Forward Momentum: Delivering Results

By Bruce Beer, PMP

Note: This is the third post in a series on PMOs. Read part 1 What is a PMO and What Does It Do or part 2 PMO Business Value and Impact.

In the previous two blogs in this series we looked at what a PMO is, and the business value that they bring to a company. In this blog, I want to look at the considerations that might help you decide whether you need one. After all, they can cost a great deal of money so you should be sure there is a definite requirement.

First, let’s look at a standard project with a PM, several team leads, and various team members. The planning would normally be performed by the PM and team leads with possible input from senior team members or Subject Matter Experts (SMEs), and the plan would include the three basic baselines – scope, time, and cost, considering the other key elements such as risk, quality, resources, and communications, etc.

When the project goes into execution, the PM will normally have a weekly status meeting where he/she would determine the current status of milestones and deliverables (scope), how well this is being performed compared to the schedule (time), all relevant costs (cost) and would probably review risk. During this meeting he/she can implement corrective or preventative actions as necessary.

Now consider a very large project with several sub-projects. During planning there may be a need for a high level view of scope, time, cost, risk, quality, and resources covering all of the sub-projects. The sub-projects may each have a PM, so the overall PM is now managing a team of PMs plus the overall baselines of the project. This is starting to look like a Project Management team!

Now let’s look at a program with several or many projects. This is an expansion of the previous case, and unless the overall Program Manager is careful, it will be easy to lose control and become a statistic for project failures.

The answer for both of the last two cases is probably a PMO, elevating the functions that spread over multiple projects to a PMO team. This team will consider and evaluate the effects of one project on other projects in the program and, where necessary, institute proactive activities as soon as possible.

Other considerations for implementing a PMO include 1) possible resource efficiency improvements across the program and 2) a much improved change management process that evaluates the impacts of changes in one project on all the other projects before deciding to approve or reject that change.

So where is the line drawn between having a Project Manager and a PMO? A PMO can be relatively small, maybe the overall PM plus the individual project PMs, so although it may not be called a “PMO” it could be the embryo of a PMO. The larger the project or program gets, the more likely the PMO is to include:

• A risk manager to review risk of the overall endeavor
• A quality manager to ensure consistent quality goals and “look and feel” across all projects
• A scheduling manager to create the overall schedule, dependencies, milestones, deliverables etc.
• Other specialist personnel

Costs could be collected and reported at the PMO level as could overall status and progress reports, to give management the relevant level of detail they require.

Another major feature of the PMO is the customer interface, whether for internal or external customers. It relieves individual PMs from interfacing with the customer, but probably more importantly, it gives the customer one focal point of contact for the program rather than multiple individual PMs. The customer will be able to have a coordinated view and assessment of the program rather than having to piece together different reports from each project.

In short, there is a grey area between PM and a PMO and it is a subjective judgment as to when one morphs into the other. One big element of the decision whether to have a PMO or not is cost – both the cost of having a PMO and the cost of not having one (potential project/program failure).

Another type of PMO that can be deployed is at the company level rather than project or program level. Several major companies have PMOs not tied to specific projects, but to act as an oversight for all projects and programs being performed by the company. This type of PMO would normally contain senior PMs and might perform project audits at various stages of a project life cycle. They might define and implement project quality measures, tools, techniques, templates, etc. to be used across the company to provide a common “look and feel” for that company’s project deliveries. These senior people could also provide mentoring for the more junior PMs in the company. This type of PMO will be particularly interested in lessons learned from individual projects to provide improving project ability for a company. If a company does not have a methodology, tools, templates, etc. in existence, the PMO could be the entity to develop, train, and implement these standards across the company. The decision of whether a company should have a PMO or not is again a subjective judgment made by senior management and will be subject to financial justification.

Although this blog gives some pointers as to when you might consider having a PMO, it is a highly subjective judgment based on things such as the company’s risk and quality policies, financial justification, and requirement for improvement of project success over time, among other things.

How do you see a PMO benefitting your current project or organization?

Next in this series we will look at how you might establish a PMO.

By Bruce Beer, PMP

Note: This is Part 2 in a series on Project Management Offices. Part 1, What is a PMO and What Does it Do? can be found here.

In Part 1 of this series, I outlined what a PMO is and what a PMO can or should do. Now let us turn to the business reasons and incentives for having a PMO. A PMO is often packed with senior and expensive resources so there has to be a good business case for this expenditure.

Not all programs can justify the cost of a PMO. However, consideration has to be given not so much to the cost but to the “value” of a PMO: things like how much does it influence the success of the project, how much money can it save, how much additional cost would there be and could the program objectives be successfully met without one, etc. So let us look at some of the features of a PMO and how this could be cost justified.

