Most people will argue that there are lots of different PMOs but when you boil it down, there is really only Enterprise/Divisional PMOs (‘Ivory Towers’) and Delivery PMOs (‘The Coalface’). The Ivory towers being largely removed from Delivery teams; the coalface working directly with the Delivery teams.
Enterprise PMOs (The Ivory Tower)
The Enterprise PMO (EPMO) team makes the rules, providing frameworks, standards, methods, templates, and tools. These guys don't generate Delivery data. Instead, they receive and consolidate data that is generated at the coalface, to provide reporting and insight at the portfolio level.
The other key function the EPMO should be involved in – emphasis on the should because it doesn't happen in every organisation - is the portfolio build and prioritisation. Depending on the level of clout that the EPMO has, it will either drive the entire portfolio building prioritisation, or it will act as a facilitator for that piece of work.
EPMO might also be involved in capacity planning, resource management and practice-management for Delivery roles (e.g. Project and Change Managers, Business Analysts, Testing).
Delivery PMOs
The focus for Delivery PMOs is to safeguard delivery of projects – it’s normally about giving bandwidth back to project and program managers so they can give maximum focus to delivery.
On small initiatives, the project manager is unlikely to have support, so covers all sorts of tasks like finance, risks, issues, dependencies, scheduling – the whole lot - on their own. On larger, more complex initiatives, Coalface PMOs facilitate those tasks, ensuring:
Flow of data and insight to provide feedback to the Delivery team (internal focus) and support reporting outcomes (external focus)
Minimum footprint on the Delivery team through optimised data capture
1st line of defense assurance
When Delivery PMOs do their job well, they save a lot of time and distraction for the Delivery team on the ground, which ultimately contributes to delivery success.
You're probably wondering why I'm telling you the basics when anyone that's worked in a PMO, even for a short amount of time, would surely know the difference between Ivory Tower and Coalface? Of course, you know that…. but are you then able to think about how these roles might be impacted by Agile? How your current role must change to overcome the challenges PMOs are faced with today?
PMOs need to be flexible and adaptable
The biggest shift, that all PMOs need to accept, is that if they are not flexible and fail to adapt, they will fail to meet these challenges and very quickly become irrelevant. Don’t believe me? Then look at the statistics.
Only 41% of organisations with an enterprise-wide project management office (EPMO) report that it is highly aligned to the organisation's strategy (PMI, Pulse of the Profession, 2018)
50% of project management offices close within 3 years (Association for Project Management)
68% of stakeholders perceive their PMOs to be bureaucratic (2013 Gartner PPM Summit)
By flexible and adaptable, I don’t just mean when your PMO is helping Delivery teams. We need to apply the same techniques to the PMO team. Why wouldn’t you want to find opportunities to run more efficiently and continuously improve?
My way of thinking is that it's great to learn new techniques, be they Agile or otherwise and to apply them wherever you think it's going to make life easier. Learn about Agile and then to look for places to apply the techniques. Could the Agile Values be applied in my Waterfall world? Could I improve life in that space? The answer is a massive “YES”.
Something to ponder…
Has it ever occurred to you that the way Waterfall has evolved over time is kind of ‘Agile’? For the last 40 years or so it has been iterated time and again - lots of different people all throwing in their 20 cents worth – and then organisations have adopted what works best for them. Later, along comes this new thing called ‘Agile’ and for whatever reason, people are hesitant to try it out for that first time.
We seem to have forgotten that Waterfall has taken us decades to get close to right. So, when we approach Agile, why do we think that it's got to be perfect first go? Does anyone else think this behaviour is weird?