There are several building blocks necessary for a PMO to be successful. To keep things simple for this article, let’s focus on the general categories of people, processes, and tools.
The Essential Three
Everyone knows you need people in your PMO or playing the PMO roles to make it a PMO (even if there is only one of you). If you want to be really great, you probably want to spend a good amount of time finding the right kind of talent, and they need to be delivering on whatever services your PMO will provide. Got it.
You also know that you need to have a couple kinds of processes. You need process for how you will operate internally within a PMO (e.g., how you will assign project managers to projects) and how you will deliver services to your customers. We need project, program, and/or portfolio management processes for the work we do. For example, if you have a project management office (you gotta define your P first), then I’m guessing you will create some project management best practices or a methodology for how you will manage your projects. Yes?
The third area you would need to consider is tools, templates, and all of the other enabling systems that help us facilitate the work processes. These are the mechanisms that enable the people to use the processes to get things done. These are also important.
The Right Sequence Is Critical
But when you use them and how you use them is what matters most. Frankly, if you want to do your project schedule on sticky notes or a napkin, I don’t care. The tool isn’t as important early on, not nearly as important as the other things that determine success or failure of a PMO. In fact, focusing too much here at the wrong time helps you fast track your PMO to extinction. Timing and order is everything. If you haven’t figured out what processes you need and you don’t have the right people in place, the tools don’t matter. At all.
Have you ever seen a PMO or a big project go through a startup? Did they immediately go to discussions on what system they were going to use? Did they spend a lot of time on MS Project vs. Clarity, for example? Did they spend months and months or even years getting that system up only to realize the business moved on without them or that the system wasn’t even usable the way it was designed? Or worse yet, the business totally rejects the system because they don’t see the value. Yuck. This happens all of the time and not just with PMOs, but with projects all over the world that have a technical component. We focus on the enabling system and forget to ask some basic questions or really define our requirements first. Consider yourself lucky if it hasn’t happened to you.
A Story of Avoidable Mistakes
I watched a client go through this once and it was really heartbreaking for me. I was helping a PMO leader new to the company set up a PMO run by the IT department. The IT leader insisted that the tool get implemented first, believing that was the first and most important step in setting up the PMO. I referred them to articles, training, resources, and my own guidance on the reasons why this would fail. I predicted that the business would not buy it because they hadn’t addressed their WIIFM (what’s in it for me) to engage with the PMO. They hadn’t clearly defined their why, or as my coach says, their “who and do what statement.” The business just saw another tool being thrown at them from IT before they were bought into the value proposition. In fact, they fought it all the way, as I kept telling them would happen. And I hated it.
I did not want to be right. I hated knowing what was going to happen and watching them make the mistakes that were going to derail their efforts, despite their best intent. I tried to keep up with the pace of their tool rollout by focusing on getting clear on their mission, value proposition, services, etc., but the force by which the tool rollout was happening was hurting them faster than I could help them. Have you ever watched a child hurt themselves after you tell them 100 times not to do something? It doesn’t make you feel good when they hurt themselves and it’s not about “I told you so.” It still stinks.
If you pay a consultant to come in and help you, you probably did so because they are experts in their field: Listen to the experts, just like you would a doctor, lawyer, or any other professional that has spent their career learning how to keep you from running into problems. Let them help you. We want you to be successful. We are in the business of service.
We were able to get things back on track eventually, but at a much lower scale than they had originally intended… and the tool that they invested a lot of time and money on was not leveraged. Sadly, it was a really good tool; in fact, I believe it was perfect for what they wanted to accomplish. Yet, by not doing things in the right order, they derailed the PMO build out for a while and took a lot longer to accomplish their goals.
… Not as I Do
Sometimes, we do this to ourselves and the funny thing is that, as project managers, we should know better. Aren’t we the ones always telling people to define their requirements before building a system? Isn’t that in our project manager DNA? It’s like the plumber with the leaky faucet. We have a “do as I say, not as I do” attitude. We pick the cool project management software that we just know is going to make managing our projects easier, but before we really know what services we are providing or what makes the most sense in our environment. Then it crashes and burns when it takes too long to get done (because we only have so long to prove our PMO worth) or doesn’t meet the processes we need to follow to be effective. I’ve seen PMOs fail because the short two-year window where they should have been building and delivering services for the business was spent almost entirely on implementing a tool that didn’t end up meeting the needs. Bye bye, PMO.
But why is that? Why do people go to the tools first? I call it “something shiny syndrome.” It seems like it is more fun or more tangible and easier to start, in spite of not being easier to do in the long run—just pick a tool. It feels harder to figure out the people side and the processes/services you are going to deliver. Defining the services and hiring the people also (in theory) seem to take longer than just “picking a tool,” but starting with the tool doesn’t give you a PMO. What it might actually do is give you a nightmare you have to clean up later if you didn’t figure out your processes first and get the right people in place to operate those processes.
Same goes for the templates. You can spend a lot of time building really complicated templates to capture every possible data point for large projects, but while you are doing that, people are still using their own stuff that they become more and more attached to as the days go by. Opportunity missed. Start simple. Use just the basics. A handful of impactful and simple templates will do.
Tools should be enablers, not the center of the PMO universe.
Put the Toys Down
So how do you avoid the mess, get your PMO set up right, in a short amount of time, all while you still have the interest (and the funding) of your leadership?
STOP PLAYING WITH TOYS!
Do the “hard” stuff first. And really, it’s not that hard. If you do it first, it’s even easier. It’s as straightforward as creating a charter, which many of us can do in our sleep. Start by asking a simple set of questions:
- First, define your “P.” Are you a project, program, or portfolio management office, or some combination of the P’s? To determine that, ask yourself two questions: What is your purpose? What business problem are you solving?
- This helps inform the services question. Who do you serve? What do you do for them?
- Then you can get into the processes, how you will deliver those services to them.
- Then validate all of this with your stakeholders. Do not pass go until you have gotten agreement from those that will interact with you that these services, when you deliver them well, will meet the customer needs. The value has to be there.
- Then you ask yourself who you need to deliver on those services. You can’t answer that question until you’ve done the homework above to figure out the services you will provide (that the business leaders have asked for, not what you think they need). That sets the stage for the kind of talent you need.
- THEN, and only then, you can get into the enabling systems and tools you need to help you deliver those services.
If you do it in any other order, you risk building systems, tools, and templates that don’t help enable your people to deliver on those services in the most impactful way.