Project success requires sustained effort. It requires getting a number of things right. This is not easy; hence, the vast literature and established methodologies like PMBOK and PRINCE2 on the topic.
Project failure, on the other hand, can be more or less avoided by focusing on a few critical factors. When we are well set up to avoid failure, we are automatically well set up to obtain success. Understanding the causes of failure is, in a way, then a shortcut for increasing the chances of project success. In this post, I look back at projects I’ve been involved in and present five factors that guarantee project failure.
Without strong executive sponsorship, a project has no chance of survival. In PRINCE2, an entire process, IP (Initiating a Project), is dedicated to such crucial foundational matters. Without strong, engaged, and visible sponsorship, a project will fail. No exceptions. This may seem obvious but it’s surprising how many projects start, and continue, with weak, ambivalent, or un-committed sponsors.
Project Management relies on planning and tracking to plans.
Despite what “agile” proponents, or those who decry “perfectionism” might say, this quote by Dwight Eisenhower stands the test of time:
In preparing for battle I have always found that plans are useless, but planning is indispensable.
A Project Plan is the quintessential artifact of project management.
There are 3 types of failures here:
The above failures sound ridiculous, but sadly, are not. They are real. A clear Project Plan is fundamental for setting expectations with stakeholders. No plan means no guidance and a project without guidance goes nowhere.
Communications are the lifeblood of project delivery. It’s a crucial aspect to get right, and probably the trickiest one, because there is no “right” answer, and plenty of room for continual improvement. Project communication includes at a minimum, communications between the project team and the PM/Governance forums. It’s crucial that this communication actually happens.
PMs must have honest and timely two-way communication with teams. Many times, this does not happen. Governance forums have an even higher responsibility for communication and are often the bigger culprits. Many forums behave like top-secret committees with just one-way entry — whatever goes there is discussed, documented somewhere obscurely, and never communicated back to the people who need it.
Nothing disconnects, alienates, and demotivates project teams more than communications that are ad-hoc, secretive, “just-in-time” or non-existent.
This is a problem in many projects and a big one in projects that meander meaninglessly or fail. Unclear role definition is common in projects for two reasons. First, many PMs can’t be bothered to delve into this (important) detail. Second, it’s conflated with structure.
A team structure chart ≠ role clarity.
One project had frequent structural changes. The project “roles” however were never clarified. Inevitably, there was confusion, chaos, and conflict. To address that — there is another re-structure! Still with no role clarity...
Defined roles and responsibilities have the “double effect” of facilitating project delivery and decreasing conflict.
Role clarity is a foundation for project success, and by corollary, a core factor for project failure.
I classify PMs into two categories — inactive and active.
The former is the most common species out there. They appear busy but take very little real interest in the project. Usually, they don’t understand the core subject matter or key parameters of what they are delivering. They rarely, on their own steam, install any project management structures.
Delving into details is beneath them, and when their laissez-faire approach risks being exposed, they come back with questions on effort and time — “Can we do it earlier” etc.? to feign control. This same also applies to Project Directors, at the relevant level of abstraction.
Contrast this to active project managers, who actually “manage” the project. While they leave the team to work on details (and don’t micromanage), they understand the subject matter. They activate relevant networks, put in the required operating structure (registers, updates, meeting cadences, etc.,), create a visible Project Plan, and actively manage progress.
With passive PMs, a project can never propel forward with the required speed or sustain any purposeful momentum.
Lack of project “management” is a gateway to other areas of project failure, which makes it particularly insidious.
The above is not an exhaustive list of factors contributing to project failure. There are others also, e.g., lack of strong business case, inadequate risk management, etc., which play a part. They are, however, what I consider to be the Top 5 key factors.
How many of these 5 factors does a project need to fail, to be considered a failure?
While there are indeed projects that have failed on all 5 counts, (yes, seriously), the answer is just one.
Failing on JUST ONE of the above will guarantee project failure. These are discrete foundational pillars. If one is weak, the structure is compromised. By popular estimates, approximately 70% of projects fail. These above factors provide the surest way to guarantee being part of that statistic.