Forward Momentum: Delivering Results

By Bruce Beer, PMP

OK – you have been asked to manage a new major project that is an integral part of your company’s strategy (or your customer’s strategy if you are providing project services) and the cost is estimated to be in the 8 to 9 figure range.

Where do you start?

A very large project would probably be a program (a group of related projects) rather than one single project, so you would probably need a Program Management Office – PMO – to manage this juggernaut. I would suggest that in most cases you would start with the PMO management infrastructure. Assuming you are to be the program manager, on a major program you will probably need a deputy to help with the workload and cover for any absences you might have.

I have worked in two different types of programs in the $300m to $500m range. One was global, one was domestic. One of them included individual PMs as part of the PMO; the other just included the key PMO functions and did not include the PMs in the team. My experience leads me to believe that the former – PMs as part of the PMO team – is preferable, so I will use this assumption for the rest of this article.

Let us look at the makeup of the PMO for a major undertaking. Apart from the management and administrative people, most major programs could warrant a full time quality manager, risk manager and schedule manager. You could have someone responsible either full time or part time to manage change. This could include changes within the PMO, but also possibly management of change within the company where introduction of the end result of your program may affect organization, structure, personnel and processes. In other words, they would manage what needs to be changed outside of the program to enable the expected and required result to be effective. You might also assign someone to manage program reporting.

Quality Manager’s Role
This is the person responsible for creating the program plan detailing quality, which could include:

• Policy
• Metrics
• Assurance
• Control
• Audits
• Internal and external standards to be met
• Common tools and applications to be used – type and version/rev level
• Method of updating of common tools and applications
• Archiving policy

The quality manager would try to ensure consistency across all projects to give the program a common look and feel, and plan and manage regular quality reviews/audits throughout the life of the program to ensure the quality plan is being followed by each project. They would also ensure the defined metrics are being measured and reported as defined in the quality plan.

Risk Manager’s Role
This person would be responsible for working with individual PMs to identify and quantify risk on each project, highlighting those that need further effort to minimize risk at the project level, and assess any risks to other projects or the overall program by any one or more individual project risks. The risk manager would attend project level risk meetings and take the high level view on threats (or opportunities) at the program level, implementing risk reduction measures as appropriate. This person would be responsible for coordination between individual projects where appropriate.

Scheduling Manager’s Role
This person would work with individual PMs to ensure they had a schedule at the correct level of granularity, with critical path identified and processes in place for regular updating. They would then amalgamate these plans into a program level schedule at the appropriate level of granularity. This should then identify the critical path through the program showing which projects, or deliverables within a project, are on the program level critical path. This is key for the PMO to know, manage and review on a regular basis. The risk and scheduling managers would need to work very closely together, as any identified time risks can be monitored closely between them, particularly for deliverables/activities on the program level critical path.

Reporting
Reporting may not be a full time position in the PMO but it is a very important one. I was asked to create a reporting system for a major PMO and I designed a three-level reporting system. Each project completed a project level status report which was sent to the PMO on a weekly basis. These were rolled up and a PMO level report was created, automatically hyperlinking project information to a one line status report per project. Use of color was important (red, yellow, green) to identify problems where the PMO management might need to focus or work proactively to avoid or minimize impacts on the overall program.

The final layer of report was for senior management. This needed subjective judgments and assessment from the PMO so it could not be automated.

This role would also include financial reporting – actual costs to date, forecasts for future and comparison to the financial baseline/budget. This report would go to senior management so the specific information, format and frequency would need to be discussed and agreed with them.

Management of this major undertaking may depend on the size and complexity of the program but in my experience, a regular meeting of the PMO (including the individual PMs if possible) would review each project, scheduling and risk issues, changes and project issues, and resolve any conflict or interfaces between individual projects. Any potential threat to the overall program timeline, budget or deliverables can be highlighted, discussed, resolved and reported.

In conclusion, for very large projects (programs), the main PMO team could include the program manager, deputy, admin, scheduling manager, risk manager, quality manager, someone responsible for change, someone responsible for reporting and, in my opinion, each of the individual PMs. How many of these roles, and any additional roles such as external communications, security, networking, infrastructure etc., that may be required depend on the size, complexity and criticality of the program. Rather than assessing just the cost of the PMO which could be relatively high, it is more reasonable to consider the value the PMO provides compared with the cost of failure of the program due to inadequate management. Then a PMO can almost always be cost justified.

