Creating a PMO business case through a business analysis approach

Abstract

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) (Project Management Institute, 2008) defines a project management office (PMO) as “an organizational body or entity to which are assigned various responsibilities for the centralized and coordinated management of those projects that fall under its domain” (p. 11). The focus of this definition is clearly on the project side. But a company PMO must always be introduced as a business solution. This means a PMO must be configured as an organizational entity (real or virtual, formal or informal) that has to deliver real and measurable value to the business; if this is not the case, the PMO sooner or later will disappear. The value of the PMO is usually designed through the PMO business case, where the PMO solution components, the implementation approach, and the benefit and cost ‘logics’ are described and analyzed.

The BABOK^® Guide (International Institute of Business Analysis, 2009, p. 81) shows that the business case is always the final task of a bigger process called “Enterprise Analysis.” This process includes these tasks: (1) Define business need (What is the business problem/opportunity the PMO has to solve/catch?); (2) Assess capability gaps (What are the missing business and project capabilities that the PMO has to introduce?); (3). Determine solution approach (How do we intend to implement these missing capabilities?); (4) Define solution scope (What are the PMO solution components?); and (5) Define business case (What are the PMO benefit and cost logics?). To build a proper business case, the entire enterprise analysis process should be followed. Why? Because through the entire process the business needs are elicited. And the most important task of this process is the first one (it is a waterfall schema)—define business need—the way how the business need is defined can impact dramatically the PMO business case, and the PMO implementation project.
This paper shows the business analysis approach for defining a PMO business case through a full enterprise analysis process and introduces some useful techniques to define the PMO benefit and cost logics tightly linked to the business need. This paper will not speak about maturity levels of a PMO, or organization structures and functions of a PMO. So much has been written in literature. It rather presents a general approach for building a PMO business case, which is applicable to many different situations.

Foreword

The main purpose of a PMO as business solution is to keep both the business and project sides aligned, while continuously improving the performances of projects. When the business environment and the priorities of management change, this PMO must react and as fast as possible reorganize the projects priorities accordingly. Business must always be first. This PMO model is valid both in positive and negative economies: in a booming economy, where the company has normally launched several projects, the PMO is more focalized in the coordination and management of many projects; in a faltering economy, management becomes more careful in selecting projects (portfolio management) and is expecting a flexible delivery organization and higher performances from the project teams. In both situations, the PMO's purpose is to keep business and project always aligned. As a consequence, the PMO is a dynamic organization.
But how can we describe the value of a PMO? The answer to this question lays in the PMO business case. Building a PMO business case is a business analysis task, and the business analysis discipline is well described in the BABOK^® Guide (International Institute of Business Analysis, 2009). Building a PMO business case is the final task of a bigger process called Enterprise Analysis.

Enterprise Analysis for a PMO Solution

Introduction

According to the BABOK^® Guide:

Enterprise Analysis describes the business analysis activities necessary to identify a business need, problem, or opportunity, define the nature of a solution that meets that need, and justify the investment necessary to deliver that solution. Enterprise analysis is often the starting point for initiating a new project and is continued as changes occur and more information becomes available (International Institute of Business Analysis, 2009, p. 7).

For a PMO initiative we can select the following business analysis tasks:

1. Define business need—Analyze the business environment to understand the problems the PMO has to solve or the opportunities to catch;
2. Assess capability gaps—Assess the capabilities of the enterprise in order to understand the change needed to implement the PMO;
3. Determine solution approach—Determine the most feasible PMO solution approach;
4. Define solution scope—Define the PMO solution components; and
5. Define business case—Develop the business case for the PMO, in terms of benefits, costs, and evaluate the risks of this initiative.

Exhibit 1: The Enterprise Analysis Tasks for a PMO as Business Solution Initiative

Define Business Need

The business need defines the problem or opportunity that we are trying to find a solution for through our PMO, from a business standpoint. It describes the core reason of our PMO. This task is the most important. How the business need is defined determines which alternative solutions will be considered, that stakeholders that will be consulted, and which solution approaches will be evaluated. It drives the choice of the level of maturity of our PMO. The business need for a PMO can be generated in several different ways:

