Skip to content

Beyond quick fixes: The challenges to “sell” systems thinking as part of project management practise

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content
Gettyimages 669887538

In work and recent discussions within the APM Systems Thinking Interest Network, we’ve discussed why systems thinking (ST) struggles to gain traction within an organisation’s project management “orthodoxy.” This article highlights the many obstacles in adopting systems thinking/engineering methodologies and offers tips to overcome these challenges. 

The name and lack of branding 

Although seemingly innocuous, I believe the name ‘systems thinking’ is unhelpful; it isn’t meaningful or alluring to laypeople, and is often confused with IT systems. I usually refer to it as a management science to avoid confusion. 

Tip: I don’t think you’re ever going to win this one. It’s slowly becoming more known and a key part of university courses et al. Many people may have already undertaken ST works without realising; I did soft systems methodology (SSM) at university in my 20s, but it wasn’t clear at the time that’s what it was. More people will be familiar with rich pictures for example. 

Project “done-deals” stifle its application 

My earlier article referenced why project management methodologies are often the cause of project failure. Recommendation 2 on my list was to end ‘project done deals’. This is where the scope of the project is already (rigidly) defined by the time it gets to a project manager, strait-jacketing them. This limits the benefits of applying ST expertise.  

Tip: The vast majority of project management disciplines have that level of decision-making at a higher level; recommendation 1 on the article is to empower the programme manager or ‘higher-ups’ with systems thinking expertise.  

Perceptions of ineffectiveness…. 

Systems thinking approaches take time, and a concerted effort with stakeholders. The whole point of ST is to be able to see the system as both a system in its own right as well as a collection of different (interrelated) systems and many of the common concepts of ST rely on identifying and working with stakeholders, developing mental models for review and understanding, and analysis. It requires time and stakeholder effort to see the system as a whole and its interrelated parts. This can seem like unnecessary 'chatter' to uninformed management, who may view it as unproductive. 

I’d argue it’s about ensuring that you’re delivering the correct solution — correctly — having fully understood the problem to begin with. The argument is efficacy; that the “overhead” of ST is a cheap cost to bear compared to the multitude of issues you’re avoiding by utilising it e.g. increased risk from unintended consequences, half-baked solutions, stakeholder resistance etc.  

Tip: “Measure twice and cut once”. This is the principal argument back to organisations; it’s not really extra work, it’s work done upfront e.g. when it can be of the most critical importance.  

…And a hard truth — systems thinking will not (directly) solve your problems 

ST won’t solve your business problems in a project nor claim to; it’s a problem structuring mindset and methodology; it doesn’t give THE answer. It may present several solutions each taken from different perspectives. It may drive to a purpose that you hadn’t considered, or it might force a reconsideration when you realised that the different parts of the system were working against a desirable purpose.  

Tip: you’re always going to encounter other parties who claim to have the answer. For simpler things, they may well do. For more complex/complicated environments, they almost certainly don’t. Demonstrate the value.  

It has strong (albeit incomparable) competition 

Project management methodologies like PRINCE2, PMQ etc are branded and offer 'safe bets' for delivering projects. They focus on control, reporting and following a linear process, with quick accreditation (perhaps 3 days). Utilising these, you’re unlikely to get into trouble with others playing the traditional ‘management game’ of backside covering, and an appetite to — at least be seen as — doggedly look to be “delivering” (something?).  

It’s then difficult to try and hijack the party with what might appear to be a change of direction and expend effort on ‘non-delivery of outputs’.  

Back to the point of where you can technically be ‘accredited’ to be a project manager in mere days... 

…It can’t really be trained 

I've used ST for over a decade and have a master’s degree in it, but it takes much time to be adopted in an organisation. There’re no quick courses for practitioners.  

Tip: rolling back somewhat on earlier, they’re not necessarily competition. They’ve a very valuable use but it depends on the purpose of what you’re trying to achieve. Saying that systems thinking is “better” than say Six Sigma is a bit like saying that onions are better than apples; they’re better used for different purposes. 

It’s actually quite hard — others generally seek simplicity and avoid complexity 

Occam’s Razor recommends the simplest solution. Professional life is full of similar metaphors that constantly re-enforce the narrative of keeping things simple (“KISS”). Don’t gild the lily or reinvent the wheel. Less is more, etc etc. But what if things are genuinely so complicated or complex?  If you don’t analyse these properly, how would you ever know? 

Project management doesn’t cope well with uncertainly; the delivery vehicle just wants to “get on with stuff” unencumbered by doubt. Doubt and fear just get in the way of delivering. Not delivering ‘stuff’ reflects badly on project managers, as is discussed in another APM article that uses the TV series “The Apprentice” as an exemplar. Returning to the project team and steering group with any suggestion that the project needs a wider view comes with personal risk. 

Tip: Unfortunately if the organisation just doesn’t get it, that’s a problem that won’t easily be solved; strike a balance. 

 

Key messages 

  • Sell by not directly selling — if there’re opportunities for sharing ST best practice in your project works, do it tactfully and by always considering the ‘so what?’ with colleagues 
  • If it works, use it — just because it’s not badged ST doesn’t mean its without use. 
  • Lead with the practical, not the theoretical. 

 

You may also be interested in:

 

 

 

0 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.