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.

Tip on how to test the Critical Success Factors of a project: propose a small Change Order to enhance the project's success and see how the stakeholders and sponsors react.

Even if the proposed change is small, those who sign-off will rightly see this as a precedent for future Change Orders and will want to watch the details closely. This is good as it will reveal the emerging Critical Success Factors as balanced between the sponsors. From the results of that Change Order you will be able to prioritize the goals between time, cost, and quality. Don't be surprised if the CSF's change over time and adapt accordingly!

When I delegate tasks, I "black-box" what I'm handing off. That means I don't hand-off tasks and then keep key pieces to myself that make it difficult for the other person to be efficient. I also clearly define what constitutes success for the particular task. That definition of success is what will come out of the black-box. 

If I'm keeping information to myself that is pertinent to the task, that may mean I don't have enough confidence yet that the specific task can be successfully accomplished by the other person. That necessary inside info is what should go into the black-box.

Maybe the person is a new contact I've never interacted with before or maybe I'm not sure that they truly have enough time. If that's the case then it's a signal to me that I need to make the black-box smaller. If the task is finished successfully then my confidence builds and I'm able to hand-off a bigger black-box task the next time around.

But if I don't black-box I can never build my trust relationship up enough to truly hand-off tasks completely.

 

What is the Critical Success Factor for the project I am about to manage?