One of the most common questions posed to me by Programme Managers is:
 
'How big should my PMO be?'

This seemingly innocuous question has a number of hidden elements...do I have too many people?...do I have too FEW people?...how do I compare to my industry peers?...how do I compare to non-industry peers?...

All intelligent questions, and if answered accurately should allow you to take the first step in addressing some of the core problems faced by PMOs across all geographies and industries...

- Not delivering against expectations;
- Not delivering against the key stakeholder priorities;
- Not delivering the high-value-added activities; and
- Ultimately losing the confidence of sponsors and colleagues.

By utilising this benchmarking exercise you can support your case for more resource or help you understand that your PMO could be inefficient because of unskilled resources (a very common issue) or a lack of automation for administrative activities.

So let's begin...

The first stage of mathematical modelling took a large number of companies with mature operational PMO functions and plotted their PMO headcount against the number of people they were supporting. For this first stage we assumed all variables regarding PMO functions were normalised (in the following pages we go into more detail regarding those variables and include weighting factors for each to allow you to drive a more detailed estimate).

The table below shows the non-linear correlation between these two variables:

TABLE 1

Programme Headcount	30	60	120	200	300	500	1000
PMO headcount	2	3	5	7	9	13	20

For the more mathematically minded amongst you the simplified model you can use is:

TABLE 2

PMO FTE = 1/5 (N2/3)

Where: PMO = Programme Management Office FTE = Full Time Equivalent N = the total headcount the PMO is supporting

You should calculate the estimate for your PMO as we will be using this later on in the article to create your more detailed estimate. This figure is a good first comparitor to your current PMO size. If the figures are wildly different (e.g. a different order of magnitude) you may find the following sections help explain some of that differential. The next stage is to understand the variables that will impact the size of your PMO...

This section gives an overview of the key variables that have been included and excluded from this model. Whilst it is clear that all of these variables play a part in the resource size of a PMO we have not included them in this model because of the subjectivity in measurement. Our recommendation is that you increase/decrease contingency according to the secondary variable levers.

TABLE 3 - PMO Considerations INCLUDED in Estimating Model

Consideration	Variable	Description
Programme Headcount	Headcount	The higher the supported headcount the greater administration overhead for timesheet creation, report generation, process governance and compliance management.
Functional Complexity	High, Medium, Low (by function)	The required complexity of the PMO function will obviously contribute to the necessary support headcount e.g. A simplistic time-sheeting and high-level Financial reporting PMO will clearly need less headcount than a full Quality, Financial, Resource, Procurement, Scope, Planning, Time, Risk/Issue management function.
Enabling Technology	High, Medium, Low	The wider application of toolset automation significantly reduces administration. Options include (from low to high automation/enablement): (1) bespoke or repurposed Excel templates, (2) MS Project/Project Professional or equivalent being used in conjunction with Excel, (3) MS Project Server, EPM, Niku, Mercury ITG for the range of simple automation to full process and lifecycle automation. Clearly these factors will be largely dependant on the budget/skills available for implementation.

TABLE 4 - PMO Considerations EXCLUDED from Estimating Model

