Why your project management methodology might be causing your projects to fail

Often when we talk about employing systems thinking (ST), it’s usually within the confines of a traditional project management methodology (PMM), PRINCE2, Agile, Six-Sigma to name a few. We usually look to apply the new tools and disciplines ‘in’ the project, but what about using these tools on the project ‘vehicle’ itself – and could your PMM actually be the cause of your project failures?  

Management Today (2018) estimated that an eyewatering £250bn is wasted annually in the UK due to project failure. Looking at this through the lens of ST, this is what I found. 

What’s project failure? 

Strictly speaking, project failure is when a project fails to deliver all of its proposed benefits. Failure is a spectrum and can span from complete success to a total washout. Assessment is subjective depending on the stakeholder and timing; what a sponsor might consider to be a thumping success at project go-live may be called into question by stakeholders using the project’s outputs a year later. Allowing enough time after the main project delivery will help to reflect on the answer to ‘what was the purpose of the project?' beyond its outputs. 

What do organisations value in the PMM? 

My research made clear that project professionals felt that there were some red lines in changing their organisation’s PMM. All of their organisations subscribed to a formal PMM in one form or another (particularly Agile, waterfall, or PRINCE2), with overtwo-thirds of these (68%) reporting customisation/in-house tailoring.  

Their organisations valued PMMs for these top 3 reasons: 

• Standardised processes that the organisation (or partners) universally understand 
• Delivery efficiency  
• Project control and governance 

What’s going wrong? 

Respondents provided numerous project case studies and these were analysed using systems thinking methods. They included: 

• E-commerce digital transformation 
• Local authority/NHS & NHS IT cross-organisation projects
• New lending product for a bank 
• Internal software platform re-design
• Highways project 
• Revenue and benefits system in a local authority 
• Enterprise resource planning (ERP)

Although the effects of the failure were felt in the ‘project management’ space, the root cause(s) were confined to the programme (corporate) management or project governance (project board) layers of project management.  

A common theme was that the project “solution” was already pre-defined before it arrived for the project manager to deliver; nearly three quarters (70%) of the interviewees complained that the solution was largely pre-ordained, and the project was started with a clear solution already determined.   

Generally, the reasons could be grouped into four key themes: 

• Limited perspectives taken into account 
• Pre-determination of the problem and/or the solution   
• Under-estimation of the complexity  
• Unwillingness to abandon the project

The first three will resonate with systems thinkers. Two-fifths of the interviewees commented that the project should have been terminated earlier, with one comment being expressed, that many project managers will likely have empathy with, “Nobody dared to say when they felt it was going wrong – there was still hope…. People personally felt exposed on their ownership of the problem.” 

How do we stop the PMM damaging the project? 

While being mindful that earlier research had recommended against changing the PMM directly (for reasons of consistency and fear of eroding the perceived benefits), my research makes the following recommendations:

1	Empower the programme manager as the systems thinker and ensure awareness on the project board	Controversial I know, but it was found that having the project manager as the ST ‘expert’ provides questionable value due to the role’s limits. The PM isn’t in charge of the project; the project board and programme/corporate management is. This is why the Systems Thinking Interest network’s first guide is aimed at project sponsors, helping them apply ST to pick the right projects, with best chance of success (available soon).  This isn’t to say that the project manager can’t be a systems thinker; although benefits are often limited and painful, as one respondent commented about being a ‘guerilla practitioner’ as their organisation wasn’t interested.
2	End “done deals” and challenge “everything is simple” thinking	Two-thirds of the project failures were caused by the project outputs being (incorrectly) pre-determined before the project was even initiated. This thinking automatically assumes that the problem is sufficiently understood and typically that the problem is simple – a key failure point.   The project manager has no real handle on this – they accept the project mandate/brief and deliver upon it. Unless the project is genuinely simple, it needs a full systems thinking-inspired review. Re-assess as required.
3	Better support for the project manager	Alongside the idea that ST needs to be led at the programme management layer, upper levels need candid, two-way feedback and for the PM to be the ‘eyes and ears’ on the ground. Honesty in project reports should be embraced.   Standard project governance tools came in for much criticism; one individual commented that their project governance was “the illusion of certainty which everyone around knows is garbage.”
4	Utilise appropriate premature termination of project without fear	Fail cheap and fail fast.  Not all projects will succeed. You may get so far down the path before realising this. Many projects were known to be duds after initiation, but either through fear of “quitting” or organisational politics, they were stubbornly pressed to continue.   Respondents provided (humorous) anecdotes from project board meetings where members readily accepted ‘green’ project health statuses, only to roll their eyes at each other or have ‘corridor’ conversations afterwards (in what I dub “shadow project boards”).

None of the recommendations above fundamentally change the PMM; these can be adopted using ‘out of the box’ processes. For example, PRINCE2 has a specific process for “premature closure of the project”  if only this was better used! 

In closing, this article makes the argument that with a more systemic understanding of the “projectified world” that we live in, we may actually increase project efficiency/reduce failure without necessary actually changing the project “vehicles” themselves.  

 

You may also be interested in:

• What is project planning?
• Avoiding project failure — and ensuring success
• Governance: an enabler to project success