• From the top down—i.e., the need to achieve strategic goals through the PMO;
• From the bottom up—i.e., a problem with the current state of a project, a request of support from a project/program manager;
• From middle management—i.e., business managers and project managers need additional information to make sound decisions;
• From external drivers—i.e., driven by customer demand, procurement needs, or business competition in the marketplace.

In this task initially, we identify the business and project stakeholders, understand their level of interest and commitment, and establish the proper management strategies (How are we building the stakeholder support?). One important stakeholder is called “business case owner.” For a business case to be credible and accepted it must be validated or “owned” by someone in the organization who is the financial key player in the management team (whether or not this person is part of the decision maker(s)). The owner agrees with the overall structure and setup of the business case. Specific numbers (e.g., expected benefits) will be validated by other people in the organization (e.g., business and project stakeholders). With the business case owner, we define the business case parameters (the approach-cash flow based, before or after tax; the investment measure like payback period, NPV and IRR; acceptable values or minimal requirements for the selected investment measures; the evaluation period to take into account; the cost of capital; what to capitalize and how to depreciate; the discounting interval—e.g., yearly, quarterly —and what to use as “period zero”; the business case presentation strategy, etc.).

Then we start exploring (eliciting is the proper business analysis terminology) the project managers' and business managers' needs. In order to define the needs, these elements must be considered:

• Adverse impacts the problem is causing within the organization and quantify those impacts (e.g., potential lost revenue, inefficiencies, dissatisfied customers, low employee morale, high turnover, etc.);
• Expected benefits from the PMO (e.g., increased revenue, reduced costs, increased market share);
• How quickly the problem could potentially be resolved or the opportunity could be taken. This has an impact on the PMO implementation approach;
• The cost of doing nothing. And this topic actually sets the ‘baseline’ of our PMO business case; and
• The underlying source of the problem.

In defining the business need, it is very important also to describe the so-called “desired outcome.” A desired outcome is not a solution. It describes the business benefits that will result from meeting the business need and the end state desired by the stakeholders. Proposed solutions must be evaluated against desired outcomes to ensure that they can deliver those outcomes.

Business Needs must also be prioritized.

Several techniques may be used to accomplish this task (benchmarking analysis, brainstorming, business rules analysis, focus groups, functional decomposition, root cause analysis, value chain analysis, etc.).

From research conducted some years ago together with the Northern Italy Chapter of PMI^®, we asked companies: “Why did your enterprise decide to start a PMO and who were the former supporters?” The research revealed that the main reasons why PMO organizations had started was to improve the results of project initiatives (time, cost, quality). Among the business stakeholders the main supporters were the top managers, the business unit directors, and financial directors.

Exhibit 2: The Results of a Research Conducted in 2007 with the PMI^® - Northern Italy Chapter

Assess Capability Gaps

This task assesses the current capabilities of the enterprise and identifies the gaps that prevent it from meeting the business need and achieving desired outcomes. In this task, we determine if it is possible for the organization to meet the business need using its existing structure, people, processes, and technology. If the organization can meet the business need with existing capabilities, the resulting change is likely to be relatively small. Otherwise the effort for change will increase.

Assessing the current capabilities of the organization for a PMO initiative, can be done at two levels:

1. Evaluate the organizational culture: evaluate how strong the organization is in conducting change projects, assess the style of authority, etc.; and
2. Assess the current project management capabilities: assess the current project management capabilities and compare the current state with the business need, in order to select the new capabilities to be implemented. For this purpose, a “PMO Catalog of Services” is always a good starting point. There are several examples in literature; some companies have defined their own catalog of services. Some key performance indicators (KPIs) linked to the new or improved capabilities can also be defined at this stage.

As it will often be difficult or impossible to prove that the delivery of a new capability will meet a business need, even in cases where it appears reasonable to assume that the new capability will have the desired effect, assumptions must be identified and clearly understood, so that appropriate decisions can be made if the assumption later proves invalid.