Baselines

At the project level we have three key baselines: scope, cost, and time. It is the Project Manager’s responsibility to establish and then meet those baselines. In a program where there may be multiple related projects, each of those projects will have their own baselines and there may be a Program Manager who is in overall charge. However, the Program Manager has a finite limit regarding the number and complexity of projects in the program that they can manage alone. It will not take long for the Program Manager to start recruiting additional resources to assist in managing various aspects of the program. It also does not take long for this to escalate and morph into a PMO, whether recognized or not.

Constraints

One thing most projects will do is to evaluate constraint priorities – the flexibility matrix. What is the key “driver” for each project – time, cost, or scope/functionality? If different projects have different priorities there is a high chance that the program will not be totally successful due to conflicting project priorities. If, for example, the program is time driven, the whole program must be complete by a certain date. Unless each individual project understands that time is the key driver and if they focus on one of the other constraints instead, they could cause the program to slip. So enabling a time driven program to coordinate and amalgamate individual project schedules and milestones will enable identification of the program’s critical path, ie which projects are on the critical path. The PMO can then ensure the focus on these projects is to attempt to ensure critical timescales are met. This could provide major benefits to a company in terms of reducing cost of slippage of a time driven program and have a direct impact on the bottom line of the program and the company.

If the program level critical path changes, the PMO should be aware of this and shift their focus to the new critical path projects, so again maximizing the chance of overall success. Missing a time deadline can have serious financial implications for a company, and the reverse is true – meeting contractual or defined deadlines can save or gain additional revenue.

Information and Reporting

Without relevant coordination and management of the constituent projects at the program level, senior management may not be able to obtain a consistent view of the program objectives and status without a lot of digging. Consequently, one of the major functions of a PMO would be to gather information from the constituent projects, combine these disparate objectives, plans, status reports, deliverables etc. into a set of higher level overall program information for easier understanding by management. These reports should indicate developing issues at the earliest time, together with any action required to put a program back on track.

Risk

Some tasks that the PMO will undertake at the program level may include overall risk management – assessing how a risk on one project might impact other projects. If a risk starts to happen on one project, the PMO can immediately assess action required on other projects to minimize “knock-on” effects.

Quality

Ensure a consistent look and feel for each project under the PMO and provide templates that can be used to ensure the constituent projects look like they are coordinated and are not just a mixture of random projects thrown together. This may not have a tangible bottom line benefit but will improve the final product of the program.

Managing a Program vs. a Company-Wide PMO

All the above considerations were in regard to multiple related projects in a program. Now let us consider a “company” PMO where the PMO is not managing a program of related projects but is there to provide assistance on all projects being undertaken by the company. Many of the benefits detailed above also apply to this scenario, but there are also additional considerations.

Having led a PMO for a major computer company, I can highlight some of the benefits. Before there was a company PMO, all projects were little “islands” of work. The company wide PMO was staffed by several of the most senior PMs in the company and the main roles of the PMO were to:

• Train all PMs in the company methodology – this was compulsory for all PMs.
• Provide a consistent framework to review all potential projects to ensure that any response to an RFP that the company submitted had considered all the relevant areas of the plan, had achievable baselines, and risk was contained.
• Provided the framework for Quality audits or reviews of all major projects in execution to ensure consistent application of the company methodology, in particular financial, time, quality and risk management.
• Provide a formal mechanism for mentoring less experienced PMs.
• Allow for consolidated monthly reporting on all projects to assess any problem areas and attempt to even out risk among all company projects.
• Provide templates and tools that could be used not only throughout the USA projects but also were accessible globally.
• Implement a standard and comprehensive change management process for all US projects.

In conclusion, there are many quantifiable benefits of having a PMO for both a group of related projects in a program or as a company-wide function to improve project management over time in a company. There are also many intangible or “soft” benefits of a PMO such as common standards, methodologies, tools and templates, etc. that will have an eventual impact on the bottom line of a company even if they cannot be quantified at the individual project level.

The next post in this series will look at why you might want a PMO and at what stage you could think about creating one.

By Bruce Beer, PMP

Editor’s note: This is the first post in a series on PMOs.

PMOs are increasingly becoming the “in thing” these days, even though they have been around for many years. So this series of articles will try and answer several main questions –

• What is a PMO
• What is the Business Value of a PMO
• PMOs: Why should You Want One?
• Establishing a PMO – How Do We Do That?  
• Integrating the PMO Into the Organizational Culture/Creating a PMO That Lasts

 WHAT IS A PMO?

