Project teams often bear of the brunt of this indecisiveness. Impossible targets, lack of clarity and an overcommitted team leaves team members disoriented and frustrated. This is an all too common problem that appears to have very few solutions.
Yes, every project should start with a set of well-defined requirements and use-cases. This, unfortunately, is a misunderstood concept. What does ‘well-defined’ mean ? Besides the use cases, there are some obvious parameters that are ignored. If these parameters are missing, prioritization is almost always incorrect or missing. So, I believe every requirement must come with the following parameter definitions (at a minimum) –
1) Requestor Priority – P1 (immediate), P2 (during next release), P3 (at some point in time). Note – definitions are rough and change based on the nature of the organization, product and team structure.
2) Requirement Justification – Why is this requirement being requested now and for this particular customer base ?
3) Business Drivers (customer / cost / product benefits) – Include $ values where possible.
4) Suggested Functional Solution – Not to be confused with design ! What is the suggested functional approach / interaction / workflow between various product components ?
5) Alternatives Investigated – What functional approaches / workflows have already been investigated and why they have been rejected / deferred ?
6) Functional Dependencies – What are the product impacts and dependencies that will keep the feature set from being complete for delivery to the customer ?
It’s interesting to note that often times the customer has not done this kind of analysis themselves. A simple spreadsheet showing these parameter values for all requirements goes a long way in priority negotiations with the customer.
Projects with incorrect requirements prioritization are doomed to failure from the start. I’d love to hear more thoughts on this !
I agree with Craig. Ranking is actually a much more granular representation of priorities. Personally I think it is more effective. However, whether you bucket things into category 1,2,3 or are able to rank your features for continuous development depends on the nature of your business, the customers involved, the release cycles at play, etc.
Also Michele is right in that the mgmt team often is too afraid to prioritize for fear of losing a customer or some other such consequences. I’ve suffered through that with my project team once. Doing so just sets the project and its team up for failure.
Thx all for your comments. This has been enlightening.
Ranking each and every requirements – at least to the horison of the next 2 releases is an excellent techniqiue in my view.
This is not rating things into category 1, 2 and 3. It’s about ranking each feature. THen you can set a deadline and see how importnt additional features really are. (You want feature Z? Okay, but it costs us another $X and Y weeks.)
Strangely ranking is a simple and elegant tool, but rarely used, and even more starangely, hard for some stakehodlers to initially work with.
Prioritization is NOT a static thing, but a constantly moving river of data which is why it gets into the “flood’ state where everything becomes number 1, often due to waiting for more data. Here is where “pairwise comparison” strategy has always worked for me. At least, it gets to some level of agreement on what is really essential in P1- immediate. I am also always amazed that Management above a PM team does not know how to guage the impact of creating this pressure. This implies the team leader is not risking his or her job enough to educate and negotiate a flow. Priorities do change at high speed for business reasons more often than technical ones. Getting some agreed upon process with the sponsors related to these potential business issues is essential and one cannot have FEAR of debating consequences with management. Sometimes it is a “do both” strategy as well meaning more work and less analysis. Collecting more data on “How fast the boat is sinking in the river of change is not of prime interest.”
I don’t know that certification makes any difference. I have worked with PM’s that didn’t understand ranking or the requirements collection process. In fact the last project I worked on the client wouldn’t let us talk the the users to capture the requirements, IT management just kept telling us what to do and that they knew what the users want, and of course prioritizing everything as “must have.” No wonder the project was late and over budget.
We all know this stuff…document requirements, prioritize, etc., etc. but time and again stakeholders and sponsors put unreasonable demands on project teams and rules get bent, and best/good practices get ignored.
Defining WHAT you are building at the outset, and especially how much and detailed to define it, is one of the toughest nuts to crack in business. A project charter document is all some projects need, whereas others, like a trip to the moon, take a bit more detail. I suppose this is what separates good PMs from poor ones: knowing how much detail is needed to minimize surprises, but not so much that the project never gets started.
I would think that with all the decades of experience from millions (billions?) of projects, plus the zillions of articles, books and blogs written on the subject, everyone would be following a standard approach that works in most cases, such as the one you outline here. I suppose that why the trend toward PMs getting PMP trained and certified.
Great article!