Several techniques may be used to accomplish this task (document analysis, SWOT analysis, etc.).

Determine Solution Approach

The main objective of this task is to identify as many potential options as possible in order to fill the identified gaps in capabilities. The solution approach describes the general approach that will be taken to create or acquire the PMO capabilities required to meet the business need. To determine the solution approach, it is necessary to identify possible approaches, determine the means by which the solution may be delivered (including the methodology and life cycle to be used), and assess whether the organization is capable of implementing and effectively using a PMO.

These are some possible approaches:

• Utilize additional capabilities of existing solutions that are already available within the organization;
• Purchase or lease capabilities from a supplier (buy);
• Develop the capabilities internally (make);
• Make organizational changes; and
• Partner with other organizations.

The type of PMO (level of maturity) and the resources types and numbers that will be allocated for building and operate the PMO are selected in this task. As well as the position the PMO will occupy in the organization. The output of this task is the first feasibility study, what we call the top-down or high level PMO business case. Several techniques can be used to build a high-level business case, such as value chain analysis, benchmarking, etc. This high-level business case can be used to validate the detailed business case. Exhibit 3 shows the technique that can be used for building the first iteration of the benefit and cost logics.

Exhibit 3: The First Iteration of the Benefit and Cost Logics

Benefits and costs can be defined at a high level, through interviews, field observations, benchmarking studies, etc.

Also in this task, assumptions and constraints that may affect the chosen solution should be identified. Certain solutions may be ruled out because they are believed not to be viable technically or for cost reasons, while other approaches may be believed to be easier to execute than they really are. Similarly, the organization may be constrained from pursuing certain solution options for contractual reasons or because they do not fit with the infrastructure of the organization. Assumptions and constraints should be questioned to ensure that they are valid.

Several techniques may be used to accomplish this task (benchmarking, brainstorming, decision analysis, estimation, SWOT Analysis, etc.).

Define Solution Scope

The purpose of this task is to conceptualize the recommended solution in enough detail to enable stakeholders to understand which new capabilities the PMO will deliver.

The solution scope includes these elements:

• The scope of analysis which provides the context in which the PMO is implemented;
• The capabilities supported by the PMO;
• The capabilities to be supported by individual releases or iterations; and
• The “enabling capabilities” that are required in order for the organization to develop the PMO capabilities.

The PMO is described in terms of the major features and functions that are to be included (PMO solution components), and the interactions that the PMO will have with people and systems outside of its scope. In-scope and out-of-scope components of the solution should be stated. Describe the business units that will be involved, business processes to be improved or redesigned, process owners, and IT systems and other technology that will likely be affected. One of the most common tools used for designing the PMO solution scope in the context diagram.

Exhibit 4: The PMO Context Diagram

In this task is also defined the implementation approach, which describes how the chosen solution approach will deliver the solution scope. Before that, the PMO solution components must be prioritized together with the stakeholders.
If the PMO solution approach involves partitioning the proposed PMO project into releases that will deliver useful subsets of functionality to the business, the implementation approach will describe also the functionality in each release and the timeframe that it is expected to be delivered in. If the solution approach involves outsourcing solution components, the implementation approach will also define which components are candidates for outsourcing, or the process that will be used to identify those candidates. The implementation approach may break delivery down into specific releases or provide a roadmap that indicates the timeframe in which a capability can be expected.

This task also defines the major business and technical dependencies that will impose constraints to the effort to deploy the solution, including dependencies that may exist between solution components.

Several others techniques may be used to accomplish this task (functional decomposition, interface analysis, scope modeling, user stories, etc.).

Define the Business Case

The business case describes the justification for the PMO in terms of the value to be added to the business as a result of the deployed solution, as compared to the cost to develop and operate the solution. It may include qualitative and quantitative benefits, estimates of cost and time to breakeven, profit expectations, and follow on opportunities. The business case may present expected cash flow consequences of the action over time, and the methods and rationale that were used for quantifying benefits and costs.