A Project (or Program) Management Office (PMO) can be considered as the coordinated project management of multiple projects – usually those within a program but can also be a Company resource to be used by all projects within that company.

OK so what do they look like and what do they do – how would you recognize one if you tripped over one?

At a high level a PMO –  

1. Provides guidance and support to all projects in the program or Company
2. Enables successful definition, integration, acceptance and implementation of all deliverables within a program.
3. Is the main mechanism for meeting customer satisfaction by providing a single point of contact for the customer (internal or external) , enabling effective communication between projects, PMO, and customers
4. Provides consistency and reliability of all deliverables and processes within a program or company
5. Minimizes gaps and overlaps between projects

     1. Provides guidance and support to all projects in the program or Company

It provides a common approach to all projects covered by the PMO, it can provide templates for tools used on all projects so that they all have a common look and feel, it can provide guidance for projects on how to plan and implement common quality and risk management policies, and because a PMO normally contains senior PMs, the PMO can also mentor the PMs of the component projects. This will have benefits for individual PMs, the program(s), and in the longer term, the company as PMs standardize their approach to projects.

     2. Enables successful definition, integration, acceptance and implementation of all deliverables within a program 

Whether you are a supplier providing project services for an external customer, or you are providing project services internally to your own company, a PMO can provide a central and coordinated point for definition of all requirements, integration of deliverables from different projects or suppliers, and coordinated acceptance and implementation of the deliverables from each project and the overall program.

     3. Is the main mechanism for meeting customer satisfaction by providing a single point of contact for the customer (internal or external) , enabling effective communication between projects, PMO, and customers

Having a single point of contact with the customer – whether internal or external – allows the customer access to one source for reporting progress, status of either the program or individual projects, issues, risks, and changes either at the project or program level. This will avoid the customer having to chase down the individual PMs within a program to obtain information which may then be inconsistent and even contradictory! If the customer has an issue on any of the constituent projects they know who to contact for answers or resolution.

     4. Provides the basis for consistency, reliability, and reduced risk for all deliverables and processes within a program or company

Consistency within a program is a sign of professionalism, rather than having a mixture of different standards, documents, contents, processes etc. thrown together, it looks like one unified production. Having one overview of all projects and requirements enables more efficient and consistent approach to the planning, integration, and implementation of requirements with reduced overall risk. For instance, integration of the schedules from constituent projects enables a unified schedule for the whole program, and can highlight the critical path through the whole program taking into account the dependencies within individual projects to be evaluated. Integrating risk and change throughout the program can enable the impact of risk or change from one project on any other project to be evaluated and managed. Because deliverables will be more consistent and integrated at the overall PMO level, the reliability of the resulting system is likely to be improved.

     5. Minimizes gaps and overlaps between projects

Just as with a project based WBS, a PMO level WBS will reduce overlaps and gaps between projects and their deliverables as viewed from the higher level. This will enable planning to be more comprehensive and complete, so reducing the opportunities for negative impacts on the key baselines.

The next blog in this series will look at the business value of PMOs, and how they can be cost justified and provide a positive ROI.

by Bruce Beer, PMP

Note: This is part 3 of a 3-part series.

The first in this series of Keeping on Track blogs dealt with how to keep your project on track with regard to time, the second dealt with how to stay within budget, this final blog in the series now looks at keeping to defined scope and how to avoid the dreaded scope creep!

As with time and cost, to be able to meet your scope baseline you first have to establish it. Project implementation can either be based on a firm, solid bedrock of requirements or it can be built on the shifting sands of indecision, false assumptions and differing interpretations that will eventually sink the project and lead to project failure, recriminations, accusations, heated arguments and potentially a visit to the unemployment office for the PM. So what are the basic requirements for a solid scope baseline and how do we create one?

The first step, often omitted, is to identify ALL project stakeholders – anyone who impacts or is impacted by the project. “Why is this” I hear you ask. Well any one of those stakeholders may have a requirement that is vital to the success of the project, and if we miss this requirement it may take time, money, and added complexity to include it later. So we will interview, perform surveys, have workshops etc. to ensure we get the full set of requirements at this stage rather than during acceptance testing! However, note that not all stated requirements will be included in the final scope of the project because each requirement has to be cost justified.

