When Governance turns against a project, by Paul Holmes
The origin of the Malady
When our natural defence system can’t tell the difference between its own and foreign cells, the body can attack itself, giving rise one of many chronic auto-immune diseases such as Rheumatoid Arthritis or Psoriasis.
A similar but often more fatal condition can afflict projects that have been suffering for many long months or release cycles from a sorry saga of failure and underperformance. Well-resourced attempts may have been made at recovery, but business sentiment has not been turned around, resulting in a hardening of distrust by top-level governance entities such as Steercos and Programme Boards in the project team and its approach. The relationship is heading for crisis as the melt-down in confidence continues.
"Admission of failure is sometimes a harder pill to swallow than suffering its enduring consequences beneath a veil of public denial"
One obvious option is to can the project entirely but as I argue elsewhere, admission of failure is sometimes a harder pill to swallow than suffering its enduring consequences beneath a veil of public denial. Alternatively, in a moment of blinding clarity, Governance decides it knows best and begins to turn on the very project it is set up to protect, sustain and motivate.
This article will look at what it means for a project to self-harm in this way.
High-level anatomy of project governance
Leading methodologies such as PRINCE2® or MSP have drawn on concepts such as the Separation of Powers which stem from constitutional theory to build a canonical governance model in which the executive branch of the project (i.e. the project team) is operationally discrete from the governing brains of the project (i.e. the Steerco or Programme Board). This is distilled down to the cornerstone principle of Delegated Authority according to which the majority of successful projects and programmes are run, whether in IT, construction or business transformation.
The PRINCE2® view of the world is often articulated in a simple and familiar graphic such as this:
PRINCE2® Management Levels. Image courtesy of article Wrangle your projects with PRINCE2® Light
In this way, the PM is empowered to execute the project on behalf of the Project board. However, when these pragmatic principles are ditched, business representatives who are comfortable only when the progress made aligns with their often partial presumption of what a good project looks like begin remote-controlling the specialist project team until autonomy is just a fading memory.
When Governance turns against a project
Once the Board’s prerogative powers to provide resources, budget and “visible and sustained support for the Project Manager” are weaponised, top-level governance rapidly metamorphoses into an Inquisition with a mission to intervene, interfere and instigate any remedial action it deems necessary. From the project team’s perspective, second-guessing project decisions and blamestorming have become the norm whilst preparing for Steercos/Boards and cleaning up their aftermath now takes days rather than hours.
Intervention by exception, which is the hallmark of conventional project governance, has been usurped by what can feel like Governance by Harassment.
On one memorable occasion, I witnessed the birth of this modern-day equivalent of an Elizabethan Star Chamber.
The External Steerco, which represented shareholder interests in the company I was working for comprised an ill-assorted cast of self-appointed project gurus, CFO’s, board directors and consultants from each of the shareholders. To be fair, it had witnessed more failure and heard more excuses over the years than the press pack at Trump Whitehouse briefings. So, at one momentous meeting, it announced a regime change with no forewarning even to the organisation’s senior management.
That was the point at which Governance palpably turned against the programme and it never looked forward again.
Along with a budget cap and the imposition of a fixed deadline, central to their scheme was a so-called Task Force of 3 representatives from the 3 shareholder companies which would first conduct a deep dive into the operation of the programme, then maintain an ill-defined watching brief across all activity. A once monthly point of control by the shareholders had metastasized into a daily barrage of barbed questions and a veritable constellation of meetings to allow other interests, such as Finance to pick over the detail and, hopefully, uncover wrongdoing.
Sadly, trust is one of those things in life that, once broken, can be patched up but never fully restored. Accordingly, the loss of empowerment, the need for every significant decision to be rubber-stamped, the self-justification and back-covering, to name just a few of the disorders that afflicted this endeavour, become permanent.
The importance of 'Operational Governance'
Now that top tier governance is an unruly collective of competing interests, the next obvious question is who is in charge of the project?
'Who is in charge of the project?'
Second only to delegated authority as a pillar of good project governance is an effective hierarchy of accountabilities which leads all the way up a project organisation through the project and programme managers to the owner of the Business Case. What you might call good operational project governance depends on it.
The usual technique for constructing the fundamentals of operational project governance is the production of a RACI (or one many variants) which details the remit and accountabilities of each and every role. In my experience, this is far too often a tick-box exercise to satisfy a template or a PMO process and not enough credit is given to the clarity it can provide when, on the ground, roles collide or responsibility vacuums open up.
Responsibilities, Accountabilities, Consulted, Informed broken down by functional activities” RACI Matrix. Image Courtesy of article The 4 letters you need when planning your public consultation
Some time ago, I was offered a consulting assignment with a warning that the CTO was both the project architect and its sponsor/executive. To me, this was a clarion warning of the mischief that could ensue from someone being both my ultimate line manager and one of my team members. Success in such a recursive relationship would be entirely dependent on an unlikely synchronicity of priorities that wasn’t going to materialise overnight. It seemed that governance was already being undermined even before I had joined.
'Governance was already being undermined even before I had joined'
As for the tale of the shareholder steerco turning on the team, programme health remained fragile as interventions lacked an associated strategy; decision-making had become sclerotic; workstream leads chose to hide in the shadows whilst others to carried the can; diversity of opinions was a bane rather than a benefit; and seniority within the corporate structure was overpowering the programme hierarchy.
A year on and an interim CTO had joined the mayhem to fill in for the permanent CTO’s unplanned absence; the CEO periodically took control; several external consultants competed for control of the steering wheel; the CFO insisted that you could plan a complex programme using averaged velocity data to derive the critical path; and the supplier was gaming the chaos. Dysfunction had turned to dystopia and a profoundly destabilised programme was now rapidly spinning out of control.
The danger of entering a death spiral
Especially in this era of Agile, some hear the word “bureaucracy” when the word “governance” is uttered as if, like the former, the latter deserves to be driven to the edge of extinction. It is a naïve and irresponsible organisation that does not appreciate the benefits of good governance and the immunity it provides against the risks of future project ill-health. Disorder can be fixed but dystopia is a terminal condition.
The project’s course is now locked into a Death Spiral, a topic I will return to in future.
Further reading: What to do after a project failure
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