The first step in building the PMO business case consists in defining the so called “benefit logic.” The benefit logic shows how the components of the PMO will lead to positive cash flows: It establishes the logical links between cash-flows generation, benefit areas, opportunities and components of the solution. Building the benefit logic is an iterative process: We start form a blank sheet and put on the right side the “benefit cash flow” and on the left side the “PMO solution components”; then we must understand the link between the two.

Exhibit 5: Building the Benefit Logic (1)

In real cases, a benefit logic can be more complicated than the one shown in Exhibit 5. Once the benefit logic is developed, we must define the target KPIs for some of the boxes (we must expect that for some boxes it will be difficult to estimate). By doing so, we identify improvements area that are quantified and documented in a specific “opportunity chart.”

Exhibit 6: Building the Benefit Logic (2)

Many techniques can be used to quantify the benefit (workshops, interviews, diagnostics, and observation). The ideal situation is that benefit quantification is totally validated by the stakeholders, though it is not easy. This is the great value that the “enterprise analysis” process actually brings to the PMO business case development.

Once the benefit side of the business case is defined, we are ready to switch to the cost side. In this case, we follow the same approach in order to define the “cost logic” and the related “costing chart” and categories.

Exhibit 7: Building the Cost Logic

To define the cost logic, we must ensure that the PMO solution scope is clearly defined, check that all potential information sources have been explored, be prepared to manage price expectations, encourage more than one estimate of cost (best, likely, worst), identify and formalize all assumptions and constraints, be prepared to adjust plans to help meet client expectations, consider risks, and provide necessary contingencies (cost and lead-time).

Part of the business case preparation effort should be dedicated to the initial risk assessment, in order to determine if the proposed initiative carries more risk than the organization is willing to bear. This initial risk assessment focuses mainly on solution feasibility risks, and is revisited throughout the project.

Also, the non quantitative costs and benefits should be identified.

Once all data are prepared, we start the PMO business case analysis and produce the financial model of the business case, i.e., the combination of the benefits logic and the cost logic; it calculates the investment measures (like IRR, NPV, payback, etc.). Be careful in communicating the strength of an invalidated business case to the stakeholders.

Some useful hints for the presentation of the PMO business case:

• Use graphs and pictures instead of words and numbers;
• Make clear all assumptions that have been made and reference all data sources;
• Go straight to the point, details can be supplied in appendices or a separate document;
• Never try to avoid critical issues or be defensive about the numbers;
• Prepare for client objections;
• Use the company existing presentation template;
• Benefits should be grouped into areas of impact so that they can reflect the real objectives;
• Show how individual benefit areas add up to the total benefit value;
• For each benefit area identify the key assumptions that produce the benefits, and reference their sources;
• Benefits should be calculated from an agreed baseline. They should include the cost of doing nothing, and the assumptions made must be explained clearly;
• Non-quantified benefits should be mentioned as well;
• Show the breakdown of the main cost elements from the cost logic;
• Separate clearly cost categories: capital investments, one-time operational costs, recurring operational costs;
• Show the impact of alternative implementation plans; and
• Clarify the basis of assumptions about the cost of the clients own resources.

Several techniques may be used to accomplish this task (decision analysis, estimation, metrics and key performance indicators, risk analysis, SWOT analysis, vendor assessment, etc.).

Final Words

Building a PMO business case is a complex business analysis effort that begins with the definition of the business needs and ends with the definition of the PMO solution components and assessment of benefits, costs, and risks. The entire “enterprise analysis” process is very important as it forces the elicitation of business and project stakeholders needs. The word elicitation is derived from the Latin verb ex-ducere, today we say “educate.” Eliciting the stakeholder needs is the most delicate part of business analysis, and should be done in a professional way. The results of this elicitation process are all visible throughout the all business case, which is not simply a set of figures about a project initiative, but represents the starting point for the PMO implementation project and for justifying the value that it will be able to deliver. This paper intends to show the business analysis approach for defining a PMO business case through a full enterprise analysis process.