Once we have identified all requirements we can then start building our project scope by first identifying the deliverables required to meet them, then discussing and agreeing these with the customer (the person paying for the project) to decide which requirements are “must haves,” “wouldn’t it be nice ifs,” and “bells & whistles.” At this stage, if there are any areas of uncertainty, they should be clearly identified as definitely either “In scope” or “out of scope” just so that there is no ambiguity or room for interpretation at a later date. Then we can create the Work Breakdown Structure (WBS) – the heart of all project planning – based on these deliverables, followed by a specification. The WBS together with the specification creates the scope baseline. The purists amongst you will know that there is a third element of the scope baseline, the WBS dictionary, but we will not consider this now.

OK so now we have a solid scope baseline. We know exactly what it is the project has to deliver and have created a detailed project plan based on the WBS. All we have to do now is to ensure the project meets the three baselines. Controlling and meeting the scope baseline is probably the easiest of the three baselines to achieve as there is one main process used to control scope – change management. This means that ANY deviation from the original specification will need to be formally requested, evaluated and authorized by the customer before it is implemented. Some people may think that any change that does not involve additional time or cost does not need to go through the formal rigor of change management. These are probably the people out on the street looking for a new job wondering why their life took such a sudden and unexpected downturn.

Let us consider an example where a customer wants to change the length of an address line from 25 to 30 characters. Let us assume this is recognized before the programmer has written that section of code, so there will be no additional time or cost just to extend that field. So why bother to create a formal change request for such a simple change? OK, well let us look at this from three main viewpoints: ripple effects, acceptance and stakeholder satisfaction.

1.       Ripple effect

If there is no formal change management process, the programmer extends the address line and keeps this as a well hidden secret because they do not want the PM to find out they did it. What harm can it do? Let us suppose the address is part of the order input screen. Other areas of the software such as invoicing will be working on the specified basis of 25 characters per line, so all printouts, disc records, searches, etc. would use this basis. So the ripple effects of this apparently innocuous change can be many and serious.

2.       Acceptance

Now let’s look at acceptance for the above. During acceptance testing, the person performing the test will look at the specification (25 characters), incorporate any formal authorized changes (none), and will expect the test to meet this combined requirement (25 characters). The tester puts in a 24 character address, expecting it to be processed correctly. Then they will try a 25 character line with the same expectation. Then they try a 26 character line and expect it to fail and produce an error message, and guess what, it doesn’t do this, it accepts the over-length line without any problem. The tester will then declare that acceptance test has failed.

Now let us consider the correct procedure. The customer creates a change request for the address field to be changed to 30 characters and gives it to the PM (all change requests must go to the PM). The PM logs it and sends it out for impact analysis. The analysis comes back identifying other parts of the project that might be affected by the additional characters and additional changes that might be required. Then it might say that there is minimal or no time or cost impact. The customer would formally authorize this change and the change is implemented. The acceptance tester will see the initial requirement of 25 characters, will have the authorized change to 30 characters and will test accordingly, and lo and behold it passes acceptance.   

3.       Customer satisfaction

Now let us look at customer satisfaction. Consider a fairly substantial change. If the change does not go through the formal process it will not be formally approved, so in addition to failing acceptance we now have additional time and cost to worry about. We as PM are measured against how well we perform against the project baselines (customer expectations) for scope, time and cost, so immediately the PM now fails on all three baselines. If there had been a formal approved change request, the project would then meet the scope requirement (initial specification plus formally approved changes). If the project took longer than initially planned but there are formally approved change requests providing an audit trail for the additional time to perform changes, then the initial time estimate plus authorized additional time is the new measure against which the PM will be judged. The same with cost – the initial cost plus approved changes is the new measure for the PM, so providing they meet their initial estimates plus allowances for formal changes, all is good and a pay rise is on the horizon. In conclusion, formal change management creates an audit trail of authorization for any change to the original baselines.

Most companies these days will have a formal change management process with which the PM should be familiar and use. One of the key areas discussed by a PM during the project kick-off meeting will be to review, explain and distribute copies of the change management process to all stakeholders. The PM should explain the serious repercussions of not following this process! If the customer is not at the kick-off meeting, the PM should review and agree the process with them prior to the start of implementation to ensure it is understood and agreed.

Final thought: if you have read all these blogs you will know they are highly interrelated. If time or cost start going out of control, one option depending on constraint priorities is to de-scope the project to bring it back on track. De-scoping will involve looking at “bells & whistles” first to see which can be removed with least impact on the end product. Once all of these have gone, the next object of your gaze will be the “wouldn’t it be nice ifs.” If you reach the end of these and are left with the prospect of de-scoping some of the “must haves,” you have a serious problem. Removing any “must haves” will affect the viability of the project, so at this stage scope cannot be reduced further. You will need to review cost and time to reach the optimum results.