Prioritize Stakeholders Before Prioritizing Requirements
In large organizations, the contract that is handed to a Project Manager often seems like the results of a collective brain-storming session.
There is a reason for that apparent incoherency.
A contract starts as the brain child of an executive and when expressed at that level, so far, so good. That's usually represented in the first page or two of the contract. Then as the negotiations get under way to put specific term and conditions down on paper, every other group with an executive of their own will attempt to insert a tangential deliverable or a perplexing contractual footnote. The riders are often allowed to happen for political expediency and buy-in by other groups. By the time the signature is on the page, the original intent of a project is often buried in pages of verbose or obscure language.
Enter the PM. This is the beginning of why he is earning his pay. The Project Manager has to attempt to read between the lines and map the specific requirements to specific executives. Once you know which executives own which requirements, you will have to assess which of those executives has the most power.
Give more emphasis in time and and resource assignments to the requirements owned by the most powerful executives. This gives you a method for prioritizing requirements.
By the way, if you don't have a charter at this point, you will now have a sound base from which to write one.
The mistake I used to make as a rookie is to treat the contract as a coherent expression of a unified goal and then attempt to balance the priorities on the basis of a logical or technical dependency map. This can make for an unhappy situation as I was giving as much priority to one set of logical dependencies as to another. The right approach is to recognize that requirements are not all valued equally. In fact the ones put into the contract by the most powerful groups are the ones to be most valued. That value ranking will not always translate neatly to a logical dependency map. This means that sometimes testing will be done after implemetation if, for business reasons, the Stakeholders with the most power are also the ones with the greatest appetite for risk.
When you think of it, this is the same as when someone is shopping for a car. Sure everyone wants performance, fuel efficiency, good looks, moon-roof, cargo capability, hauling capability, all in one car. The reality is that for the same price range, one will trade good looks for cargo capability or vice versa. The added difficulty with a project is that you are working with usually multiple stakeholders, instead of one stakeholder, with different and sometimes contradictory priorities.
Some will have to be pleased more than others.
Conclusion: actively recognize the business context within which a contract lives and prioritize requirements accordingly.
