Stop playing with toys – where many PMO leaders are getting stuck

There are several building blocks necessary for a PMO to be successful. To keep things simple for this post, let’s focus on the general categories people, processes and tools.

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 and you are just getting started or having the life drained out of you by being one resource doing a hundred things), right? Yes, you’ve got to have people doing something (hopefully of great value). 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. OK, we need people. Check.

We also know that we need to have a couple of kinds of processes. We need process for how we will operate internally within a PMO (i.e. how will we assign project managers to projects) and how we will deliver services to our customers (yes, even if you are internal, you do have customers – they are the people that use your services). We need project, program, and/or portfolio management processes for the work we do. For example, if we 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? OK, good. Let’s keep going.

The third area we 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.

But when we use them and how we use them is what matters most, to me. 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. Period. Sorry, but no, not even a little bit. Stay with me here…

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 isn’t even usable the way it is 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.

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 setup 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.

Lesson: 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 want you to win.

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 them, perfect for what they wanted to accomplish. Yet, by not doing things in the right order, they derailed the PMO buildout for a while and it took a lot longer to accomplish their goals.

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 or with our types of people resources…and then it (and we) crash and burn when it takes too long to get done (because you only have so long to prove your 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, not easier to do in the long run, but feels easier to start – 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 templates, really complicated ones, to capture every possible data point for large projects and 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. Don’t get fancy. A handful of impactful and simple templates will do.

Tools should be enablers, not the center of the PMO universe.

So how do you avoid the mess, get your PMO setup 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. And if you do it first, it’s even easier. It’s as straight forward as creating a charter, which many of us can (and probably have) do in our sleep. Start by asking a simple set of questions:

1. 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?
2. This helps inform the services question. Who do you serve? What do you do for them?
3. Then, you can get into the processes, how you will deliver those services to them.
4. 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.
5. 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.
6. 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.

If you want to learn more about my take on PMOs or how I teach others to setup Business Enabling PMOs, check out the Building Blocks of an Effective and Sustainable PMO blog series.

As always, I’m happy to answer any questions you have to help you on your journey.

See you online!!