What positions have you involved in your large-scale project? What worked? What didn’t?

by Vicki Wrona, PMP

I recently learned about a tool called the OODA loop. While the tool itself was created based on military fighter pilot observations and is now often used to train law enforcement, it has applications for use in business and personal life as well. Here we will discuss the applications of the OODA loop in business, and more specifically, in managing projects.

First of all, OODA stands for:

1. Observe
2. Orient
3. Decide
4. Act

The concept of the OODA loop was first created by US Air Force Col. John Boyd during the Korean War. We all naturally follow this loop. If you are in a confrontation, you want to interrupt, or get inside, somebody else’s loop so that you instead of following, you now lead and can react faster than they can. At that point, they are chasing you on your OODA loop terms. This technique is often taught to police officers and law enforcement. For example, if someone were to break into your house, they know what they intend to do and so their OODA loop is ahead of yours. What you want to do is somehow disrupt their loop, or get inside it, so now you are the one in the lead. While this loop works well with quick reactions, it also works with longer-term decisions that need to be made. Let’s explore this.

In business, this can be used to manage projects, staff or operations. Let’s take the example of a project that is already in process. Once a plan is in place, the project manager will monitor the progress made on the project to make sure it’s on track. That is the first stage of OODA, Observe. The second stage, Orient, has to do with watching the work as it progresses, listening to what is going on, analyzing the reports that are pulled, talking to stakeholders, etc. In pulling information and data from as many sources and vantage points as practical, you can determine if the project is on track and progressing as planned. There will be variances from plan; you need to decide if they are normal or an indication of trouble. Based on this, you move to step three, which is to Decide what course of action, if any, is needed. Maybe you need to add more resources to a particular piece of work to keep it on time. Maybe you need to look at options to cut cost in order to stay on budget. That’s your decision here. The next step is to Act. You follow through on that decision, and then repeat the cycle to observe the impact of your decision and whether to take additional actions. By nature, this cycle repeats constantly throughout the project.

This technique can be very useful in noticing and rescuing a troubled project earlier rather than later. What we want to do is interrupt what is going on in the project and improve it.

This cyclical process may sound very familiar to experienced project managers. This is similar to the PDCA (plan-do-check-act) cycle made famous by W. Edwards Deming. The cyclical nature of these cycles is built into project management and should be done constantly to effectively and pro-actively manage our projects. The Six Sigma version of PDCA is called DMAIC (define, measure, analyze, improve, control). Kaizen, also called continuous improvement or “for the better”, also follows this concept. With kaizen, small improvements and corrections are constantly being made to keep a project on track or to improve existing processes.

The reason I like the OODA loop concept is because, at least for me, it adds an extra dimension to the PDCA cycle. This dimension is the thought of interrupting and getting inside the loop on the bad things that are happening on your project or within your teams. It enhances the ability to adapt more quickly by remembering that we have to interrupt the current flow of work or status quo in order to put things back on track. With our teams, we may have to shake up our team in some way to get them out of their current rhythm or comfort area in order to do what is best. It is also adaptive in that on projects, the plan you go back to when you have completed a cycle may be different from the plan before the cycle was completed. This is fine, as long as the proper change control processes and sign-offs are followed.

While the PDCA cycle is cyclical in nature, I have observed that it tends to be viewed more methodically, slowly and with a longer-term attitude. That is not always true, of course, but that is how it often comes across to me in practice. The PDCA cycle is not always long-term and the OODA loop is not always short-term and quick, but when thinking of these concepts, it helps for me personally to keep them both in mind in order to properly manage my teams and initiatives both quickly and methodically.

Here is a link to a good description of the OODA loop in business called The OODA Loop: Playing chess with half the pieces. It is a book review with notable quotes on agility, overcoming the numbers, planning and strategy, on not following the rules, and on culture as a long-term competitive advantage from the book Certain to Win.

Think about the OODA loop and how it may apply to your processes, operations, teams or projects. How can you use this new perspective to better manage those?

By Kathy Martucci, PMP

Note: This is part 3 in our series on portfolio management. Part 1 is Projects Projects Everywhere: A Portfolio Management Approach, part 2 is Elements of Portfolio Management: Developing the Compelling Business Case.

