Do the following statements describe your situation?

• You are a Project Manager
• The company you work for has seen strong growth over the past years
• Therefore you have been asked to build a PMO
• You are good on the formal side of PM-ing, and that’s what you were hired for.
• Maybe you are also great on the formal side and you have your PMP
• You really want to make an impact and deliver quality output, but you are also very busy in your main role as a Project Manager
• You want to take our existing project management group and turn it into a real PMO.

The challenge:

The company you work for isn’t a very mature organization – everybody is kind of doing their own thing!

“Not very mature” — this can mean a lot of things!

But ….

What you probably observe at your company is a combination of the following things:

Does any of this sound familiar?

• There isn’t much standardization in terms of how projects should be run. No rules and no guidelines – or at least they are not being enforced.
• Every PM basically runs his or her project according to their preferred style, and the experience can be either good or bad depending on who is put in charge. You have no guarantee that a project will be a good experience because it so much depends on the individual.
• You may have a few standard Excel and Word templates for things like an SOW template, testing sheets or attendance sheets – but nothing is mandatory and in the end, everybody still uses their own, preferred templates
• There are no defined project meetings – some PMs willingly set up weekly update meetings with internal and external stakeholders while others hide behind their computers and don’t proactively share updates with the team.
• Senior management frequently complains about a lack of transparency regarding projects. They don’t know what projects are in the pipeline, and what the status and expected delivery date are.
• You don’t have a formal project intake process. Some “tasks” which can be considered projects are even submitted via tickets. There are discussions on what makes a project a project … Can you simply submit a ticket? Is that enough?
• Getting resources for a project can be tough. There is little or no transparency of who is contributing to which project and with how many hours per week or month, and resource demands aren’t properly aligned between departments.
• For new hires who are being put on a project, it is really hard to get started and perform well in their job because they have no process and no guidelines to follow.

Because of the conditions mentioned earlier, this leads to all kinds of problems in the delivery of projects which often boil down to communication: 

An example would be: 

Team A may be getting ready to start with the next activity on the plan, but then they realize the colleagues from team B haven’t completed the work they depend on. 

Another example: 

There is confusion about the true status of a project. Depending on who you ask – the project manager, a team member, the customer – you will get different and contradicting feedback on where a project is at.

Did any of these points bring up memories from your own experience?

Some of the issues I listed may sound familiar…

For other issues, your organization may have ways to address them properly, and that’s great!

In any case, the challenges I listed above are somewhat typical for organizations that do not have defined rules and a process for how projects should be run.

The fact that you have accepted the challenge of “taming the chaos” and bringing standards and discipline to your project execution is amazing, and I want to congratulate you on that!

You are not only helping your organization become more mature and more “professional”.

You are effectively helping your teammates be happier and more successful.

“In what way?”, you may ask.

Just imagine the following scenarios:

• Some of your Project Managers may be terrific planners, but they may not be born communicators and they don’t proactively share important information. By handing them a communication template, and showing them how to effectively communicate the project status, and setting clear expectations with regard to communication, you are making it easier for them to meet your expectations and keep everybody in the loop.
• A PM may see a problem with the way a project is set up, but he may not voice his concerns due to fear of criticism, especially in the presence of senior management. A few months on, the project gets into trouble for reasons that the PM saw coming. The situation escalates: the team is frustrated because they have to work overtime; the budget explodes and the customer is unhappy because the original target date cannot be met. This kind of messy situation could have been avoided by having conducted a Risk Assessment Meeting during project initiation, where each stakeholder (including the PM) could have looked at potential risks and a proper risk mitigation strategy could have been developed.
• One of your Junior PMs is having an issue with a client. The client is demanding an analysis that the PM doesn’t know how to provide. Focused on keeping the project moving forward and unsure how to satisfy the client, the PM misses to act on the client’s request and the client is frustrated and escalates the issue to the PM’s boss’s boss. The PM is discouraged and demotivated, and the relationship with the client is strained, even though this was a minor issue and the project is well on track. This unfortunate scenario could have been avoided with regular progress update meetings involving the PM and his or her supervisor. Done well, a progress meeting is done in a coaching style way, where the PM shares his updates and any obstacles he is struggling with. In a coaching-style format, the supervisor and the PM will then brainstorm possible solutions and the PM can leave the meeting with more clarity and a feeling of confidence because he has addressed the issue.

All these mechanisms are “building blocks” in a project governance structure, which is what you build when you define your project management process and PMO.

I’m not saying you have to implement all of those mechanisms – or not immediately.

I’m just trying to show you how a more disciplined and structured approach to project management will actually help every individual PM and project stakeholder at your company.

This is somewhat opposite to what you often read, but I truly believe it and I have seen it with my own eyes after establishing project processes at my previous company.

So now that we have talked extensively about what you are intending to do is so tremendously valuable and helpful for your team, we have to address one key issue:

You are enthusiastic about the opportunity of building a project management discipline at your company. But you also have a main job, and there’s only so much you can do as an individual!

I know what you are talking about …

You’ve probably got projects to manage yourself.

You are attending project workshops.

You may be coaching other people in your team.

Maybe you are occasionally on business trips, pulling you away from your office and leaving no opportunity for face-to-face interactions with your leadership and team members.

You are lucky if you are leaving the office before 6:00 pm

And how often are you skipping lunch?

With a packed schedule like yours, how can you still make a meaningful impact on your organization and get your team moving in the right direction?

It is possible — if you are being thoughtful about your approach and you have a little patience with things to work out.

