Project professionals inhabit very strange worlds sometimes, but rarely so odd as that of the Recovery Project.
So in the spirit of the fantastic things one sees and hears on such an assignments, here are some highly opinionated and satirical perspectives on this dark category of rogue projects and programmes.
How to spot a Recovery Project?
To need recovery, a project (which I will use to cover programmes) will be significantly off-course from original baselines, unable to deliver the benefits on dates agreed with the project sponsors and perceived to be in urgent need of structural reform.
Obvious symptoms are that delivery deadlines have been habitually missed or there is no clarity around one or more future key delivery dates despite repeated demands from sponsors.
Signs may be more subtle or indirect. For instance, software that doesn’t stop throwing up P1 bugs despite efforts to stem the flow or mounting technical debt.
Most commonly, there is a saga of failure plus a meltdown in stakeholder confidence.
Sometimes, all you might detect are what might be called meta-symptoms, such as a succession of project managers, several people departing the project in vague circumstances or empty key roles.
Only when you, as the project professional chosen to “shake-up the team” or “improve governance” realise that the carefully chosen euphemisms used during your recruitment cover up an inglorious history and a stakeholder community collectively frothing at the mouth does the reality begin to dawn.
Within days of starting, you suspect you should have negotiated danger money on top of your rate as you appear to be walking a tightrope whilst spinning broken plates. The truth drops like a lead weight in your gut: you are managing a Recovery Project!
Welcome to the theatre of the absurd
“Saying the unsayable, imagining the unimaginable, and still making sense.”
One of the first things that may strike you is that whatever steer you have been given by the management that recruited you to do the recovery, people in the know often won’t recognise the project as failed or failing and are resorting to linguistic contortions to avoid describing it in those terms.
There is usually a pall of denial hanging over a Recovery Project. Though stakeholder trust may be heavily eroded and the project team know change is needed, the root-causes of project failure are usually a complex interplay between stakeholders, project team and (where applicable) supplier interests and behaviours. Explanations for project underperformance as may be proffered are often simplistic such as blaming the previous project manager for being “too laid back” or the adoption/rejection of Agile (delete as appropriate) or stakeholders frequently changing their minds/pulling in different directions.
Where this culture of denial exists, there is often a belief that the way forward is to focus on what you might call Low-hanging silver bullets rather than the structural, multi-dimensional problems you suspect are the real problem. Already, there is a disconnect.
These alleged quick-fix solutions are often typified by sentences which include the word “just”, as in “We just need a better plan” or “we just need to get tough with the supplier”.
Hear a sponsor or senior stakeholder talk in these terms and you realise that not only are you going to have to sell the need to swallow several bitter pills but you will also have to explain why chasing those low-hanging silver bullets is unlikely to turn the project around. Your task list has suddenly sub-divided and grown like a virulent cancer.
Passions run high on Recovery projects so don’t be surprised to encounter such phenomena as Governance by Harassment. This is where a forum such as a Steering Group provides one or more members with a recurring opportunity to pursue an agenda designed to distance the members from the delivery team and deny them the devolved authority, resources and guidance required by its terms of reference. At times, it can feel like a vendetta.
A while ago, I took on a failing programme where the external stakeholders were actually the company’s shareholders. They chose to assemble a small team of representatives from their respective organisations into what they called a Task Force whose most vocal member was someone I shall call ‘Karl’.
Karl engineered things so that he had a weekly (and eventually daily) opportunity to torment the team with barbed questions which were engineered to suggest that the obvious had been overlooked or that we were making the wrong priority calls.
Again, time that should have been spent repairing the broken project had to be diverted to the management of his interventions. Rarely did his implicit criticisms reveal a material shortcoming or strengthen our approach but it sowed seeds of doubt and mistrust in the minds of our insecure internal stakeholders which simply multiplied our burden.
Heroes are the bad guys
Another frequent feature of this topsy-turvy world is the hero worker. Not entirely unlike the propaganda type beloved by the USSR or the Chinese Cultural Revolution, this is an extremely hard-working and conscientious individual who repeatedly goes above and beyond the strict terms of his/her duties by stepping into a resource, process or skills gap and working long hours to cover the day job as well.
Senior managers love project heroes but the reality is that they are a menace. Acts of heroism unwittingly conceal deeper, more hardwired problems whose resolution simply pushed into the future. Worse still, it isn’t unknown for the project hero to cut corners or ignore proper procedures and thereby contribute to technical debt which will eventually need to be addressed.
Heroes should be expunged from projects at the first opportunity but try telling that to the sponsor who sings his or her praises!
And just when you thought it couldn’t get any more dysfunctional, you find that every creative solution you come up with is countered by someone you would otherwise respect with the retort “oh, we tried that x months ago”. So, as well as having to come to terms with a Looking Glass world where nothing is quite as it seems, you also trapped in Groundhog Day.
As the saying goes, “you can’t make it up” and trust me, I haven’t!
Starting over may be better than running repairs but support will be elusive
“Dysfunctional is fixable, dystopian needs nuclear solutions”
With many failing projects, the root causes can sound like recipes for disaster: a messy stew of Agile and Waterfall; over-cooked bureaucracy and under-cooked governance; sloppy business analysis and over-egged requirements. You get the idea.
It takes skill and time to unpick the puzzle, not least because there will be shoals of red herring tempting you to swim in the wrong direction. Speak to your predecessor, if still around, and a strong rationale will often be given for past decisions which just 6 months later may seem naïve, negligent or misguided. From your perspective, it may seem reckless not to have had a test strategy and an experienced test manager, but does that mean that new issues emerged during that time or that the people managing the project earlier in its life missed the obvious? Sometimes, you can rely only on your own instincts.
The kinds of underlying issues I have mentioned above are both common and relatively easy to fix. Usually, the management caucus that has parachuted you in to recover their project will have already reached the same or similar conclusions and is happy to wave through the changes you recommend to fix a set of identified problems provided you don’t slow the project down.
On a software project, running repairs will allow you to continue to churn out code, test and ship it to a pre-production environment. With some deft replanning, you might still be able to preserve the original delivery timelines, perhaps by reprioritisation or rephasing, but chances are these will need revision. Long faces from stakeholders but momentum is largely preserved and the changes you are advocating are generally not viewed as holding the project up.
That’s where you want to be but sometimes the range of problems means that the disruption needed to implement the fixes justifies a formal halting of the project and a formal “Recovery Phase” of perhaps 6-8 weeks. Because of the resistance you will encounter, this needs to be treated like a mini project in its own right with its own detailed plan, objectives, defined benefits and frequent review steps.
However, a broken project can be an extremely complex matter with many difficult trade-offs between doing the right thing and the short to medium term hit taken in costs and time lost. Many stakeholders do a job where results happen within a relatively short time horizon and so they are professionally phobic towards the idea of short-term pain for long-term gain.
Additionally, they may not be particularly au fait with project techniques and so telling them the testers have only been conducting functional rather than end-to-end tests, so we need to rethink the whole testing strategy or the development team hasn’t been operating proper Agile is unlikely to convince them of the value they will get from the large sacrifices being asked of them.
Stakeholders will always favour running repairs, no matter your prophesy that, in the long-term, they will come to regret it. Unfortunately, there is a limit to what running repairs can achieve and there is a whole order of magnitude difference between the merely dysfunctional and the truly dystopian. Once acknowledged as such, the latter category projects are best put into stasis and brought back to life only when all the vital organs of the project organisation are functioning correctly. But things will have to be truly wrecked and everyone singing the same tune for this to be proposal with any prospect of being sanctioned.
A need to be popular and Recovery Projects are uncomfortable bedfellows
“Enter as messiah, exit as pariah”
Ok, that is a little bit melodramatic but it’s hard to resist a good rhyme when there is more than a grain of truth in the statement. For when you arrive on the scene, you may initially be treated as the Saviour but stakeholders, being a fickle lot, when it is time to line up another scapegoat, your walking on water days will soon be over.
Never forget that you are tasked not only with recovering the delivery side of the project but also, and perhaps more importantly, with the collapse in stakeholder confidence
I recall one particular 25 million euro programme for a very high profile client which had happily sailed along for 4 months with a fixed launch date plucked out of thin air, superficial governance and no project plan to speak of. Though I had inherited problems of others’ making, I got the launch over the line 3 months later than the original target with a rephased scope. We went live with very few technical issues and the client was coining in thousands from day one.
On this occasion my efforts were acknowledged but a few months later found myself pitching for a new job with a large telecoms company, very happy to gild my credentials with tales of how I turned this behemoth around. The senior business manager, for whom I would be working, would have none of it.
In his eyes, I had patently failed to give the customer what he had wanted, and I must have been suffering some kind of delusional episode to be proudly illustrating my alleged talents for dealing with difficult programmes with such tales. Thankfully, I didn’t get the job!
The point is that recovery is relative. Whilst you may believe that you have worked miracles by preventing a project falling off a cliff, to stakeholders who have possibly lost bonuses and credibility in the eyes of their customers and management, the concessions you inflicted on them in terms of timelines, cost and scope meant you simply made things worse.
It is no small part of Recovery to get senior stakeholders on your side and keeping them there whilst holding forth about the many issues they failed to properly supervise in their governance and assurance roles.
Even when you have successfully resuscitated a previously moribund project, knowing you have met your objectives and done the best job possible in difficult circumstances may be the only consolation you get for a widespread lack of gratitude.
Just as falling out of love is irreversible, so a stakeholders’ loss of faith in the project team is usually terminal.
Chances are you are only the latest messiah to arrive on the scene with an aura of the miracle worker about you but try hard not to acquire a messiah complex, no matter how many senior people ostentatiously put their faith in you.
On a very troubled recovery assignment which I described to the CEO in my first week using a very pithy past participle, I was for a time, assailed by senior managers with the opening line that they had been told by the CEO I was the best programme manager to date.
Fast forward several months and that same CEO had come to the view that his survival in the role depended on sacrificing me and silencing the home truths he and his colleagues could not face up to.
As most senior stakeholders would struggle to tell a good Programme Manager from a purveyor of snake-oil, don’t let the initial flattery go to your head.
Much better to adopt an imposter mindset and do your job fearful of being found out because misplaced trust that key decision makers will continue to be on your side could be your downfall.
Expect to justify your approach every day and be prepared for the killer question that puts your judgement on the line in the bear pit of Steering Groups or PMO reviews. A pessimist is rarely disappointed on a Recovery Project!
Dealing with dystopia and projects in a persistent vegetative state
“Cruelty motivated by kindness is an impossibly tough sell”
As already argued, most senior stakeholders will want you to make running repairs, even if they don’t phrase the endeavour in those terms. No one wants substantive activity stopped and resources stood down. However many and complex the fixes, no matter how deep the rot that has set in with bad practices and broken governance, such is the embarrassment, inconvenience, and loss of face amongst those with a significant stake in the project that very few project managers are able to successfully make the case for doing what will prove to be, in the long-term, the right thing.
When I was confronted with such a situation, knowing that my predecessor had argued for the same hard-to-swallow medicine, there was the added complication that the integrator’s business almost totally depended on this project to maintain cashflow and that therefore a moratorium on software development would mean having to release a large number of developers.
They were a supplier with a dubious track record on this project but to remove their management from the equation whilst retaining what human and intellectual capital they possessed meant risking a very significant disruption whilst we built back better, to coin a phrase.
This was a damned if you do/damned if you don’t moment. It was clear to us in the project team that the right thing to do was to stop the project and plan recovery in such a way that the time lost was made up when the benefits were reaped from taking time to fix all that was broken.
However, the sudden arrival of a new CTO keen to remain popular with the shareholders who had recruited him meant that we continued to do the equivalent of trying to repair the engines on a 747 mid-flight. And whilst improvements to project performance were made, they were not big enough to count as a recovery worthy of the term.
The trick is knowing when to admit you have run out of magic dust. No one likes to admit defeat but sometimes you are simply up against the laws of physics and the only sensible course of action is to turn off the power, dismantle, reconstruct and restart.
Unfortunately, even if you and some like-minded colleagues see it that way, it is very unlikely you will convince the sponsor and senior stakeholders. It means the organisation acknowledging failure and the politics of most organisations make that impossible.
Recovery projects: A poisoned chalice or double-edged sword?
“Recovery projects can be hugely stimulating but loved ones might need to put you on suicide watch”
Recovery Projects are some of the most demanding and rewarding endeavours on which project professionals can apply their career experience and insights. They require vast amounts of resourcefulness, pragmatism, lateral thinking and single-mindedness and can therefore be highly motivating for inveterate problem-solvers and those who get their thrills from innovating solutions and challenging the status quo.
Expect stress because you will be working under the scrutiny of a disgruntled stakeholder community who will show as much mercy as a packed jury at a Stalin show trial.
Most have already decided that Project Management is a dishonourable profession of chancers and quacks and some may even believe they could have done a much better job if they had been in charge.
You really, REALLY need to be prepared not only to be unpopular but to do those things you know will make you unpopular and trigger auto-da-fe style interrogations.
And the rewards? Hopefully, the personal pride that you have been, if not the mastermind, then the catalyst for putting the show back on the road and getting it over the finishing line, albeit late against the original baseline and slimmed down.
The camaraderie of working closely with a few like-minded people who didn’t previously get the opportunity to put into practice what they knew should be done or who you have recruited is also a huge source of satisfaction and powerful reminder of what true team-work can achieve, even it is not universally appreciated.
And best of all, there are the war stories you can regale friends, family and colleagues with during those long days of lockdown, though I would counsel against taking glazed expressions and uncharacteristic silence for awe!
Unless you prevented the Channel Tunnel from taking a nasty turn or got Apollo 13 safely home, best to assume your loved ones would rather be watching repeats of the “Masked Singer”.
Paul Holmes is an Agile PM/PRINCE2/MSP-Certified IT Programme Manager with a track record of delivering complex IT software projects.
