If you asked someone what their definition of a PMO was, you’d probably get a wide variety of answers. Some responses might include project managers, administrative function, the process police or even the what now?
The definition given by the Project Management Institute states that:
‘The Project Management Office (PMO) is defined as “a management structure that standardises the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques” (PMI, 2013a, p. 10)’.
And although this description is both succinct and accurate, perhaps it’s better to discuss why the function exists, and some of the solutions it provides than to impose a static definition. Further, not all PMOs are created alike, as they will vary in approach and method depending on the maturity of the PMO, the organisation it serves, and the individuals who work there.
The PMO definition also overlooks a major aspect I feel is key: engagement and support. This engagement can be via the provision of regular status reports required by management in order inform strategic initiatives, or providing templates for the artefacts used by project managers to mark gateways and monitor progress. But this engagement and support isn’t limited to the confines of project delivery; it extends to cover the whole project life-cycle from pipeline through to embedding into BAU.
Without it, there’s a risk of making ineffective prioritisation decisions, a lack of visibility into resources leading to bottlenecks, and inconsistent approaches to planning and managing projects. Good governance underpins all this, ensuring fairness and consistency is applied to all projects.
Still, there often remains a perception that the PMO exists to enforce a rigid set of rules that apply to all people and situations, ready to deliver a scolding if someone forgets to dot an ‘I’ or cross a ‘T’.
I’m reminded of an episode of Futurama, where Hermes Conrad, the resident accountant and bureaucrat, is given the instructions to eject a box into the sun. He’s ticked both items off his list (box, sun) and is all ready to push the button when this happens:
Obviously, I’d never fire my colleagues into the sun and neither would he, but there is a tiny part of me that understands his split-second of hesitation, because both items were ticked off the list and the job was nearly done! It’s this kind of bloody-minded focus on process that it’s safe to say PMOs are in danger of falling prey to. When processes are dictated by governance and informed by user/stakeholder needs, they will ensure compliance and maintain standards. However, it can be easy to lose sight of the wood for the trees, and become blinkered by inflexible adherence to processes that can and should be catered to user needs.
So how can agile methodology apply to the PMO function? On the surface, the concept of an agile PMO might seem like an oxymoron, particularly when the accepted PMO definition fits so well with waterfall concepts and principles. Cards on the table: when I learned CDS was promoting an agile mind-set, I was somewhat confused as to how this could apply to me, and very quickly found myself on a whistle-stop tour of the change curve model.
First, I hopped on a coach to Anger-Ville, where I stewed and muttered “This is the worst kind of change – the kind that affects me!” before continuing to Panic City (population: me). I realised it was rather lonely there, and the weather was rubbish. So I made a commitment to learning all I could about how I could apply agile practices to my role as PMO Manager
A couple of crucial things got me on the train to Acceptance-land. One was the inaugural CDS all staff meeting, a brilliant day of reflection and planning, with a focus on our objectives and overall mission in a relaxed atmosphere. I also attended the GDS Digital and Agile awareness course. This helped give me a better idea of how to apply agile practices and why. In particular, I began to realise that understanding user needs is crucial – and when I realised my stakeholders were just users by another name, I felt like I crossed the agile Rubicon.
I began researching and reading about how other PMOs apply agile methods, and was both alarmed and excited to discover that there isn’t really a consensus of opinion on how to run an agile PMO. Alarming, because this means there are no set guidelines to follow. And yet, exciting because there are no set guidelines to follow. What we do have are key principles that can be applied to existing practices. Using gov.uk’s digital service standard criteria as a focal point, I realised that I’m applying several of the criteria already.
The need to iterate and improve frequently has always been a feature of my reporting, though I never thought of it that way, I thought I was just fixing things. When I look back at the very first dashboard I created, I now cringe at the layout and level of detail it provided. It looks totally different now, though I wasn’t able to improve it overnight, and there’s still room for improvement. But whereas before I felt like this ought be a responsibility that I alone needed to tackle, I now see that the best way to improve is to constantly re-evaluate and communicate with stakeholders/users to achieve these iterative improvements. After all, I’m creating the reports for them, not for the governance.
Instead of worrying that my management reporting would be become obsolete under agile, I began conducting user research in order to review the current dashboard and the management information included. I am compiling user feedback to ascertain what is working and what isn’t, including the format and frequency. It has the bonus of leading to improved communication, and feels like an exercise in mapping the as-is process, isolating the pain points and then creating a to-be process, all very familiar stuff! Except this time, I’m open to the fact that it’s not a process to be carved onto the proverbial stones carried down from Mount PMO.
I believe that by embracing the concept of user needs, the PMO has an important role to play in CDS’s agile culture. The last stop on the change curve tour is commitment (or Commitmentopia, to continue the travel analogy). By continuing to research and discuss agile methodology, I am better able to understand how it applies to the PMO, and how this will enable CDS to achieve its mission statement of leading the digital transformation of the council’s systems and services, and the digital enhancement of our borough.
Rebecca Toennessen is the PMO Manager for Croydon Digital Service.