Previously we have presented the overall Project Portfolio Management Process and offered some guidance on writing a solid business case.  Business case development is under the purview of the functional manager who is requesting the project be considered for part or all of the organization’s scarce resources. However, the Portfolio Management Committee (PMC) has its work cut out for it, too.

Perhaps the PMC had developed the template for the anticipated business cases. Let’s assume they have, since they know (or should know) what they need to see from the functional managers in order to make decisions on what projects will go forward. Now, as the deadline for next fiscal year’s proposals nears, the members of the PMC must understand and agree on how these new or improved business cases will be analyzed for the initial, high-level evaluation of their size, complexity and alignment with the organization’s corporate strategy. During this process, projects that do not meet these established criteria do not make the first gate and are not analyzed any further.

A thoughtful, proactive approach to developing the criteria, the decision matrix if you will, may include the following:

1.  Brainstorm evaluation criteria
Brainstorm any and all evaluation criteria appropriate to the situation. If possible, involve customers in this process. General categories such as feasibility and effectiveness are difficult to evaluate, so, when possible, drill down into the categories to define criteria that may be more easily scored.  It should also be noted here that annual review of the matrix is key to staying current with corporate strategy, market conditions and other factors. Possible criteria will include:

• cost (order of magnitude costs may be available at this stage)
• time to accomplish
• financial payback
• resources required (for example, money and people)
• customer pain caused by the problem
• urgency of problem
• effect on other systems
• management interest or support

2.  Refine the list
After all ideas are on the table, refine the list (there should not be more than 6-8 key criteria considered or the process becomes too unwieldy) and ensure that everyone has a clear and common understanding of what the criteria mean. Also ensure that the criteria are written so that a high score for each criterion represents a favorable result (more likely to pass the gate) and a low score represents an unfavorable result.  Criteria such as cost, resource use and difficulty can cause confusion: e.g., low cost may be highly desirable.  This can be avoided by rewording the criteria to state “low cost” instead of “cost”; “ease” instead of “difficulty.”

3.  Assign weights to criterion
Assign a relative weight to each criterion in cases where some decision criteria are more important than others. In a tight budget year, low cost may carry more weight than customer pain. Other years, alignment with strategic direction regardless of costs may be more heavily weighted.  The assignment can be done by discussion and consensus or each member can assign weights.  Then the numbers for each criterion are added for a composite team weighting. This step often produces a lively debate!

4.  Determine scoring range and representation
Determine the scoring range and ensure that all PMC members have a common understanding of what the scores will represent.  One of several ways to do this includes establishing a rating scale for each criterion. Some options are:

• 1, 3, 5 (1 = low, 3 = medium, 5 = high)
• 1, 2, 3, 4, 5 (1 = little to 5 = great)
• 1, 4, 9 (1 = low, 4 = moderate, 9 = high)

Enhance the committee’s agreement and understanding by coming to consensus on definition and fully documenting the scale. For instance:

Financial Payback:
Low Score (1 point):
Net profit potential generated in the first 3 years after implementation is expected to be less than $5M per year.

Medium Score (3 points):
Net profit potential generated in the first 3 years after implementation is expected to be between $5M and $15M per year.

High Score (5 points):
Net profit potential generated in the first 3 years after implementation is expected to be greater than $15M per year.

Once the decision matrix is developed and institutionalized (it may require review and approval from other stakeholders), it will be used in the Project Portfolio Management Process to create a prioritized list of open business cases. The prioritization provides a blueprint of which projects will be the ones to receive further attention from both the functional business units and the PMC.

Food for thought: What evaluation criteria are most important to your organization?

By Bruce Beer, PMP

Note: This is the fifth and final post in a series on PMOs.

In the previous four blogs in this series we looked at defining a PMO, the business value that they bring to a company, why your company might need one, and how to establish one. In this final blog of the series I want to look at how this new bright and shiny PMO might be integrated into the organizational structure and not just be regarded as a new “toy” that will shortly outlive its usefulness once the novelty goes away. In other words how do we internalize the necessity and contribution to strategic goals of a PMO to provide maximum contribution to your company and justify the high cost in terms of its even higher value?

There are two main types of PMOs in my experience:

1. Those that are created to manage a major project or a program (for the duration of this article I will use the generic term “program”) and will disassemble itself at the end of the program, or
    
