The three key reasons why some projects fail are:
There is but a grain of joke in this PM joke: requirements are key. In real life, three different sets of requirements could and should be identified during the project initiation.
Requirements-1: The Spec.
First requirements that come to mind are the “standard” ones: what exactly we have to deliver. If the “what” is not defined properly, different interpretations of the requirements will lead to reworks, conflicts, delays etc.
Although requirements definition and requirements management is an important part of the PM’s job, it is important to go one level higher and make sure that we understand the business context.
Requirements-2: The Constraints Triangle.
If you’ve read this far, you are probably not new to the project management. Hence you know that the triple constraints – Scope, Time, Cost – are part of PM life, and that another PM not-exactly-a-joke insists that you can pick only two.
Your Sponsor must pick the two from the get-go, as he has the ultimate authority to call your project a success – or a failure. Your role as the PM is to obtain this guidance, have it reflected in the documentation and communicate to the team.
Requirements-3: The Goal.
Delivering the agreed scope on time and under budget is what the PMs are hired for. In order to excel, you need to find out what is the real Goal of the project. In most cases, the Goal goes hand in hand with the defined constraints, but not always.
Usually, the goal of the project falls into one of the 3 following categories:
- Make money. Keep the Cost down, period. Ever bought a house from a developer?
- New product (first-of-a-kind) development. Depending on the business, priorities may vary, but likely the Time (TTM) is key. (Launching new mobile handset).
- Deliver or die, but better stay alive. Think space mission.
Knowledge of the Goal will allow the PM to come up with the right tactical solution when problems start popping up, and the team expects an immediate decision.
Getting the Goal clearly identified may be more difficult than prioritizing between Scope, Cost and Time; corporate politics may be involved. That makes the Goal all the more important for the project success.
Being able to define the Goal and stay focused – on the Why as per Simon Sinek, or on the Purpose, as per Dan Pontefract – is the hallmark of a true leader (who may happen to be managing a project at this time; someone has to).
Bonus: Requirements-4 – Values
This is a bonus for having read this far. You won’t find this in the PMBoK.
When the project Goal is clear, all other requirements will align. Now the PM needs to have the team assembled. In most cases, PM selects the team based on competence profile and resources availability.
Up one level, the PM selection is done the same way. Hardly ever the choice is adjusted based on the personal values’ alignment. This is the key reason why some projects fail.
To get the Olympic gold in freestyle wrestling, you will not take a marathoner on the team. Likewise, to have your cutting-edge equipment tested before the launch, you may need a person totally different from those who designed it.
The aligned project team differs from other teams the same way an Olympic team differs from any other team, even the “all-stars” level. The team members are so deeply synchronized that their actions are a continuous masterpiece of work, not just occasional three-point shots that are awesome. They work together in a “flow.”
Depending on the Goal, you will need people with a different values profile on the team. Of course, if you do not need to excel, no need to bother. But I would consider changing jobs then.