October 17, 2016
How To
How To
Jim Stewart
By Jim Stewart
The Project Management Institute defines a Project Management Office as a “management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools and techniques.”
These are some lessons learned from a recent experience I had setting up several Project Management Offices. There's more to setting one up than I can effectively advise in this space. So these are just some items you should definitely take into consideration:
- Create a charter: A charter is the official authorization that the project is approved. It also helps set expectations for your stakeholders. It can also provide justification, measurable project objectives and success criteria.
- Have a sponsor: A senior executive in your organization has to be a sponsor, evangelist and champion for this. They can run interference for you when people begin to question why you're doing it.
- Decide on a structure: Your PMO can be just a repository of templates, a governance body including compliance or it can actually run projects. Which do you need?
- Know your stakeholders: A variety of people in the organization will be impacted by this endeavor. Know who they are and what they need from the PMO. Then keep them informed of progress.
- Treat it like a project: Process improvement endeavors are often seen as overhead while you're running your real projects. But establishing the PMO is a temporary endeavor with a start and end date to create a service. In other words, a project.
- Create a schedule: Whether it's a milestone schedule in Excel or a full-blown schedule in MS Project, you need something to establish milestones and timelines.
- Make time to do this: Establishing a PMO is not, or should not be, an afterthought. Build some time into your day to get it done.
- Don't boil the ocean: Once you identify the areas for improvement, you'll be tempted to fix everything all at once. Don't. Pick two or three items and work on them. For example, use a risk register or work-breakdown structure.
- Go for the low-hanging fruit. You want to show progress fairly quickly. Start with a template. These shouldn't just be chosen to check off a done box. Pick items like an issue log or risk register. And then make sure people know how to use them. This is the beginning of your repository.
- Behind every artifact is a process: Just putting, say, a risk register in the repository and declaring it done isn't enough. Do people know how to use it?
- Understand change management: You are introducing change into the organization. Recognize this and that many people do not like change and will not welcome you with open arms. Introduce change at a rate the company can absorb.
- Establish metrics: You need to measure progress. So, how many projects are meeting their objectives today? How many are on-time, on-budget? As you introduce more process, you should be seeing better results. If not, why not?
- Staff it with the right people: Depending on the type of PMO you have, you may have a very small staff or a larger one. Regardless, getting the right people in place early on is key. You want people with the right skill and personality mix. There is a sales flavor to promoting the PMO.
- Understand how agile fits in: Agile is, by definition, less process and paperwork heavy. You may just need an agile side to help make decisions on which projects are and are not agile, coaching and mentoring. It certainly won't have all the templates you use for the waterfall side.
- Don't necessarily call it a PMO: PMOs have gotten somewhat discredited, less because they don't work, more because they're not established correctly. You can refer to it as Project Center of Excellence or Best Practices.
Jim Stewart is certified in professional project management. He is principal of JP Stewart Associates and specializes in consulting, training and mentoring. He can be reached at jpstewar61@gmail.com
Most Recent
Most Recent
Comments