Project 'Death Spirals': when denial is no longer an option and it’s time to press Abort! By Paul Holmes
Previously, I have written about the gothic traumas of Governance turning on a project and Stakeholder SHAMBLs. So destructive are these spectacles that they should be regarded as portents of what I call Death Spirals.
Calling time on recovery
In aeronautics, the expression death spiral describes what could be the final 178 seconds of a flight following a series of catastrophic compound errors arising from complex environmental conditions.
It’s not hard to see how this type of crisis provides a powerful metaphor for the final stage in the life of a star-crossed project. Though total disaster is thankfully rare, professionals piloting a project or programme (used interchangeably in this article) which has endured a saga of failure, perhaps over several years, or where attempts at recovery have had limited sustained success, are strongly advised to add this doomsday risk to their register.
Like aircraft death spirals, if a project’s fatal trajectory and its causes are appreciated soon enough, total loss of investment costs and projected benefits is not inevitable and salvage may be possible, if only saving the face of the sponsor. But just like judging when Tesla shares have reached peak altitude, so there is the awful quandary of deciding when the time is right to stop running repairs to stay airborne and start yelling “brace, brace!”.
Any one of the following alarms are warnings of project disaster. If not treated as calls to immediate action for radical and systemic solutions, the project leadership will soon discover that it is the risk of project disaster that will land and not the project itself.
Alarm 1: Governance has turned against the project
The Project Board’s mandate to provide resources, budget and “visible and sustained support for the Project Manager” has become weaponised; top-level governance has metamorphosed into an Inquisition hell-bent on intervening, interfering and instigating changes of course it deems necessary; and intervention by exception has been usurped by Governance by Harassment. The project is rapidly losing altitude, ground zero is fast approaching and no one hears the PM’s cries of Mayday, Mayday.
Alarm 2: SHAMBL syndrome
Stakeholder Hyper-Active Meddling & Blocking, like any clinical syndrome, is a complex set of correlated project behaviours that cause chaos and confusion. In particularly acute cases, it will fatally undermine the Programme Manager’s authority, subvert governance structures, and cause a complete breakdown of the controls that keep the programme in the air and on course.
In such circumstances, swapping out the offending stakeholder(s) is the obvious solution, but it is much more likely that the Programme Manager will be pushed out of the emergency exit first. A precipitous descent gathers speed as dysfunction takes the captain’s seat.
Alarm 3: Organisational civil war
To illustrate my 3rd alarm, it seems apt to recall my experience of a digital project to deliver a complex online flight search and sales service.
The company had split technology between project/development on the one hand and infrastructure/service on the other, in 2 departments under 2 directors who openly loathed each other. Their mutual hostility was propagated throughout their respective fiefdoms and try as you might to stay neutral, every project that got ready for operational testing and deployment could expect a flare-up in hostilities.
"It was like North and South Korea, but without a DMZ to keep the foes apart."
My flight project got off to a bad start because stakeholder demands, which had the gung-ho backing of the CEO, were misaligned with what was safely achievable within rigid timelines. Nonetheless, we overperformed and overflew the scheduled launch date by just a few weeks to allow for performance testing. The stakeholders made a theatrical display of their disappointment but, to all intents and purposes, we had done a good job in the face of strong head winds. Only problem was that as we throttled up the web traffic, the load was killing response times.
We were already the bad guys as we had failed to meet an unachievable deadline. The slippery answers and casual dismissal of our hypotheses by our adversaries across the border were therefore swallowed whole by our increasingly hostile stakeholders and there was a very real prospect of the project going down as a monumental disaster and blighting our reputations. No software options remained so our suspicion fell on hardware configuration rather than code quality.
So, there was no choice but for our solutions architect to mount guerrilla operations behind enemy lines to prove what he suspected: shoddy set-up of content switches. Of course, politics prevented us from revealing how we got the proof but, to cut to the chase, North Korea was ambushed into putting things right and the service went supersonic.
At an international mobile phone company, internecine tensions between the global division and the UK Opco meant that a proto-GDPR project mandated across Europe just could not get off the ground because a positive business case could not be made “locally”. All manner of catch-22’s, vicious circles and false starts afflicted this project which crashed even before it had even taken off. Summits were held but the reality was the OpCo did not want to be told what to do.
The moral of these two very different tales is that where an organisation is at war with itself and the flightpath of a project traverses conflicting departmental territories, collateral damage is almost inevitable and sooner or later, the project risks being brought down by crossfire.
Alarm 4: Methodology mayhem
Getting the programme or project methodology right for the organisation, the culture, the team, and the project type is as important as setting up effective governance controls. Despite a fair bit of dogma that I have heard from PMO’s, one size doesn’t fit all and what flavour of agile or combo of scrum and waterfall works well in one company may be lethal in another.
Adopting a methodology which fails to leverage the particular strengths of a project team whilst mitigating their shortcomings may trigger malfunction but will not usually end in disaster as adjustments can be made over time as part of continuous improvement. Indeed, when I took over one of my first large full agile projects for a telecoms retailer with declining velocity, mounting technical debt and an adversarial stakeholder community stuck in a waterfall mindset, there was a window in which to review and revise the use of story points, reorganise the team and refocus on architecture rather than features for long enough to tilt the trajectory upwards.
But it was a close-run thing. Stakeholders were murmuring of nuclear responses; team motivation was declining as the Product Owner was using stand-ups to big up team failures and play down his; and crucial market-driven milestones were fast approaching.
By contrast, I worked at a national broadcaster who had just ditched a project to develop a CMS from scratch using what was in the UK at that time, innovative agile techniques. As far as I could make out, they had attempted the steep ascent from waterfall to 100% agile without any real-life experience or an experienced coach. Apparently, it was carnage and set back the cause of Agile by years as the experience seem to disprove the many touted benefits of this new way of doing things. Time and money were lost, reputations were damaged and content managers were denied the modern tools needed to do their jobs.
Unfortunately, recognition that the project had entered a death spiral came too late for a controlled abort and the end, when it came, was bloody.
Many years later, now that Agile is mainstream and proven its worth, it is easy to assume that the mistakes of early adopters will not be repeated. There are still many organisations taking their first tentative agile steps or trying to square agile development with the fixed scope/fixed date mentality of the wider organisation, ending up with a hybridised model where the place of the project manager is being questioned and traditional Project Operating Models can be at odds with a cutting-edge technology mindset.
It can be hard to imagine that a malfunctioning methodology can bring a project down but where there is widespread dissent, compromise, inexperience and especially dogma, a grave outcome is a real and present danger. Once again, it’s time to update that risk register and start mitigating!
A brief de-brief
As far as I know, there are no check lists, fancy interactive tools or stage gates specifically designed to detect Death Spirals and trigger the momentous decisions needed to put a project and its stakeholder community out of their misery. Nonetheless, fellow project professionals will readily be able to supplement my carillon of alarm bells with cautionary tales from their own near-death experiences. Sadly, it is easier to identify the symptoms of impending disaster in hindsight than mid-flight which is why even experienced PMs will struggle to have their apocalyptic prophesies acted upon by senior management.
In my next article I will describe the Diversionary tactics and other Flights of fancy that companies adopt to disguise project death.
Whoever said piloting a turbulent project was plane sailing?
Further reading:
Download infographic: 4 Project 'Death Spiral' Alarms
When Governance turns on a project
When stakeholder over-engagement creates SHAMBLs
About the Author
Paul Holmes is a consultant IT Programme Manager with a background of 30 years bespoke software delivery in a wide variety of industries. He has particular experience of managing troubled projects needing intensive recovery measures and often writes about lessons to be learnt and the pathology of project problems. All perspectives and opinions expressed are Paul’s own. You can contact Paul at paul@retrograd.co.uk or via LinkedIn