Listen to proponents of a Project Management Office (PMO), and they will tell you that there were a few key reasons they formed.
- Visibility into the execution of projects and portfolio
- Methodology or rather, delivery needed to be more consistent and repeatable
- Resource and capacity planning are necessary to function better within the execution of projects
- The maturity of the process was required to increase
- Financial control or budgetary planning
Even CIO believes that a successful PMO needs sophisticated methods that will capture the value. While I don’t agree necessarily with the author of that article I do agree that defining what success is will make a huge difference. Your mission, should you choose to accept it, is identify what your PMO success is and while you are working on it develop a secret weapon that will keep your PMO in the corner pocket. In a previous blog post we talked about what PMO’s needed to deliver, but what about planning for current and future delivery? Project resource management is a basic function that the PMO should be providing yet struggle with constantly changing project delivery and planning.
Look, it’s very prevalent this PMO thing, just search for “why you need a PMO.” You’ll get lots of hits, but I can tell you from experience only 30% of why you need them pay off. That’s just a by-product of how disorganized we can become as layers of process and function overtake our mission. I liked the article I found on Thinking Portfolio, Seven Good Reasons Why You Need to Start a PMO in 2014, although the reasons turned into major advantages in the article and included “increases in accuracy, better decision making, cost-cutting, increased control, and resource management.” When you consider accuracy and cost control, you may also find why many PMO’s cease to exist or are de-organized to break the chain of heavy-handed governance and tight-fisted approaches to budgetary foresight.
In some cases, PMO’s attempt to reign in chaotic project management processes and streamline how effective managers may execute. Often though, PMOs support multiple domains or disjointed organizations and forcing each to play nice in the methodology field doesn’t always work. In fact, the more control or pressure a PMO exerts, the less trust in the system a partner will have. The PMO become a policing entity that collects fancy reports and attempts to reign over project delivery.
Unfortunately, this tactic only results in eventual contracting of a PMO, the entire project execution function, or elimination. There is no reason a contracting function couldn’t execute your portfolio. Where is your secret weapon? Are you existing because of data or information ownership rights? What I mean to say is, is the only reason your group exists is due to the high level of intellectual property on specific components of the business. While your ability to manage Project Managers and all the roles involved is quite efficient; you’ve got to craft a better value proposition!
Let’s Use a Lean Value Proposition
To ensure longevity, PMOs must focus on value first. That means doing the homework to decide where and how in your organization the PMO can provide the most value. If one or two executives have agreed that fancy budgetary reports effectively serve that need, then you may be fulfilling the function of a Portfolio Management Office, versus a project one. If a PMO can tightly couple the project execution process with governance, then it may have a chance of survival. Remember that the key to any operation is building in flexibility to support rapidly changing technology. Related: Top Five Reasons PMOs Fail.
I believe this is where necessary process management and lean components come into play. A PMO that wields transparency into project execution processes will always be of value, and it can prove it with something as simple as Statistical Process Control (SPC). Using this for project resource management will kickstart future automation of this function. You can probably find many an easily excitable process engineer to explain it in painful detail–but we’re just going to use what we need to develop our secret weapon. In a business process where teams execute seemingly unmeasurable actions, SPC is not so understood. All you have to do is pare it down to something we all understand, “Team X always takes weeks to get anything done!”. I haven’t been a part of an organization yet who doesn’t target specific business groups that appear to slow execution.
If your projects execute with defined characteristics such as financial approval, charter development, quality or application testing, completion of epics, etc., and you aren’t paying specific attention to the timing of events then how can you measure project delivery? There are so many moving processes within a project that one cannot determine delivery simply by meeting a project schedule. Keep in mind that quality of a deliverable is one thing, and quality of project execution entirely another. The PMO is responsible for the quality of project delivery. Using necessary measurements of executing processes; the PMO can begin to focus on real process improvement.
If you can understand how the execution of tasks inside a project has a moving range of time sequences, then you can understand how the analysis will pinpoint trouble areas for failure or quality concerns. “Procurement always does this at this time of year, and it puts us behind.” Prove it! “I think this always happens with projects over the threshold.” How can you show that? With process management and statistical process control.
Your team is probably already measuring the project execution process within some project management system or software. If not, the technology world is your oyster, and you can use the most basic of tools to do this, more on this in later posts. You probably already have some of the data to begin an accurate statistical analysis of your project execution. The fundamental analytical study into the process supports the framework that allows flexibility within project execution. So let’s just extract two basic equations from lean thinking into project execution process: action points and capacity.
They Said There Would Be No Math
First, we’ll cover action points. The example: In each project schedule, you have the number of days it took for some function you want to measure. Let’s say this is budget approval for all projects under one million. In reality, PMO’s or project support functions spend countless hours in project review boards, status meetings, and daily/weekly repeated discussion of date related information. Imagine that time being spent on innovation or employee creativity. Using actionable information (like action points) based on executing functions, teams can spend much less time reviewing status. The idea is to quickly act on indications that the action point has been triggered. The action point is inside the moving range of values acceptable to efficient execution.
For example, most projects get their approved budget in 4 weeks, but sometimes it can last for 8. Do you need status reports each week? Or do you need the action point for when to act? The equation is: Mean + or – 3.14 times the Median Moving Range (MMR). Use your fiscal year portfolio and calculate the mean and MMR for all of the projects executed or you can work smarter and use a first in, first out method so that the MMR takes into account current time ranges. Those day counts are somewhere in your project schedule and PPM system. (Ultimately the MMR would be stored in your business process management system.)
The MMR helps you identify how that budget approval, over time, fluctuates. This enables you to understand when to act because that action point equals Mean +/- 3.14 MMR*. With MMR you can visualize the guide rails, if you will, of the time limits that a project needs to get approval. You understand the fluctuations, but with the math, you now know when to act without having to review that same project week after week. When a project meets that threshold, an alert is a status. This is an elementary example, imagine your portfolio of projects with action points for phase completions, approvals, audits, benefits realization, and a host of the generic components of all your projects. Remember to stay within the confines of project execution. In other words, you aren’t looking at action points for how long it may take a team to test a software component but are looking at the test phase completion time. That is because of your PMO function, understanding the value of it, and delivering it to the groups you serve.
How Many Project Managers?
The second part of the PMO secret weapon is capacity. You’ve got 200 projects in the queue, you are currently executing 50, and the groups you serve need to know how many more you can complete with a few more Project Managers. The PMO has two fundamental problems: fluctuating project initiate rates, and Project Manager assignment or service rates. There is no set number of projects each year, and some Project Managers can handle more than a few projects because some projects are small or large and even completed more rapidly.
How much spare capacity does PMO need to cope with these fluctuations in new projects and execution rates? The PMO has (x) Project Managers. Should they add more to achieve more? So we use a little more lean math to help us solve our problem: Queue length = Utilization/(100-Utilization). Or Q = U/(100-U). The PMO uses a fiscal year or more data to understand how many projects execute on average and how many are assigned to each manager. Those are basic statistics that PMOs retain.
Then we use our project velocity to understand what is the average number of projects we execute each fiscal year, or better yet, each month, quarter, etc.
Let’s perform an example:
Your PMO executes 20 projects at any given time currently. And you estimate that you’ve got 50 new projects in the queue. Theoretically, you need 20 project managers to cope with demand (if you assign 1 to 1). However, we know that some project managers can manage multiple, projects start/end differently, and some of the new projects aren’t ready yet. We do know, that on average, you get 50 new projects each year. So the queue will just keep getting longer – and we know this happens because all PMOs suffer from project overload or old new ideas.
We need the spare capacity to keep the projects moving. But, how much do we need? Right now, in this example, say we have 10 Project Managers to handle demand. What if we add two more? In our equation, we have 12 doing the work of 10. So that means 12 people are 83% utilized.
Is that enough to cover the velocity of projects? The formula is:
U/(100-U) This formula tells us that the backlog, or queue length, will then be 83/(100-83) which is 5.00. That’s five projects in the queue at all times, and our average project length is six months. So now we know it’ll take 30 months (projects*avg) to have all projects assigned and in execution (anywhere in the cycle.
I don’t know about you, but your business is probably not going to wait 30 months for their (100%) project to begin executing. In fact, let’s look at a realistic scenario: Your PMO now has the 12 Project Managers that you demonstrated would be needed to keep the queue moving then one is promoted or leaves the company. Instead of hiring a new project manager, your PMO Director remembers that you could execute back at ten, so she tells you not to fill the void. Although we know they can complete the work, what does this do to our ability to plan and execute the portfolio of projects? The utilization rate is now 91% and that pushes your time to assignment to 60 months. The queue doubled. What are a few months regarding a handful of projects not being assigned? The PMO would know the answer to that question because they know about any projects that are waiting to be kicked off.
In the chart below, which scenario is closer to a backlog the organization can withstand and balance Project Manager’s utilization rates accordingly? Considering a normal business workday, isn’t around 75% utilized closer to the truth? Should this example PMO hire four more Project Managers? I guess that depends on the importance of projects in queue. Each year the number of resources will change and many organizations will use contract resources to supplement this.
|Today||Example 1||Example 2||Example 3||Example 4|
|Average project lifecycle||6|
|Queue = U/(100-U)||5.00||10.00||2.50||2.00|
|Months in backlog||Current||30||60||15||12|
Lock and Load
The secret weapons: Use action points to keep your projects within the safety rails and succinctly communicate how many resources are needed to execute the portfolio in (x) years. Set your action points starting with basic averages on phase days/weeks and limit time spent in status review meetings then arm your leadership with the utilization rates based on your current project portfolio. You can show how you can execute with 10 resources and continue to experience a significant project queue considering your current backlog. You proved you can decrease project backlog to 15 months with extra support. PMO can now say with 14 project managers; you can execute the portfolio in less than four years. The PMO foresight for the win. This allows the organization time for demand management functions such as benefits realization, approval, and resource planning. Build these calculations into a PMO dashboard so that they are communicated and easily understood.
These are some fundamental steps your PMO can offer the organization. The utilization and set action points are your secret weapons and contribute to those five basic reasons a PMO was organized. Imagine if you applied the rule of utilization with business and financial analysts. With current data you already collect, you can easily derive the utilization rates and queue numbers. Your average project lifecycle may change over time but it’s easy to see the impact of time on resources with this equation.