Consideration	Variable	Description
Strategic Delivery Model (SDM)	Locations	The higher the number of locations involved the more resource is required centrally and locally. Split working attracts additional complexity such as time (differing time zones), cultural (differing 'ways of working'), communication (differing languages and using only e-mail, messenger, telephone etc)
Management Support	High, Medium, Low	Support from the Senior Executive/Management team, simplicity of reporting lines and clarity of programme vision (inconsistent vision will lead to rework, significant ad-hoc reporting and reduced decision-support) contribute to a reduced support overhead.
Programme Management Maturity	High, Medium, Low	Initial process/policy/contract/template maturity all provide an environment within which activities can be supported more efficiently. These processes may exist in other business areas such as HR, Finance, Contract Management, General IT etc but can be repurposed for the management of the programme.
PMO Resource Capability / Seniority	High, Medium, Low	Greater experience and team skills correlate to lower time for PMO functional execution and decision-making. The more capable and experienced PM team members are, the more efficiently PM can be setup and operated.
Engagement Workforce Capability	High, Medium, Low	The experience of normal engagement staff in working with timesheeting, quality assurance, planning, financial reporting etc will reduce the amount of time a PMO will spend doing ongoing training and awareness sessions and general support.
Programme Delivery Complexity	High, Medium, Low	The (1) higher the number of organisational/delivery entities involved, (2) higher the risk (which drives volatility of PMO requirements), (3) governance model (is the PMO autonomous for a specific project or does it exist within a matrix of conjoined PMOs) the more PM resources will be required. In many instances complex programmes will devolve responsibility for some PMO activities to workstreams and maintain the strategic vision, PMO engagement plans, standardised processes, templates and reports centrally.
Diversity of Programme Scope	High, Medium, Low	Diversity of scope will drive different requirements for reporting and governance mechanisms e.g. EV application, status reporting, Risk and Issue management and metrics requirements (which will be different for an outsourced Service Delivery function and a conventional programme of project work.
Phase of PMO Lifecycle	Set-up, Operation	The set-up phase of a PMO requires more resource to successfully develop, implement and bed down processes/templates/toolsets. Once the PMO is operational and these assets have reached maturity there is a reduced support requirement for PMO resources.

The next part of the process is inclusion of the defined variables into the mathematical model...

Now that we have a high level estimate and understand more about the variables that contribute to PMO sizing we need to come up with our Secondary Estimate.

The functional categories defined below are defined as general PMO functional areas but you will note there is strong correlation to standard project management methodologies such as PMBOK, CMMi and PRINCE2. 

Whilst the next stage is quite straightforward you should approach the creation of your Secondary Estimate with care and ensure you are calculating your data correctly. The three steps are as follows: 

(1) Apportion your High-Level Estimate to the Lower Level Functional Areas as defined in Table 6 (Column A)
(2) Determine the 'Movement' (Column X) by referencing Table 5 and add this data for each Functional Area; and
(3) Calculate the new FTE estimate for each Functional Area (including the increase/decrease) and then add together to get a new Overall Secondary Estimate for your PMO size. 

To make this process easier to understand I will use use a worked example...

Now in the example I'll be using I have a 350 person programme to support. As previously defined I want to apportion the High-Level Estimate we should have calculated in the first part of this article. For a 350 person programme this equates to:

PMO FTE = 1/5 x N^2/3 = 1/5 x 350^2/3 = 1/5 x 49.66 = 9.9

first step is to apportion the 9.9 FTEs by Functional Area. You can see below I have done this by multipying 9.9 by the 'Apportionment' column to get a estimate for each area.

TABLE 5 - High-Level Estimate Apportionment

Functional Area	Apportionment	Normalised Estimate
Measurement and Analysis	9%	0.89
Status Reporting	9%	0.89
Resource Management	10%	0.99
Issue & Risk Management	11%	1.09
Change Control	10%	0.99
Financial Management	13%	1.29
Project Scope & Definition	9%	0.89
Governance / Organisation	13%	1.29
Plan set up, maintenance & tracking	11%	1.09
Deliverable Management	7%	0.69

The next stage is to define your assumptions in regards to the complexity of the functional work your PMO is undertaking and the level of automation that is supporting each functional area.

If we take an example for Financial Management: In this example I'm undertaking some standard budgeting, Earned Value and forecasting so I'll assume that is 'Medium Complexity' however I am trying to support it using a combination of basic admin-heavy Excel Spreadsheets which I feel is 'Low Automation'. Using the reference table below I can then determine that the 'Movement for Financial Management is 'Small Increase'. This basically means the baseline FTE figure you calculated in Step 1 will be uplifted slightly when we move into Step 3. Therefore:
 
TABLE 6 - Assumption Reference Table

Movement	Variable Mix
Large Decrease	Low Complexity, High Automation
Small Decrease	Med Complexity, High Automation Low Complexity, Med Automation
No Change	High Complexity, High Automation Med Complexity, Med Automation Low Complexity, Low Automation
Small Increase	High Complexity, Med Automation Med Complexity, Low Automation
Large Increase	High Complexity, Low Automation

You should determine this movement for all Functional Areas depending on the mix of automation and complexity (both of which need to be determined for each Area on an individual basis). If you feel that a Functional Area listed here is outside the remit of your PMO then don't include the estimate, for that area, in the final calculation.

The final step is to create your more detailed estimate...

Well done so far. You are nearly ready to unveil your Secondary Estimate for the size of your Programme Management Office (PMO). I will assume, in my example, that, for all Functional Areas, I am facing Medium Complexity and Low Automation. Hence this will produce a small increase for each Functional Area.

You can see in Table 6 below the 'Movement' factors (which differ in the model depending on the Functional Area) and also the original estimate and the new estimate using the 'Movement' factors.

TABLE 7 - Before and After Estimates

Functional Area	Apportionment	Normalised Estimate	Large Decrease	Small Decrease	No Change	Small Increase	Large Increase	Secondary Estimate
Measurement and Analysis	9%	0.89	-50%	25%	0%	25%	50%	1.11
Status Reporting	9%	0.89	10%	5%	0%	5%	10%	0.94
Resource Management	10%	0.99	40%	20%	0%	20%	40%	1.19
Issue & Risk Management	11%	1.09	10%	5%	0%	5%	10%	1.14
Change Control	10%	0.99	-10%	-5%	0%	5%	10%	1.04
Financial Management	13%	1.29	-60%	-30%	0%	30%	60%	1.67
Project Scope & Definition	9%	0.89	-50%	-25%	0%	25%	50%	1.11
Governance / Organisation	13%	1.29	-80%	-40%	0%	40%	80%	1.80
Plan set up, maintenance & tracking	11%	1.09	-30%	-15%	0%	15%	30%	1.25
Deliverable Management	7%	0.69	-50%	-25%	0%	25%	50%
0.87

The final analysis, for my example, shows that before using the more detailed model my High-Level Estimate was 10.1 FTEs (which would correlate to a headcount of 9 people if you assume approx 10% overtime). After the Secondary Estimate we have a total of 12.1 FTEs (this would correlate to a headcount of between 10-11 people depending on your overtime estimate).

So by now you should have created your first estimate for the size of your PMO. But you may still have some questions...

Once you have calculated your FTE Equivalent for each functional area you will have a total estimated headcount for your PMO.

There are a few important points to note before you head off and use these numbers in anger! ...namely;

- The mathematical model that supports this article has been derived from twenty-two best practice engagements (a new version will come out in 2008);
- You should remember to uplift/decrease your estimate based on the additional variables we discussed earlier;
- If your actual headcount is significantly lower than the estimate, common reasons are that your people are working a lot of uncharged overtime (remember an FTE is a Full Time Equivalent based off a standard working day - usually about 8 hours a day), you have strong support from senior management (and clear authority), you have strong automation of processes and tools or you have a very experienced and skilled workforce; and
- If your actual headcount is significantly higher than the estimate common reasons are that your team isn't working as efficiently as it could on direct PMO value-added activity or is doing work that isn't strictly PMO activity, you have an unskilled team, you have little support from senior management (or limited authority) or your level of automation is much lower than you think.

Whilst this isn't an exact science it should give you a good indicator of how big your PMO should be and some of the factors that contribute to it's size.