Design your own ERP PMO for fun and profit
So, you’ve had the green light you were looking for and your organisation or programme has agreed to pay for an ERP PMO. Great News! Now you get to create it, which means bridging the gap between the wonderful concept you have in your head, and the reality of a value-adding ERP PMO providing useful services to support your ERP programme’s delivery and governance.
The first part of that “bridge” between concept and reality is to agree a coherent design. I like the idea of building a PMO to deliver a coherent, value-adding set of services. This article is based on that approach.
That said, you don’t HAVE TO design a PMO around a service concept – you could, for example, build a model around explicit roles (Planner, Support Officer, Administrator) with implicit services. In that case, you can still take what is useful from this article and leave the rest.
I. PMO cost/ size modelling
As in much human-centred design, we begin with a superficially insoluble problem: we have to start somewhere, but wherever we start will be “wrong”, in that there isn’t a perfect sequence where every step is based on unambiguous fact and evidence. We can’t wait for perfection; let’s start “where we are”, knowing we’ll have to back-track and iterate.
?
For this article, let’s start with financial/ budget considerations. How do we estimate the cost of an ERP PMO? You might be surprised to learn that there is no ERP-specific PMO estimating tool – even the biggest ERP vendors with their own bespoke methods don’t touch the subject. Instead, we can use generic PMO estimating methods. Here are three ways of estimating:
?
1. Top down, % of programme cost
This “quick-and-dirty” method is based on the size of the financial investment in a programme. We add 3% to 5% of the TOTAL programme cost, not just people cost.
?
2. Top down, % of programme headcount number
This method is based on the total headcount profile over the life of the programme. PMO headcount can vary from 3% to 10% of total headcount numbers, excluding PMO. As a rule of thumb, you need the higher 10% towards the start when the team is small and the setup work for standards, methods, and so on is intense. Later, as the programme team grows, the PMO % of total headcount can drop (the number of PMO team members might still grow). Still later, as the programme winds down, the PMO % scales back to just enough for normal reporting and governance, plus a little more for lessons learned and archiving.
?
3. Bottom-up, # FTEs needed for planned ERP PMO services
In this case we need to work out what we want the PMO to do, in hours per week, both at individual project/ team/ workstream level within an ERP programme, and at Programme level across all projects. Then we convert to FTEs (full time equivalents).
I’ll look at PMO services in more depth further down. For now, a few examples:
?SUBTOTAL for these 3 services 1-3 is 38 hours per week or 1 FTE.
?
Pro Tip: We can start a first iteration with the top-down view to generate rough-order-of-magnitude costs (ROM costs). At a later stage, when we have done more of the design work described below, we can circle back to refine our cost estimate with credible detail.
?
II. Workstream Modelling
Before we dive into design our ERP PMO Services, it is useful to stop for a moment and look at the wide range of workstreams in a complex ERP programme. Today I just want to share the list, as underestimating the challenge is a chronic problem that plagues many ERP programmes. I’ll look in more depth at how an ERP PMO might support each ERP workstream in another article later this year when I cover ERP PMO Operation.
?
?
Once again, there is no off-the-shelf standard breakdown of ERP workstreams that is holistic enough for my tastes. Some ERP Providers have their own models, which are a good starting point but understandably rather ERP solution centric. The fact is, even so, different people on the same programme may well have different mental models. So please take mine as indicative rather than definitive, and as a model unashamedly aimed at being useful to an ERP PMO.
You could alternatively start with the SAP Activate workstreams, one of the better ERP own models. In that case, tick off the Activate workstreams that map to mine, and decide what to do about my “extra” streams that don’t have an Activate equivalent. But bear in mind I originally added workstreams to compensate for the deficiencies of Activate’s predecessor, ASAP.
?
Programme Delivery Workstreams
We will often find teams or subteams deployed according to these streams:
?
Programme Management & Support Workstreams
These workstreams tend to be the preserve of programme and project management, PMO and other non-delivery specialisms (notably finance):
?
III. PMO Services
PMO services can usefully be defined in terms of four key PMO competence domains (the spheres of action of a PMO), which I modify slightly here for a Programme context:
There are two sources I know of where we can get a ready-made starting point for a catalogue of ERP PMO Services. Both are aimed at generalist PMO audiences, so we can pick and choose those services most relevant to our ERP programme.
The first is Appendix F of the P3O standard from Axelos, which lists (but does not detail) 300+ potential PMO services across 21 potential service areas:
For each service the appendix suggests one or more services at Portfolio Office, Programme/Project Office, and PMO Centre of Excellence (the latter 2 are the most relevant to ERP PMO) and suggests tools, techniques and references.
?
The second source is the excellent “PMO Service Catalogue” from House of PMO. This features 26 service areas and c.250 PMO services. Although there are fewer services compared to P3O, each Service Catalogue service comes with definitions, descriptions, SIPOC tables and KPI suggestions, making it the more useful "accelerator" resource in my opinion:
?
IV. Anatomy of a PMO Service
Let’s take a closer look at one of the PMO Services in the PMO Service Catalogue. If we leaf through the catalogue, we’ll see each service follows a standard profile. This not only makes it much easier to look at any of the 100s of pre-defined services; it also gives a “template” for any new services we invent for our ERP Programme.
Let’s take a simple example: producing a collated report based on multiple project reports. This is in section 23 of the Service Catalogue, “Rollup Reporting” pp.461-474, where several reporting-related services are grouped together.
Service Description:
The collation of individual progress reports into a single report for the programme. A collated summary report will list each project out separately as one line of information.
What the service provides for the customer:
This provides the ERP programme manager with a single summarized report of the individual projects within their area.
Why is this service being offered?
Rather than have the individual reports sent separately to the programme manager, they are sent to the PMO who will collate these together and produce a summary view that focusses the reader on the important items that need management attention.?
How PMO will apply this service
(The catalogue gives some background here which we can use or adapt to suit our programme)
SIPOC table
A SIPOC table is shown for every service in the catalogue, so you’ll soon get the hang of it. It is terrifically simple. If I am to provide a service, someone (Supplier) needs to give me something (Inputs) that I can work with following defined steps (Process) to produce a new something (Output) for another someone (Customer). And that’s as complex as it gets: Supplier, Inputs, Process, Outputs, Customer = SIPOC.
As LinkedIn articles are limited to plain text (no tables), I’ll just list the SIPOC for our report collation service.
Supplier:
Input:
Process:
Output
Customer:
?
How the PMO will measure the value of this service
This can be measured by whether the Programme Manager asks for the report, or suggesting changes or improvements (shows they are engaged and see opportunity for further value), or by checking they are satisfied. (What is interesting here is that while some services can be measured with numerical/ quantitative KPIs, we shouldn't overlook simple qualitative KPIs)
Criteria when the PMO will use this service
?
V. Top ERP PMO Services
A downside of these great PMO services resources is that there are an awful lot of services and a typical ERP Programme doesn’t have a lot of time to ponder them all before acting. So many potential services! So little time! Let's prioritise.
?
These are favourite PMO services that I think give the best “bang per buck” in an ERP Programme:
?
Planning and plan-based reports
ERP is complex, so the services of a good PMO planner are a good investment. But keeping plans up to date is burdensome for the PM, even with a planner.
?
Governance secretariat
PMO has fought hard for years to be seen as MORE than administration. However, we can still add value and keep a finger on the programme’s pulse through administration, so we mustn’t see it as beneath us. Supporting key ERP governance bodies – of which more further down! – not only helps those bodies be more efficient and effective, but means the PMO is aware of latest developments.
?
Change Control
In ERP, we need to establish a set of baselines which are protected by robust change control. Solution architecture, phase schedule, budget and planned quality/ assurance levels are among the obvious candidates. Some of these have both a programme and a contractual meaning, so coherent governance of changes – which could involve solution sign-off, approval of a revised schedule, an agreed change of funding AND a change to the negotiated contract – needs to be thought through in advance.
?
Managing uncertainties
Risk and Issue management is a “given” – although that doesn’t always mean it is done well or adds value. Dependency management is of above-usual importance, given the many workstreams in ERP. Assumptions also need to be tested – traditionally a weak area if assumptions can’t simply be confirmed or denied by talking to the right person, but Agile thinking has given us some new tools and approaches here.
?
Methods and templates
My heart sinks when I see LinkedIn posts boasting of links to hundreds of PM templates. A template on its own is nothing. Where we can add value is by designing a method or playbook in collaboration with knowledge-holders on the programme. Then, where it makes sense, we provide templates, completed examples, “how to” guides and people support to embed the ways of working our agreed method requires.
?
Quality & Assurance
Arranging and supporting process walk-throughs, quality gates, and conference room pilots make a huge difference in surfacing problems early, building confidence in the programme, and making sure people really are ready for change.
?
Action tracking
Not just the normal everyday meeting actions, but also:
The help needed is to chase for updates and closure, so the number of open items is kept under control.
?
VI. ERP Governance Model
While we’re still designing our ERP PMO Model, we should simultaneously design (or check someone else’s design of) the governance bodies that play a major part in a system of “guard rails” that keeps an ERP programme on the path to success. A smaller ERP programme may combine these bodies; a very large one may need to augment them. Either way, we need to spell out the links between the governance bodies themselves, and between the bodies and our PMO services
?
?
Solution Design Authority
A body to review and approve designs, approaches, strategies and technologies. In principle this is an advisory body providing an opinion rather than a decision. In practice, it’s often a decision-making body in all but name, because a lot of expertise is at this level.
?
Programme Change Authority
A body to consider Change Requests, which – without such support – have sunk many an ERP programme. The PMO needs to give strong support to PMs and Business SMEs as they consider the implications of potential changes and rule them in or out. This is another “in principle” advisory body that in practice often takes decisions so long as within budget.
?
Finance & Commercials Committee
A body to support the management of budgets and contracts – which are often confidential, so cannot adequately be covered elsewhere.
?
Business Advisory Group/ Reference Group
A body to support and scrutinise the work to ensure the organisation’s staff are ready, willing and able to accept the delivered solution, deliver the new capabilities, and realise the forecast benefits.
?
Programme Board/ Programme Steering Committee
A body to provide the formal role of oversight on behalf of the business; control exercised by advising, directing and intervening in escalations or exceptions; decision-making between options; ensuring the programme is integrated with strategy and with wider business-as-usual. This is the most senior governance body, and is supported by the specialist authorities and committees previously listed.
?
The PMO role for all these bodies includes:
The PMO also needs to ensure the meeting cadence is helpful, e.g. agenda items for the Steering Committee should have cleared the lower bodies first and this should not be a delaying factor.
?
VII. ERP PMO OKRs, KPIs and SLAs
How will we know if our ERP PMO is any use? We COULD wait to find out after implementing it, but that seems a bit late, no? Let’s be proactive and try to agree ERP PMO success criteria up front and design our PMO services to achieve them.
?
To do so, we adapt the concepts of OKRs (Objectives & Key Results), KPIs (Key Performance Indicators) and SLAs (Service Level Agreements):
Our starting point is the wider Organisation Vision, Mission or Strategy, part of which is realised by the ERP Programme. The ERP Programme in turn drives the vision of what the ERP PMO is to achieve. Let's quickly run down through the layers in the picture above.
Our ERP Programme Vision & Business Case gives rise to ERP PMO Objectives or goals. Each objective, if attained, will give us some PMO Key Results Areas - concrete results in various areas of our PMO activities that we can observe and verify. These together form our PMO's OKRs - objectives and key results. At design stage, we can have as many objectives as we need. Just be aware that when it comes to implementation we need to pace ourselves and prioritise. We ought not try to meet all PMO objectives on Day 1, Month 1 or even Quarter 1.
The next step is to come up with some value-adding PMO Services that will contribute to these results. You can refer back to my previous post on favourite services, or look at the PMO Service Catalogue for ideas. Each objective might be supported by one or more services. Conversely, an objective with no linked services needs investigation – how are we to deliver it?
When we've defined our services, what are our key performance indicators? Here I like an etymological breakdown of KPI: "What key things do we want to show, that tell us whether something is flourishing and brought to completion?" Some care is needed here - our PMO Service KPIs measure whether our services are being performed well. That might not mean the programme is going well. Like an altimeter in a plane, if the plane is going down and we show clearly and accurately the plane is going down, our service KPIs should be good!
The final type of PMO metric is the SLA or service level agreement - here used in a simplified way. A service may have 1 or more PMO SLAs that need to be met if we are to provide the service usefully. For example "if you inform us of a programme board 3 days in advance, the PMO will attend, take the minutes and publish them within 2 working days [2 SLAs for 1 service] or "we'll always have latest project metrics updated on our ERP Programme dashboard by COB Monday" [1 SLA, 1 service].
?
VIII. ERP PMO Skills & Capabilities
Up to now we have been designing our ERP PMO remit and services as if our only challenge was to be clear what we want and why we want it. Which is fine – in fact I advise folks to design ANYTHING ERP-related iteratively. There are too many moving parts to get it straight in our heads in one pass.
But now it’s time to temper our design with a little piece of reality. The organisation running the ERP Programme might not have solid project delivery capabilities. Why would it? Most organisations exist for their operations. Factories build, shops sell, universities educate, public bodies provide services. It’s normal to have a high operations maturity but be a bit muddled when it comes to delivering projects. How do we design for organisational project & programme maturity?
My favourite thinking tool here is the snappily titled “P3M3” from Axelos – the Portfolio, Programme & Project Management Maturity Model. The P3M3 idea is that we can describe maturity for project & programme management practices on a scale of 1 to 5.
L1 = Awareness: people are aware that, say, "Risk Management” exists, but they don’t all do it, and if they do it’s ad hoc each time.
L2 = Repeatable: individuals are “doing” Risk management – but re-using or repeating what they did before; it’s not standardised across a team.
L3 = Defined: At this point there is a defined, standard way of doing Risk Management across the teams.
L4 = Managed. Here we see practices are measured e.g. with KPIs. The organisation is managing its consistent application of the L3 standard.
L5 = Optimized. Now we see “continuous improvement” – there’s a feedback loop applying learning from the measurements of L4.
How to apply P3M3 sensibly? Use your P3O cheat code! Whip out your P3O Manual, Appendix E, and for each process you can figure out: (a) where the organisation is today, and b) where it needs to be to run the planned ERP PMO services.
Tip: aim for a maturity level as high as needed BUT as low as possible to start with. Embed and stabilise simple processes before deciding where the next improvement needs to be.
The process perspectives covered in P3M3 are:
Each topic is covered from a Portfolio, Programme and Project viewpoint. For an ERP PMO, I think we need to look primarily at Programme maturity (Table E.2) and Project maturity (Table E.3). As a rule of thumb, the PMO can work internally 1 or 2 levels ahead of the programme team. Any more, and what the PMO is trying to do will be too sophisticated, probably neither right for colleagues nor grounded on solid foundations. Let the team advance a level to catch up before taking another step up the maturity staircase.
?
IX. ERP PMO Team Competency
As we design our ERP PMO, we need to temper our enthusiasm to grab our bag of good practices and implement everything, everywhere, all at once, with a few inconvenient realities. We just talked about the constraint of organisational maturity; another important constraint is our own people's skills. Are WE good enough for the job ahead? The people in our PMO – ourselves included – might not tick the box for every skill and experience we’d like to have. We haven’t looked at that before, so let’s do it right now.
?
?
Service-based skills and experiences.
If we want to design our ERP PMO around the high-priority value-adding services it should offer, then we should reach right away for the PMO Competency Framework from House of PMO. This defines the knowledge, skills and behaviours needed by PMO Administrators, Analysts, Managers and Directors across 24 PMO competencies that align closely to the 26 Service Groups in the PMO Service Catalogue.
Each of the 24 competencies is described in 4 PMO contexts:
Tip 1: For an ERP PMO, I recommend looking at the Programme and Centre of Excellence contexts.
?
At each level, the framework then sets out knowledge, skills and behaviours needed for a PMO role in order to reach one of 4 proficiency levels:
Tip 2: as a rule of thumb an ERP PMO is going to need someone – but not necessarily everyone - to be at advanced or expert level for each of its high-priority services.
?
Role-based skills and experiences.
Whichever framework we use to assess our PMO staff skills and experience, if we compare the proficiency level we have to the one we need, both as individuals and as a PMO collective, we’ll likely identify gaps that we can then plan to fill. That could mean formal internal or external training. But don't undervalue cross-training on the job, self-study, PMO webinars, taking part in professional associations, PM/PMO conferences, or communities of practice.
X. ERP PMO Tools
It is as possible to light a fire by knocking two flints together now as it was 300 or 3,000 or 30,000 years ago. But I’ve got to be honest, I’m happy with electric light and heat, or using safety matches if I need a real flame. Similarly, folks were running programmes 300 or 3,000 years ago without tools, but that’s no reason to do it now. So, let’s round out our ERP PMO Design by thinking about the tools and techniques that can automate, accelerate and otherwise help us.
One approach is structured and logical but only takes us part way, as the output is a set of tool ideas and requirements, but not a tool. Once again, we can reach for the P3O Guidance and do the following:
Section 1.2? Overview of tools and techniques
Section 1.3? Benefits of using standard tools & techniques
Section 1.4? Critical Success Factors when introducing tools and techniques
Section 1.5? P3O Tools. Table 5.1 on page 101 shows core functions of enterprise PPM tools for Portfolio Management, Resource Management and Programme & Project Management. We are interested in the latter 2. Table 5.2 ?on page 102-3 lists key questions for developing a tools requirements document
Section 1.6? P3O techniques – skip past the Portfolio Management items to see some ideas for dashboards, information portals, and facilitated workshops the PMO can implement/ offer.
When we have worked out our requirements, we can check if the organisation already has suitable tools somewhere (in IT, say, or Product Development) and arrange to adopt those. Otherwise – with appropriate involvement from Procurement/ Purchasing colleagues – we can check what is available on the open market. PMO and Project Management exhibitions are a great place to do this as vendors are very happy to showcase their offerings. We can visit several stalls, run through our requirements, and identify a shortlist of candidates for more formal consideration.
?
A second approach is to start with real, existing tools we already know and implement them. In fact, the client organisation or ERP delivery partner may mandate certain tools e.g. for Finance management or for tracking contract delivery, respectively, such that checking what the market could offer is a waste of our time, for better or worse.
The downside of starting with known tools is we might reach for the familiar rather than work out what is really required. For example, a tool designed to support individual projects might BOTH be unsuitable for the complex interrelated projects that make up an ERP Programme AND have no way of supporting the overarching programme-level tasks that cut across many or all projects.
?
Finally, here’s my list of indispensable tools for an ERP programme:
??
XI. ERP PMO Design Summary
We’re at the finish line of our ERP PMO Design! Let’s quickly summarise what we have covered:
?
There are just two things left to do.
A. Gather our Design into an appropriate, coherent format. We can treat it like a programme blueprint, a requirements document, a solution specification, a User Story backlog – whatever works in our organisation. We don’t want to bury ourselves in bureaucracy, but we need enough of a design baseline to be able to verify later whether we have built the damn thing or not!
B.?Prepare an implementation plan. We can argue to push this into the next stage of ERP PMO Implementation, but I think at least a high-level plan – enough to show the design is implementable – is no bad idea in the Design stage.
And that’s it: the end of this ERP PMO Design article. I hope it is of some interest or use in your ERP programme.?
XII. Sources & Resources:
Guidance & Standards
P3O (Portfolio, Programme & Project [Management] Offices) Guidance: https://www.zindiak.co.uk/products/p3o%C2%AE-portfolio-programmes-and-project-offices-guidance-manual-latest-version-paperback-axelos
PMO Competency Framework: https://www.tsoshop.co.uk/product/9780117094604/PMO-Competency-Framework-2nd-edition-Paperback
P3G (Project, Programme & Portfolio Governance) Guidance: https://www.tsoshop.co.uk/product/9780117093768/Project-Programme-and-Portfolio-Governance-P3G-Paperback
PMI P3M (Portfolio, Program & Project Management) Governance Standard: https://www.pmi.org/standards/governance
?
Training
P3O (Portfolio, Programme & Project [Management] Offices) courses: https://www.pmolearning.co.uk/certified-pmo-courses/p3o-certifications/
Essentials for PMO Managers course: https://www.pmolearning.co.uk/certified-pmo-courses/pmo-essentials-certification/essentials-for-pmo-managers/
P3GP (Project, Programme & Portfolio Governance Professional) Course: https://www.pmolearning.co.uk/certified-pmo-courses/p3gp-project-programme-portfolio-governance-practitioner/
?
Other resources
SFIA (Skills Framework for the Information Age): https://sfia-online.org/en
APM (Association of Project Managers) competence framework self-assessment: https://www.apm.org.uk/resources/find-a-resource/competence-framework/
House of PMO self-assessment: https://houseofpmo.com/members-home/members-self-assessment/
PMI (Project Management Institute) PM skills self-assessment: https://www.projectmanagement.com/deliverables/541423/pm-skills-maturity-level-self-assessment#_=_
Human First SAP Advisor | Mom | Empath
1 天前Garret Beggan thank you! I will surely read this!
PMO, Governance & ERP Specialist
2 天前Affiliation: I am an authorised trainer for P3GP and an approved trainer for Essentials for PMO Managers, both via PMO Learning Ltd. I am going through the approval process to become a P3O trainer. Other training providers are available for P3O and for P3GP. "Essentials for PMO Managers" and the other "Essentials" courses (for PMO Administrators, PMO Analysts, and PMO Directors) are only available from PMO Learning.