The exact moment when a project fails

Sadly, projects fail all the time.

Do a quick Google search on failed projects and you’ll find a mountain of statistics about how often projects either run over time and budget, or fail to deliver the value that was expected, or both. It doesn't seem to matter what the industry is or where the project is being delivered, failure rates are staggeringly high. Regardless of whether the project is an IT implementation, the integration of an acquired company or the development of a new product, they fail on an all too regular basis.

Which begs the obviously question: if this problem is so ubiquitous why does it keep happening? Billions of dollars are spent every year on project management techniques, change control processes, training and cultural change. There are a plethora of project management tools to track and monitor progress, and armies of consultants charging top dollar to lead and deliver these projects. And yet they still fail on a consistent basis.

Well I'm about to give you the secret to successfully delivering projects, and it’s got nothing to do with high paid consultants or complex project management methodologies.

The secret to delivering projects successfully is knowing, in advance, the exact point when the project will start to go off the rails. Because if you know exactly when this occurs you can to address the issue before it becomes a problem. And the best part about this that it is the same point every single time… well actually it’s two points, but we’ll cover that in a minute.

Here it is: the exact point where the project begins to fail is before the project has even started. It is that tiny little gap between the project being given the green light and the project actually starting. It's the time between the approval and the project manager being appointed.

Why is this the point of failure? Because it's the exact moment when the project goes from being theoretical to actual. From expectation to reality. And critically, from the sales team to the delivery team. And it’s this last point that is the most pertinent.

One thing I want make clear is the definition of the sales team. This does not have to be an external sales team selling your company something. It can be that, but it can also be an internal team who are championing the project or initiative. The "sales team" is whoever is responsible for driving the initiative from idea, through planning and budget approval to sign-off. Whoever "sold" the company on the vision of the project is part of the sales team.

The crux of this problem is that in the vast majority of cases, whether it is handled externally or internally, the sales team and the delivery team are two separate teams. Very rarely does the sales team stick around to manage the delivery, or has the delivery team been involved in the sales process from the beginning. Standard procedure for most companies is that the sales team wins the work (or gets it approved) and then “throws it over the fence” to the delivery team who are expected to slam dunk the project despite knowing nothing about it until it lands in their lap.

This is the exact moment when the project begins to fail; during the dreaded handover.

The handover is usually the most poorly performed operation in any organization, regardless of the task or the teams involved. The reason for this is that there is a fundamental conflict of priorities between the two teams: the sales team has done their job - they got the project approved - and now they are ready to move onto something else. To them this project is now yesterday’s news. Meanwhile the delivery team are probably still wrapping up their previous project and want to get all the loose ends tied up before they can give this new project their full attention.

As such the handover is one of the most rushed, poorly executed tasks that most companies perform. I have literally witnessed multi-million dollars projects handed-over from one team to another in a single one hour meeting. These projects are destined to fail.

A successful handover takes time, real time. It took months to sell the company on the initiative and it will take months to implement it, so how can anyone expect the handover to be performed in a matter of hours? In order to successfully deliver the project the delivery team needs to understand all of the decisions that were made during the sales process. Not just the high-level stuff like why are we doing this project and what are we trying to achieve? But the nitty gritty: where did these estimates come from? Who did them? To what level of quality have we budgeted for the delivery? How many resources have been allocated to each section of the project, what is the logic behind these numbers? And on and on.

In order to get maximize the chances of successfully delivery, the project it must be set on the right path from the very beginning. This means a structured, in-depth handover is required and ideally someone from the sales team would be assigned to the project for at least the first third of the delivery in order to provide detailed context to the decisions made. While this might seem impractical, compared to pulling someone from the sales team back into the project 3-months later it’s a small sacrifice to make. And compared to the cost of the project failing this is a really small sacrifice to make.

A huge factor in the successful delivery of any project is the handover process. The more thoroughly this is done the more the delivery team understands the boundaries of the project, and the more they will understand how success can be achieved. The transition from sales to delivery is the exact point at which projects start to fail.

However I mentioned earlier that there was a second point at which projects fail, and interestingly this second point actually occurs after the project. It’s the post-implementation review (or PIR). How many of you have ever seen a PIR executed properly? I never have, not once.

The delivery team is under pressure to close out their current project and more onto the next one… which just got thrown over the fence from the sales team. Yet the PIR is essential for the successful delivery of the next project. If we don’t learn from this project we will almost certainly repeat the same mistakes on the next project. Just like the handover from sales to delivery, if the PIR is not performed thoroughly and the lessons learned disseminated across the organization then you’re setting up your next project for failure before it has even begun.

Handovers are one of the primary areas of failure. This is where miscommunication, misunderstanding and misalignment of expectations creep in. Instead of being seen as a chore, these transitional points should be embraced and given as much attention and structure as the project itself. Companies are always under pressure to deliver things faster, this is natural, however by taking just a little bit of time to focus on these handover points companies can save themselves a huge amount of pain in the long run.

 

If you found this post interesting please follow me on twitter where I discuss decision making for strategy, R&D, change management, product management, M&A and project management