10 Steps To Design A Project Management Office!

Every PMO Director has a different view on how to start up a new PMO. Most Directors will agree on the plan at 50,000 feet, but  each will have different ideas about the importance of each element and where it fits into the process. Some directors would put the selection of Software at the top of their to-do list. I view specialized project management software as a great performance booster, but not the 1st thing to implement. There is absolutely no arguing that PM software is valuable, but project management can be performed without it. A PMO without specially designed software will be less efficient, but if you are just setting up a PMO you need to deal with larger and more immediate inefficiencies, confusion and bad habits. Focus on the absolutely necessary items to ensure success. The purpose of a PMO is to identify and fill the “gap” that is holding back the success of projects. Having said that, this is a pretty good list to get you started:

  1. History: Your first priority is to collect information on previous projects and opinions from different team members and sponsors. A big part of project management is having historical information to project the accuracy of future budgets and schedules. While initial information may be weak or hard to find, collect as many measurable details as possible. Learn what is done well and what is done poorly, and especially develop an opinion on budget and schedule accuracy.
  2. Gap Analysis: What isn’t working and why? Now that you’ve collected some history, even if it is limited, begin to form an opinion about the most urgent issue. Typically, your big problem will be: budget overruns, missed deadlines, poor communication, wrong projects in the portfolio, missing stakeholders on the team, missing and incorrect approvals, or projects that never finish.
  3. Culture: How were things done before you arrived? You may hear that, “There is no process!” But that usually means, “We don’t have a GOOD process!” Alternatively, there may be MANY different and inconsistent processes. However projects are currently managed, somehow: space is acquired, software is purchased and people are hired. You need to put new processes in place, but you also need to KILL OLD PROCESSES! Remember… you were brought in to increase the control and reliability of projects. In order to do this, you need to know about the old processes so that you can effectively retire them; don’t be surprised to learn that some “informal” processes take a great deal of effort to terminate.
  4. Map approvers: Typically, before a PMO is built processes have conflicting or non-existing owners. When you don’t know who signs off on different items, a “tradition” develops of sidestepping the few processes that are known. High-ranking manager willing to rubber-stamp approvals are found, or sympathetic secretaries become accomplices by “helping” teams  to gain approvals. An effective PMO provides team members with a road map for approval. No PMO starts on day 1 with a perfect map, but over time the map develops and drives uncertainty out of the system.
  5. Estimation process: A key responsibility of the PMO is assurance of on-time and on-budget project delivery. Unfortunately, many team members don’t know how to develop accurate estimates! This causes two problems. First, your project portfolio becomes biased. Projects that cost too much to be worth doing are approved (because they are underestimated), or projects that should move forward are rejected (because too much “fat” was added to the budget or schedule). Second, poorly estimated projects that finish late or over-budget produce angry clients. Use the history data you collected in #1 to develop an estimate modifier. If projects are typically 50% over-budget, use this modifier to increase the final estimate. If the group responsible for this cost (or schedule) disagrees, then it is up to them to provide evidence that THIS project will be different than previous projects. If this modifier is unacceptable… well then we may have already identified your big problem!
  6. Communication: Each individual project needs its own communications plan, but the PMO also needs to drive a communication culture! If you’ve stepped into a situation where projects don’t work well, people are probably angry with each other and don’t communicate well. They may not even want to be in the same room. If the culture deteriorates even further, they complain about “useless emails,” meaning everyone gets a lot of emails that shouldn’t have gone to them in the first place and people who should be answering aren’t. When you get people working in groups again, and help them in their communications, this will improve. Take a look at the next item!
  7. Personal interest: New corporate groups are usually met with the same reaction, “Oh great, another waste of my time!” Because other groups were inefficient, people become cynical of new processes and may be legitimately time-constrained. The firm benefits from the greater efficiency a PMO delivers, but individual team members may not see how they personally benefit. If team members realize personal benefits, project success will rise.  If the PMO functions effectively, and gets teams to work together, the number of useless emails will drop because issues are getting resolved. When a team communicates well, they are more likely to communicate efficiently in email, rather than using it as a tool to document their issues with other team members.
  8. Process: Now that you have collected historical information, spoken to a few people and started mapping approvers, you have some idea of the internal processes of your firm. How many processes are in writing? Are they written in a standard format? Think about a template for SOP’s (Standard Operating Procedures). Find one or two “orphan” processes, and apply the template. Take the process to whoever you think is the owner and see what they think. You don’t need to document the firm’s processes, but you do need to develop support for the development of a process map that will guide project delivery. Not all at once, not all in a day… but find some opportunities to start this process.
  9. Repository: As new processes are developed, you will need to store these SOPs (as well as project material) in a repository. Don’t be surprised if you attend meetings where standards and procedures are talked about, but after the meeting you find out that no one in the meeting has ever seen these standards or knows where they can be found. Or you find that there is a repository, but you’re not  allowed access! Start your own, and make it as public as you are allowed. Make it a model that others can emulate. By providing this resource you may be able to dramatically reduce frustration on project teams, and drive needed changes in the organization.
  10. Draft design: Throughout this process you need to talk to potential stakeholders, future team members, future sponsors and others who will be involved or interested in your PMO. Not every idea can be (or should be) incorporated into your design, but the end product should reflect: the legitimate concerns of the people you work with, the gaps they have identified, and the general culture of your firm. This will guide you in determining if you should build an all-inclusive PMO that owns and staffs every projects, or a smaller organization that provides guidance and training. Or something in between.

Before you present your design to management for a final approval, run it by other stakeholders one more time. See how much or how little support you have for your design. How does this compare to the strength of your mandate? If creating a PMO is part of a much larger plan to save your firm from bankruptcy, an authoritative approach, rapid deployment and a powerful PMO may be the way to go. However, give careful thought to how you start off your PMO. No matter how strong your mandate, after your first few projects, more difficult projects with less vigorous management support may enter your project portfolio, and have fewer opportunities for success. If you build in support for your PMO model at the very start, you also build in a higher probability of ongoing project success. And that is my Niccolls worth for today!

This entry was posted in Best Practices, Decision Making, Delivering Services, Improvement, Continuous or Not, Learning and Development, Project Management Office and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.