Requirements data: Projects, not customers

[Continuing a series of posts, started here.]

Certain words in the technology industry lexicon are so unspecific that they obscure more than they describe. Customization is one such word. Another is customer.

Who needs your products and services? Not General Motors. Not McGill University. Not the US Department of Labor. Instead, the collection of people, procedures, and problems that constitute a project define who the "customer" really is.

I learned the importance of this distinction by way of customer references. Everyone wants to have a Name Brand Customer as a reference. However, notoriety has nothing to do with customer success. A Big Name Manufacturer had less success, due to internal politics, than Dinky Manufacturer. Of course, dazzled with the glamour of working with Big Name Car Manufacturer, we wasted a lot of effort on trying to help people who, in all frankness, didn't really value our help, because they weren't ready to receive it.

The same rule applies to all aspects of product management, but especially to product requirements. If you're trying to find organizations that are representative of your target customers, the project matters far more than the name of the customer.

A recent case in point, from my own experience, is Harvard University. You might think that you could learn a lot about what higher education needs from a software vendor by studying Harvard. However, Harvard's IT organization is much less centralized than the average. (In fact, I used to advise other members of the PM team not to think a single "Harvard IT department" at all.)

Could you learn valuable lessons from Harvard? Maybe, but not about the process of rolling out a new service to a campus-wide audience.

Focusing on the project also increases the chance that you are tracking the right information. The sort of information about customers that you might find in a CRM system--their headquarters, vertical, company size, etc.--may be completely worthless, for your purposes. Far more important are details like project goals, the definition of success, the project champion, and the target user.

To use another example from higher education, Northeastern University has a world-class IT department. For many projects, they'll be the point of the spear...But not for every project. If you want to understand how to support faculty research, you need to talk to people in the Sponsored Research office. If you want to see what people are doing to protect the university's intellectual property, you need to talk to someone in the library. While the central IT organization, as good as it is, definitely has a role to play in both of these projects, it's not necessarily the leading role.

Therefore, product requirements need to focus on the target project, not the target customer. Requirements information needs to reflect this emphasis.

Categories:

Comments

re: Requirements data: Projects, not customers

Tom, your I share you views generally and I'll agree that requirements information should essentially focus on the project. The challenge in my experience has been that your customer does not readily see the distinction. One term you haven't referenced is that of 'stakeholder management' within the scope of a project proposal. Requirements gathering (to assure a satisfactory project outcome) should take full account of the organisation's goals - which may often appear to dilute the 'project' goals.

re: Requirements data: Projects, not customers

Yeah, I've certainly seen that phenomenon in action. The stakeholder hands off a project to someone who may not understand or share the original project goals...And wackiness ensues.I'd be interested in hearing more about your experience with customers who did not see the distinction. Without naming names, of course.

re: Requirements data: Projects, not customers

Tom;On the distinction between organisational goals and project goals, t’s often the case that without thorough stakeholder engagement in the requirements phase, there’s a significant delay to subsequent phases (mostly through rework).Probably the most visible and familiar effect is “scope creep”, which I think many project managers and product managers will agree is not “creep” but an arrival (eventually) of what the project scope should have been in the first place.There are several research papers on the matter, each emphasising the importance of those people with a vested interest in the project outcomes.A couple of illustrations from my experience: Large projects have objectives like (a) saving a few million dollars, post implementation (b) enabling new process efficiencies and services across the enterprise. At that scale, several departments and executives are involved and affected and essential for a well-coordinated, manageable project. The challenge is to have them take part in the development work as opposed to being anxious beneficiaries of the outcome.They have to say exactly what they want, how much they’re willing to contribute, and what impact on the results (from their perspective) they’re willing to accept if the implementation costs are too high or the schedule is too long. I think project managers are excellent at seeing activities through. That’s their expertise.The rest of us have to help them ensure the effort matches the true expectation from the outset.P-J