Do I really need a Program Management Office (PMO)?

RD-Veeva_blog-header

Part 2 in a series exploring project improvement through the use of a PMO implementation

In a previous blog, we looked at how a program management office (PMO) can develop as a natural outcome of your company’s growing needs. We looked at the initial stage of this development process, using a fictional example company, “A+ Emerging, Inc.”

In this post, we look at how the initial PMO structure continues to develop at “A+ Emerging, Inc.”, and the benefits realized from their first foray into program management.

What exactly did A+ Emerging, Inc., do?

  • They put a program manager in place – this constitutes management acceptance and acknowledgement of the role. Management support is key in the organizational adoption of any initiative.
  • They consolidated to a program plan and one format for reporting project status – the establishment of project/program management (PM) standards (and templates) is an integral part of any PMO.
  • They put in place a consolidation of communication to reduce redundancy and inefficiency.

You can search and find a gagillion (it’s a word – look it up!) articles on what a PMO should/could do and be. I’m listing 7 key goals here, to make it easier to see how the next step for “A+” becomes evident:

  1. Standardization
  2. Project metrics – measurements of progress, trouble, success
  3. Training and mentoring other PMO members and business teams
  4. Aligning the PMO to company/business strategy
  5. Transparency into dependencies between various projects in the program portfolio
  6. Improving communication within the program team among all stakeholders
  7. Increasing the awareness of the value of the PMO and PM

Without aiming, “A+” has hit items 1, 5, and 6 – standardization, transparency, and communication. The next step in their evolution of the PMO comes as the business and IT leadership look for confirmation that the PMO is working and other projects seek to take advantage of the structure that is forming around the PMO.

Measure twice, cut once

It’s easy to use standard PM success and health metrics, but here, I’m highlighting a natural progression in maturity to a PMO. Our teams want to know:

  • How are we doing?
  • Where are the potential problems?
  • How will we know?

Let’s begin with the relatively easy one, measuring progress.

With a program-level plan in place, “A+ Emerging, Inc.” just needs to make sure to incorporate project milestones. These will act as measurement targets along the way, throughout the plan. The measurement question to ask is, “How many milestones have we hit on plan?” (both before and after consolidation).

Our hero, the program manager, is reviewing the plan, and learns that “Project 1” needs to move out their development milestone, impacting the testing activities, which affects their testing milestone date, maybe more.

Let’s assume that, during testing, some time will likely be made up, so the overall end date doesn’t change.

How many times has this scenario occurred pre-PMO? These missing milestones indicate more than a delay, they can point to a need to re-plan, or to revisit the project scope or resources. Changing a milestone could also increase risk to dependencies and other milestones. Hence, attaining milestones consistently indicates accurate planning, resourcing, and mitigated risks, and is a good overall representation of project health.

Simple measurements/reporting:

  • Measure progress – establish baseline and a baseline comparison report for project sponsor and management reporting
  • Measure project health – establish a milestone report, including upcoming milestones to help track project progress and health

(In our next blog, we’ll define instituting standards like Cost Performance Index and Schedule Performance Index, as well as Estimates to Complete and Estimate at Complete).

Finance measurements

Next, “A+ Emerging, Inc.” turns to some finance details. Assuming it took some digging by their PM team across the multiple projects, the overall budget is now in place. Using the contracts and their payment terms, they know what is paid, what is accrued (or earned), and what remains.

They can also tell if there have been any change orders to the original contracts. These typically increase cost, push out deliverables, or change scope. Multiple changes to contracts could indicate planning, resource, or requirements issues. Frequently, these are hidden impacts (because they are unknown until they need to happen) to the overall budget.

Measure budget (start and current budget and current spend, based on paid and earned)

Because the PM team can see what was “spent”, “A+ Emerging, Inc” can calculate the “forecast”. They can view future payment milestones and project milestones and when they will occur. They can forecast when those payments will be made and compare to the budget amount. Hopefully, there is enough to cover project costs. But if the budget is lower than the forecasted amount, a change order is needed, and what happened will have to be determined.

Measure changes and impacts

Something that is harder to determine, historically, is change to scope. This might not be captured in a status. It might be casually worded in meeting notes as, “added additional data feed from vendor x”. No one thought much of it at the time, but it added two weeks of additional development and testing time to the project.

Instead of a clear indication, something shows up in your forecast that you are $n thousands ahead in your spending, and only then do you discover the change in scope. This happens. I’ve seen it and had to deal with it. Don’t get me wrong – it’s great to handle change and be flexible, but it has to be done correctly in the project context.

With these three common sense measurements, we’ve just established how our PM team will track and measure progress, identify areas for concern, and report on these activities, using the standard status reporting we discussed in the first blog. See below for the “easy-peasy” method of reporting the status on these items (Figure 1 & 2). Green means each area of concern is in a healthy state, milestones and progress can likewise be displayed.

Figure 1: High-level reporting

 fig 1

 

 

Figure 2: Detailed reporting

fig 2

 

 

 

By this time at our example company, other project teams and stakeholders are looking at the progress and reporting generated from this beta program. The standard reporting is getting noticed and adopted. Stakeholders will be communicating the level of information they are now receiving and how it helps inform their decisions.

The next natural step will be organizational, looking to identify the performance of the project in order to determine the viability of rolling this practice out for other teams. In our next installment, we’ll take a closer look at this aspect and how project success ties into the establishment of a program management office.

Tags: pmo, project management, standardization, stakeholders, project health

   

Recent Posts

Tag