2. A Company PMO that is established to form a “Center Of Expertise” for project management. It is there for the benefit of all projects undertaken by the company and remains in existence as different projects form and finish.

Program PMO

Let us consider the program specific PMO first. This is created to manage a specific program and is created generally during Initiating and remains until the late stages, probably into the formal Close. It is customized for that specific program, so it’s forming and ending will be dependent on the specific needs of that program.

The value of the PMO in the overall control and management of generally a large program can justify the cost by providing significant value. The areas where value can be demonstrated are areas such as coordination between the projects within the program and understanding and managing the potential ripple effects of issues, risks, and changes on one project with respect to all other projects. With regard to change management, if a change is implemented in one project in a program in isolation, the impact on other projects may not be recognized until final acceptance testing or even worse, in initial live operation.  For example, understanding how changing a database record in one project may impact other projects using the same database is critical.

If a company starts using program-specific PMOs, the value should be immediately apparent, particularly by considering what might have happened if the PMO had not been in place. One major advantage for senior management is coordinated reporting at the program level rather than having multiple project reports. This allows them to now have the overview or “big picture” on the status of the program in one report.

Other key areas where a PMO provides significant value by overseeing all projects in a program are:

1. Scheduling – identifying the critical path of all projects in the program, plus the critical path within each critical path project. Any issue affecting an individual project completion date for a critical path project will impact completion of the overall program. It might be a good idea to recognize and incorporate this into the overall plan.
    
2. Risk – if a known or unknown risk occurs on a project and a contingency plan is implemented, does this impact the ability of other projects to complete successfully on time and on budget? Is the overall program under threat? It would be highly beneficial to the overall success of the program to know this.
    
3. Quality – having a common methodology and project tools/templates will result in a common look and feel for all elements of the program and enable interfaces between them to be more easily defined and implemented. It also opens up the opportunity for reuse both within this program and for future similar programs.
    
4. Cost – overall cost of a program is composed of the costs of each individual project, and escalation of cost on one project will impact the overall cost of the program. Forecasting the latest cost of a program will be significantly more accurate by taking an integrated view of the whole project and can lead to one overall financial report rather than multiple financial reports from each project.

For this type of program-specific PMO, the benefits and value of a PMO should be clear, so the use of PMOs should be easy to justify and institutionalize for large programs.

Company or Permanent PMO

A PMO that is established on a more permanent basis for use by all projects in the company has many advantages to the company.

1. It can be the creator and keeper of the company project methodology and historical database. It can create common tools for use on all company projects. (This will allow easy re-use of tools and templates). It can also create and implement a common approach for quality and risk management throughout all company projects.
    
2. It will encourage all company PMs to utilize the company standards, methodology, tools, etc., leading to a unified company approach to projects and project management. It can also provide project auditors to perform regular or adhoc reviews of projects in execution to ensure all project standards are being met and to gather lessons learned from each project throughout the project lifecycle.
    
3. It allows members of the PMO to mentor and coach company PMs, again to help institutionalize a company methodology.
    
4. It can accumulate “best practice” documents that can easily be stored in a library and re-used for all future projects, saving cost by having a group of standard templates such as a quality management plan, a risk management plan, a change management plan and most other “management” plans so that projects are not reinventing the wheel for every project.  Once the company quality policies and procedures are created, the quality management plan will be “standard” for all company projects.

 Integrating PMOs Conclusion

In conclusion, the value of either type of PMO should be clear, and the improvement in resulting projects will not only justify the cost of the PMO, but enable higher quality projects with an increased probability of meeting the key project baselines of scope, time, and cost. Once a PMO has been created and used on a major program or multiple company projects, the benefits should justify their use. The PMO will be incorporated into the company approach to projects and become institutionalized.

PMO Series Conclusion

Overall I hope that this series of articles on PMOs has shown what they are, the business value that they bring to a company, why your company might need one, how to establish one, and in this final post of the series I hope I have showed how a PMO might be integrated into the organizational structure. In this way, it can become a valuable asset for a company to use to improve their ability to manage large programs or to establish the framework for management of all projects in a company.

PMOs can be expensive but the value they provide to a company will normally far exceed the cost. They should standardize a company’s approach to projects, lead to time and cost savings, gradually improve the project management ability of the company, and make projects a valuable tool for a company rather than something to be feared.

How has your organization incorporated a PMO into its culture? If it hasn’t, what would it take to do so?