If you want to know how a lean PMO works, and how it differs from the traditional PMO, you are in the right place. Not only we will see the key characteristics of a lean PMO, but we will also give some insights on how to make your own PMO office more agile and effective.
Before Lean PMO: A Refresher
Let’s touch some of the basic concepts of PMO and lean to ensure we understand the context and tools needed to pivot toward a lean PMO.
The Types of PMO
Before we can dive into the details of lean PMO, we should set some basic definitions of PMO and its types. As we will see, all types of PMO can adopt lean and agile approaches, but they may need to do that in different ways, depending in their role.
PMO stands for Project Management Office, and it is the group of people in charge of defining how a company should run projects. For smaller organizations, it may be a one-person office, but it still retains its role. You may find one PMO for the entire organization, or one PMO in each function that needs one (IT, HR, Engineering etc.).
A company can structure a PMO in three ways:
- Supportive PMO – It provides guidelines to project managers around the organization on best practices to run projects.
- Controlling PMO – It defines policies that are to be followed, and then audit project managers and projects around the organization to see they are adhering to such policies.
- Directive PMO – In this case, the PMO runs the project. The project manager (or project managers) running projects are part of the PMO. The PMO has full authority over projects.
These three types of PMOs define the level of control a PMO can have over projects. Even if lines can be somewhat blurry in some cases, it is relatively easy to understand which type of PMO you are dealing with. Furthermore, these definitions are the one accepted by the Project Management Institute, so you should really know them before we dive into lean PMO.
The less control the PMO has (that is, the more it is oriented toward “supportive PMO”), the more “lean PMO” will be about effective communications. Instead, the more it will skew toward directive, the more “lean PMO” will be about lean project management by itself.
Traditional PMOs
The traditional way of operating for a PMO is to erect some bureaucracy and have project managers follow it. Even when the PMO is directive, it will have some internal bureaucracy to simplify tasks.
In fact, the PMO is tasked to deal with projects that are quite different from one another, and often to report their status to senior management at an aggregate level. Because of this, the frameworks to be used are often inflexible, so that all projects are casted into a single reporting template, which can be then rolled up to create aggregate reports.
This often creates tension, particularly with agile teams, because it reduces the flexibility they need and often add administrative burden. The toll it takes to produce administrative reporting document is often unjustifiable high if we have a significant segmentation of small activities. This means that, the more the reporting requirements are stringent and complex, the more the traditional PMO pushes project to be managed at a higher level, rather than a lower level. This, in turns, pushes toward a waterfall/predictive approach to project management and monolithic development of deliverables.
All this can be good in some organizations. But for organizations wanting to implement agile methodology, or generally be faster to react, this can be a significant showstopper. Fortunately, a lean PMO can help solve these problems.
Lean Crash Course
Before we can actually tackle lean PMO, let’s have a quick refresher of lean concepts. Probably, you already know these concepts, but this section is still worth reading so that you know the terms we will use for the rest of the article.
Lean is about removing unnecessary waste. Waste can be intended as anything that adds no value to the customer. This concept was born in manufacturing, so the most immediate representation of waste was scrap material (e.g., you have to cut a disk of metal out of a square, all the parts around are wasted metal), but the concept rapidly expanded.
With waste, we now mean everything that adds no value. Waste is any time that is not spent on value-adding activities. It is a huge amount of inventory waiting to be processed (we can imagine that materials, like people, are wasting their time waiting to do something / be processed). Waste is also products that you produce but that are not of good quality and you have to discard, and also products returned by the customer because they were defective.
The concept of waste can go even further. In fact, waste is the time you spent fixing problems that you should have prevented in the first place. Time spent providing customer support in itself is not wasted, but all (or some) of the requests arise because of problems you could have prevented (for example having a better product), then you are wasting some time.
As we are about to see, the concepts of lean apply quite well to project management, and specifically to a lean PMO.
Adopting a Lean PMO
Now that we have the key concepts in mind, we can put them in practice to transform the traditional PMO into a lean PMO. The good news is that most people working in the PMO you already have will already posses the skills needed to run a lean PMO. All you need is a change in perspective, and in processes.
1. Shift the Focus
The first step toward lean PMO is shifting the focus of the project management office. Traditionally, the PMO is about reporting and aggregation of projects. This means everything they do will be tailored to make good reports and aggregate projects in a consistent way.
With lean PMO, the new focus is to help project teams “fill in the gap” between what they do and what the organization needs from them. This is a concept of “servant leadership”, where instead of providing top-down policies and guidelines, they work closely with the project team to understand what they need, and why those needs may not be aligned with the organization.
For example, a software development team may work with an agile framework with a backlog of things to do, with the team pulling features to be implemented as soon as they finish existing framework. A traditional PMO will ask the team to “chunk” this agile approach into milestones (called “sprints” to sound more agile). However, now the team has a deadline for a bunch of features together that are potentially unrelated. This may be needed in some cases, for example where the software developed is a firmware to be shipped to appliances that are hard to update afterwards (e.g., dish washers, cars etc.), but for most software projects it will not be the case.
By having to chunk their work and commit to those timelines, the project team will tend to be more conservative in estimates and add some contingency. The overall pace of the project will slow down.
Instead, a lean PMO will approach this in the opposite way. It will talk with the team to understand how they are working and how the pick features from the backlog, and then keep track of what features have been added each reporting period (for example, each month) so that they can create their report in chunked ways. With this approach, it is not the work to be chunked, only the report about the work is chunked.
So, shift the focus of your lean PMO. It is not about telling project teams how to implement company procedures, and more about filling the gap for what they can’t do themselves.
2. Change Processes
The underlying skill set required to run a lean PMO is the same as the one you need for a traditional PMO: great communication skills, precise reporting, data modeling. However, this does not mean transitioning from one to the other is easy. It requires a significant shift in perspective. Such shift will go nowhere as long as the processes are wired in a traditional way.
To transform your traditional PMO into a lean PMO, you need to change the processes that govern the way the PMO works. Often, these processes are implicit, so the first step is to identify them and try to have them on paper so that you can see clearly how they work.
Most often, these processes define how the PMO interacts with project team (or with its own PMs, in case of a directive PMO) and how they construct reports based on the information they get. They define frameworks of communication to limit options and make interactions more standardized. This approach assumes you have a clear set of requirements from the organization, and a clear set of outputs from each project – that is always the same set for all projects. In this context, the PMO needs to find a way to pipe the information coming from the project to the organization. This can be repeated over and over across projects.
In a lean PMO, you can’t have such standardization, because having that has the cost of sacrificing flexibility. Instead, you need to think about organizational requirements as fixed (or rarely changing), and analyze what the project produces on a project-by-project basis. Then, you need a way to reconcile the two, which will be different from project to project.
This reconciliation is not done with complex processes and automation, but it is done by talking with people and spending time to really understand. In fact, in a lean PMO, active listening takes an even more important role than in a traditional PMO.
To do this, you will need to literally scrap most of the processes that impose standardization. However, if you just scrap them, the team will feel “gutted”, and these processes will re-appear spontaneously because the team just knows that way of operating. Instead, insert a process to document the need of each individual project team. This will force the PMO to see projects from the PM’s point of view. Once these needs are documented, project by project, the team will be forced to confront them with the organizational needs and do the reconciliation.
This does not mean standardization has no value. It has significant value. However, with this approach, the lean PMO can critically discuss with the project team what may be worth standardizing because it has little or no cost (in terms of flexibility), and what instead cannot be standardized.
3. Educate Stakeholders
Transitioning from a traditional PMO to a lean PMO is all about redefining expectations. Now that the PMO has become a lean PMO toward the project managers and understand their need, some conflict may arise with other stakeholders across the organization, which still want standardized reporting. The PMO will take care of that, “filling in the gap” as we said earlier, but the gap cannot be filled 100% of the times to 100% of the depth.
You should spend time educating stakeholders on the complexity of projects and on the proxy nature of reports, which do not often reflect reality in the best way.
This is because it is not always easy and immediate to capture the value a project is generating, even more so if the project is changing scope and pivoting like an agile project is likely to do. In traditional project management you have methods like Earned Value Management, that says the work done so far has created/earned a value of X dollars, where X is computed by multiplying the current percent complete by the original budget of the project.
For example, if a project had a budget of one million dollars and we are at 10% completion now, we have earned 100k$ in value, even if to reach this 10% we spent 120k instead of the 100k$ that were planned. This can be a good estimate for projects that are strictly following a waterfall approach, such as in constructions, but it is not a good proxy of value in an agile environment.
When we create a feature, it is not always clear what is the value of the feature, and the effort used to develop that feature is not necessarily related to the value it provides. Furthermore, we scope and priorities often changing, it is hard to define a percent complete value that is actually meaningful.
Instead, the lean PMO should spend time educating stakeholders about how the project is really going with clear and detailed explanations, without oversimplifying an entire project into a bunch of number (most notably percent complete, planned cost and actual cost). Educating stakeholders, for the lean PMO, means spending time to make them understand the real status of the project so that they can have a critical view of it. It is crucial to navigate the complexity of modern projects.
So, in a nutshell, educating stakeholders means shifting away from pre-formatted reports and more toward an open-ended communication.
Lean PMO in Summary
In this article, we saw what is a Lean PMO, how it differs from a traditional PMO. In a lean PMO, you focus on understanding the needs of each project and then bridging the gap toward the organizational needs. Lean PMO focuses more on open communication and less on standard formats, and ditches useless metrics.
If you like to dive deeper in lean PMO, this other article about lean operations may give you an edge.