To get you started on the right path, here are three recommendations for you:

3 Practical Tips That Make Building a PMO and PM Processes Surprisingly Easy

Tip#1: First, build relationships with department heads

Whenever you try to establish processes and change the way people work, you naturally will be faced with resistance.

The level of skepticism will be even greater when you are new to the company.

Everybody will have their stories why “this won’t work here”

How it just adds overhead and makes people waste time on non-value-adding things like filling out spreadsheets and creating update reports.

How management doesn’t get what people at the bottom of the org. are doing.

The reason for this resistance is fear of change:

Nobody likes change, especially when you come up with those crazy ideas about how you gonna control and monitor projects and raise the bar for everybody.

The only way to overcome (and even avoid) this kind of resistance is by first building relationships with your stakeholders and listening to them. 

Listen to their feedback on what works or doesn’t work in the current way projects are handled and what solution they think would work best. / mechanisms they would like to see …

Let’s not over-complicate things:

Project management is really about listening to people.

And so is setting up a PMO.

Just talk to your stakeholders and figure out what people want, what value is to them and then see how the PMO can provide it.

If you do your job well and you build the relationships, not only will your stakeholders show less resistance. They will support your PMO initiative because they feel they have been part of the process and they will ultimately become ambassadors for your great ideas.

Tip #2: Align your PMO goals with your organization’s goals

What is the purpose of a PMO?

When you ask around, here are the typical answers you get: 

• It serves to ensure the successful delivery of projects
• It serves to improve communication between project stakeholders
• It serves to increase the overall efficiency of collaboration in projects
• It can help you establish project portfolio management (PPM)

These are all valid points.

It’s just that they are missing the key point.

PMOs are established to help the organization achieve its strategic and business goals.

The PMO is simply a means to an end. It’s tool to achieve a higher goal, in the same way as a forklift, a computer, a software application or the company website are just tools to serve the business.

If you don’t align your PMO’s goals with the specific business and organizational targets and the goals of your stakeholders, you will run into the typical challenges so many PMO initiatives run into:

• Your stakeholders will question the value provided by a PMO.
• You will face incredible difficulty in getting the needed support for your initiative.
• You will struggle to get people to change their way of working
• In the end, it’s just going to be a frustrating experience for everyone involved, and you won’t be able to make the impact you wanted to make.

How you can avoid making this mistake? It’s not rocket science!

First, you have to understand who your stakeholders are and who you are accountable to in the organization.

These are usually a range of entities and individuals – your technical teams, business teams, accounting, purchasing, Human Resources …. up to the CEO!

Your stakeholders can tell you what their goals are — short-term and long-term targets, financial and strategic goals.

These are usually bottom-line targets like sales and profitability, but they can also be more qualitative targets like customer satisfaction, market share or ratio of new products sold and so on.

Your job is then to figure you how the PMO can help your stakeholders achieve their goals.

This is how you align your PMO goals with the overall objectives of your organization.

And this is how you get the necessary support and buy-in from the people you work with.

Tip #3: Start with a minimum set of measures, test, and scale as needed

In the end, you want to standardize processes and then figure out how our future PMO can best assure that level of standardization on an ongoing basis.

But talking about standardization …

Where should you start?

What templates should you roll out?

Which parts of the project management process should be regimented?

And where is it okay to let your PMs ‘do their own thing’?

Should you introduce phase gates?

You browse through your 3987-page PMBOK Guide wondering what you should implement.

These are interesting topics to look at as you go about improving your organization’s project delivery process.

But one thing you should NOT do: 

Roll out a set of rigid PM standards in a “big bang”-overnight-kind-of-way without looking at the needs of your organization and considering both the benefit AND cost of the measure.

The thing is:

Your project management process should make your PMs and stakeholders’ lives easier and not harder. As much as possible, at least. Sometimes organizational goals outweigh individual goals.

But if you just add a lot of rules that people don’t see the value of, and you have them fill out a ton of paperwork even for the tiniest projects and have people attend 2-hour-long project review meetings that they have nothing to contribute to …. you create a bureaucratic monster that just robs people’s energy, slows down projects and the team’s motivation VANISH.

Here’s a better way to go about standardizing your project delivery process:

(1) Identify the specific problems and bottlenecks existing in your project process. This requires a deep dive into your existing processes, and face-to-face interviews with the key project stakeholders at all levels.

(2) From your interviews, you are able to choose the “needle-movers” – the measures which most likely will have the biggest positive impact on your processes and which will eliminate 90% of  the current problems in project execution.

(3) Test your new project management process and any new measures, and get feedback
from the PMs and project stakeholders.

(4) Fine-tune your project management processes gradually over the coming 6-12
months and implement additional measures wherever it seems useful.

You have to be willing to try things and sometimes be wrong!

Not every process is going to be right, and you can’t get caught up in the idea that something has to be perfect and tested before you give it a shot.

Sometimes it’s just, “Hey, I got to get feeling about this, I think this will work. Hey, I was wrong, we’re rolling that back, let’s try something else.” So, having some bravery in terms of how you put yourself out there, how you put your ideas out there is definitely important.

Now here’s the thing:

I have already hinted at the rough process you should follow, and some of the mechanisms that can solve the most common issues in the project delivery process.

To give you a more detailed, and actionable guide to help you define a project management process for your organization and start a PMO, I created the PMO Launch Checklist.

It gives you action steps, and stages with clear milestones for what you should accomplish within each stage – starting from an as-is analysis of your current project processes to uncover areas of improvement.

You can read more about the PMO Launch Checklist here: