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 !