A few years back I was parachuted into a major European airline that, to all intents and purposes, had no coherent project initiation or delivery processes. It had a primitive PMO and was delivering projects in a wild west environment where those with the biggest firepower in the organisation got what they wanted. All was laid bare in a damning competency maturity assessment.
Something had to be done.
Digital had been carved out of IT, creating 2 relatively arbitrary fiefdoms, the one operating increasingly sophisticated Agile and the other stuck in some sort of pre-PRINCE2 time warp. There was nobody responsible for product development or enterprise architecture and flashpoints arose over sharing or borrowing resources and technical dependencies because there were simply no unifying processes.
Management knew there was serious and unsustainable dysfunction, but they gravitated to developing a full service PMO as the catalyst for better times. Based on my experiences, however, it seemed obvious that a full service PMO would never be the panacea and could only be part of the solution. Where management saw only silos of PM’s, BA’s and so on that needed to up their game in parallel with standing up the PMO, I saw one integrated transformation opportunity to remodel the whole relationship between project delivery, portfolio oversight and assurance and the business beyond.
Law enforcement model of the PMO
I have worked in many organisations where the PMO was regarded with about as much warmth as the Health & Safety Inspectorate. Too often they talked themselves into a reputation as the bad guys who on PMs’ backs to complete weekly reporting templates that were poorly designed, frustratingly complex or annoyingly simplistic and so provided an incentive to bury any news that wasn’t 100% good.
They imposed rudimentary risk register templates which, amongst other failings, overlooked the value of proximity or post mitigation and so pushed the risk profile of projects unnecessarily onto the naughty list, giving PM’s an incentive to massage their risks.
PM’s would find themselves navigating a stage/gate process designed pre-agile that just doesn’t fit and so has become a periodic flashpoint. Or perhaps the bone of contention was financial reporting that was a monthly chore because the PMO provided a set of actuals so muddled that the PM community called it “the gobbledy-gook report”.
I have experienced all of these stress-points and the harm it does to a relationship that should have been one of mutual support but had become irredeemably adversarial. Underpinning all these stresses were PMO’s that had been fashioned in a parallel universe, often physically remote from project delivery, staffed by administrators with scant delivery experience, stricken with the collective presumption that PMs are a slippery bunch of rebellious mavericks with no respect for company rules. Just do a simple google search and see how many graphics portray the PMO as detached from delivery or at the centre of the whole governance universe
It’s a flawed model that results in us-and-them relationships with delivery, a PMO that is responsive only to its organisational masters and puts little value on consultation with and consent from those who must work within its ideas about what’s important to regulate projects. Deriving no benefit, inevitably PM’s will pay lip service to a PMO’s many demands.
PMO reimagined as a community service
So, back at my airline, here was a unique opportunity to forge a new way of doing things, built on the notion of the PMO as a service provided to a community of interconnected interests; symbiotic and with bilateral benefits; a partnership. In this way, the working relationship could become one of continuous collaboration, where deficiencies were solved by cross-discipline teams with a mutual interest in the whole thing working in harmony.
Utopian, maybe, but hardly revolutionary!
evolving a transformation programme
So, I made the case for a transformation programme which would initially ignore organisational and functional boundaries and take at a holistic view of the future state; disregard the detail and envision a mature project delivery environment from 100,000 feet and ask the simple question “what capabilities does a joined-up, efficient, responsive and well-motivated project delivery organisation look like?” At this early stage, no point in worrying about responsibilities and ownership; just focus on the project community’s collective capabilities.
After taking soundings from various specialisms, I came up with 8 capability groupings as the basis of a blueprint for the new project delivery organisation, which looked something like this:
Combining the capability overview with the vision of the PMO as a community service suggested a modest but important upgrade to conventional textbook graphics, encapsulating the scope, philosophy, and ambition for the proposed transformation programme.
The first step was to assemble a team of highly engaged SME’s. Divided into 6 thematic workstreams and no particular alignment with the capabilities, they would be responsible for defining and delivering related groupings of the component deliverables. This deliberate dissonance would reduce the risk of land grabs and the dominance of one interest group over another in particular areas of project activity. All interests needed to have some sort of stake in every aspect of the project eco-system. Even if at the end of the transformation the PMO, say, might own and operate Financial Tracking, other interests such as PM’s needed to contribute to the development of the processes, templates and responsibilities that would flow from the Blueprinting stage.
Roles & Permanent Organisation
(eg Architectural Review Board, Portfolio Approval Board)
Organisational Interfaces & Stakeholder Engagement
Methodologies, Techniques & Toolkits
Financial Tracking, Forecasting & Reporting
Programme and Project Governance, Assurance and Quality
Demand/Capacity Management
Each workstream would be led by whoever was best suited to the assigned theme but comprise cross functional representatives to ensure the concept of community was embedded throughout.
It was then for the workstreams to come up with their own development and implementation plans organised into tranches that would involve different combinations and permutations of communities from the project delivery universe, including stakeholder community representatives, as needed.
The need to embed new ways of working was at the forefront of our thinking and we believed it would take 18 months to truly transform the organisation.
Whilst all this planning was taking place, we felt there was an immediate need to put the theory into practice and launch a PM and a separate BA professional community to ensure that, from the outset, these key specialists had a stake in what we were doing. Test and Architecture would follow.
Implementation and beyond
Of course, the integrity of this vision was stress tested over the ensuing months as we had to contend not only with departmental divergence but also a disconnected and antagonistic stakeholder environment. The erosion of idealism due to politics and organisational dysfunction is well understood so best to leave the implementation saga to a whole different chapter.
However, it is worth paying a last visit to the post implementation vision and how change to the project delivery eco-system would be managed.
If ownership was to lie collectively with the various project communities and not be dominated by one particular interest, then it followed that the management of change should be a collective responsibility. As mentioned, professional communities would exist for the PM’s/scrum masters, BA’s, Testers and Solutions Architects.
These entities would meet and co-operate for the purpose of professional development, to suggest improvements and perhaps be gateways for changes proposed from outside the delivery eco-system. Though not constituted as a community, the PMO would be an important clearing house for new ideas which, ultimately would find their way to some sort of community of communities forum to refine, approve and embed the change.
Looking back on looking forward
Looking back, I still feel strongly that the principles I championed and the goals we set ourselves as a team were worthy above all for promoting an operating model designed to be consensual, self-renewing and mutually supportive. In this Brave New World, the PMO would stand neither apart from nor at odds with the rest of the delivery organisation but operating in partnership with all the interests that interact with a project during its lifecycle.
It is, sadly, a rare treat to be able to re-imagine the architecture of a whole project eco-system but there are still universal lessons to be learnt such as how an established PMO might measure its performance. My tip would be do resist cold KPIs such as how many reports have been produced on time, but set objectives centred on collaboration, community, and service.
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 Linked In
