Using the power of program design to improve final outcomes

Abstract

The business purpose of a project is to help the organization deliver more value. That means that we need to know the following:

1. Who has accountability for benefits realization?
2. How much value is projected to be delivered?
3. How much value was actually delivered?
4. What obstacles prevented us from delivering greater value?
5. What needs to change to improve project performance across all future projects?

The success of a project depends on many factors, and the interaction of these factors can lead to complications. The base complexity of a project will depend on what is being delivered. Although the base complexity of a project cannot be changed, many of the added complications can be reduced or eliminated before the project starts, by changing initial conditions. The difficulty and risk of a project will be determined by those controllable initial conditions. The worse they are, the greater the risk. Initial conditions can rarely be rectified through management and control (coping) during project delivery. Poor initial conditions impose both additional cost and additional risk, which has contributed to low project success rates and reduced value delivery.

This paper contends that every project should be delivered as part of a program and that systematic program design be used to optimize initial conditions. Doing so can significantly increase the likelihood of project success. A focus on value delivered and a focus on the proper design of whole programs should be the central focus of any project management office.

Introduction

“We were doing fine, but then we ran into complications. As a result we lost the patient.”

Surgeons understand that it is critical during surgery to avoid complications. When a single complication arises, risk goes up dramatically. Therefore, doctors take great care to ensure that anything that can be done to reduce complications during the actual surgery is taken care of before the surgery takes place. The main purpose of surgery is to help the patient get better, not to test the limits of the surgeon’s skills. Great skill and concentration is required to succeed even under the best of circumstances.

A project is similar to complex surgery. There are enough inherent difficulties with producing the defined deliverable that additional complications simply push the risk far too high. Today’s project manager has to deal with the complexities of delivery and all the complications that surround it. Many of those complications could be reduced or could be eliminated prior to the project starting.

These are examples of unnecessary complications that can be resolved prior to project launch:

1. Lack of accountability for benefits realization
2. Lack of requisite support
3. Insufficient user resources and engaged participation
4. Poor, inadequate, or untimely resourcing
5. Lack of strategy connection
6. Overestimating business benefits
7. And others

Imagine a project where everything went right. Would not such a project have a much higher likelihood of success? Of course, it may not be possible to have everything go right, but that does not mean that that we should not try to set right everything that we possibly can. Many of the items on the list need to be resolved before the project begins, before a project manager is even assigned. In fact, they should be resolved as a condition for starting the project. When a project begins, it should take off like an airplane. A pilot will hold the breaks and gun the engines. Only when the engines are at almost full power does she let go of the brakes. That provides enough momentum to get the plane off the ground. The same should be true for projects. Hold the brakes as long as the initial conditions are not optimal. Only when they are, should we release the project for flight. Once a plane is in the air, it is very difficult to fix any serious problems. It is the same for a project. Once launched, it is difficult to address any serious issues without increased risk and cost.

There is enough complex planning and work to be done without the added risk of poor initial conditions. The focus of the project manager and project management has been to quickly get the project started and then deal with issues in flight. This does not work effectively. Trying to make up for poor conditions by controlling execution (task control) is not effective. The result is that project management, at least in the technology sector, seems to be stuck at a success rate of about 30 percent. In addition, this rate has budged very little in the last decade or two. As hard as project managers may work, they cannot seem to budge this number.

Can this number be significantly improved? I believe it can. We should be able to get it to over 50% relatively quickly with good program design and management without increasing total cost. We just need a little shift in focus. We need to give the project manager a little help. We need to set projects up for success by design. In addition, systematic program design is the way to do that.

The Program as the Center of Focus

The Standard for Program Management (Program Management Institute [PMI] 2006, p. 4) specifies, “A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.” The standard also says that the focus of a program is on benefits, whereas the focus of a project is to deliver a product, service, or capability. However, the benefits typically flow after the project is completed and not during its execution. Therefore, benefits are not within the span of vision of the project. That means that business success, which depends on realizing benefits, is outside the span of vision of the project. Therefore, we need a wider span of vision.

To achieve that wider span, let us explore an alternative, yet complimentary, definition of a program.

Programs are often assembled from existing projects by evaluating their degree of interrelatedness. This may be a way to improve the management of projects—efficiency. However, such a bottom-up approach begins with a pool of already identified projects. The underlying assumption is that the pool already contains the appropriate projects. Often this is a false assumption providing a poor starting point.

The project pool is typically populated by functional interests. They are more often than not championed to deliver functional solutions rather than enterprise performance solutions. This pool is often the starting point for project selection. Such a pool may not contain the more important initiatives required by an organization. In particular, cross functional problems have a tougher time making it into the pool.

An alternative use of programs is as vehicles for consistently and reliably managing the delivery of measurable value outcomes linked to strategic objectives. Programs would be initiated to close strategic or performance gaps instead of apparent functional deficiencies. Each program would have a set of desired value outcomes. At the end of the program, the value outcomes would be authenticated against the projected outcomes. Accountability would remain during the entire lifecycle, as shown in Exhibit 1.

Exhibit 1 - Accountability in Lifecycle

Today’s project management office (PMO) focuses largely on conformance, on standardizing the work approach. The focus of a strategy driven PMO would be different. Its focus would be on ensuring that programs and projects were based on the delivery of value outcomes. Its primary role would be to properly identify potential benefits and authenticate them to ensure that we maintain a business focus rather than a technical focus. The program becomes the value wrapper for projects.

In general, PMOs have focused their attention on getting project managers to adhere to standards and to meet certain levels of competence. This is a quality assurance and policing role. Although this may be necessary, it is not sufficient. PMOs can have a much greater impact if they also devote time and attention to program design. The key goal of program design is:

An enhanced role for the PMO can be to ensure that when a project is officially launched and handed over to a project manager, the project begins under optimal conditions, not challenging conditions. No project should ever be launched with controllable conditions at anything other than optimal.

The Structure of a Program

It has been said that the Roman Colisseum could not have been built without the development of the arch. The arch is considered an almost perfect design for bearing heavy loads. Exhibit 2 depicts the “Program Arch” for producing greatly increased value.

Exhibit 2 – Program Arch

The arch consists of the following:

1. Two Value Pillars

   a. Left Pillar: Desired outcomes—this is a specification of the measurable outcomes that the program is intends to deliver.

   b. Right Pillar: The actual value outcomes realized as a result of the program.

2. Functional Cost Wedges

   a. Program Design: It is here that we define what projects are required and what the optimal conditions are. It is also here that we ensure that the conditions are actually optimal before projects begin.

   b. Projects Delivery: This is the normal project delivery cycle.

   c. Outcomes Authentication: Once the project deliverables have been implemented, we authenticate how much of the projected benefits actually get realized. This can take months or years to complete.

3. Net Value Foundation: The net value represents the difference between the realized benefit outcomes and the cost. If this is positive, then this was a contributing program. If it was negative, then the program reduced enterprise value.

Today, many organizations evaluate project success based on budget, scope, and schedule. Few evaluate program success, which is equivalent to business success. Of course, the latter is more important. It should be the latter that drives change, not the former. The lesson here is that every project, no matter how small, should be delivered inside a program wrapper.

The primary goal of a PMO should be to manage the program for business success. In fact, every program should have a program profit and loss statement. In addition, there should be a running program balance sheet that shows the retained benefits over all projects. Only in this way can we truly demonstrate that “project management is indispensable for business results.”

Every program should have three stages (as depicted in the arch diagram):

1. Stage 1: Program Design
2. Stage 2: Projects Delivery
3. Stage 3: Benefits Delivery and Outcome Authentication

It is the goal of program design to ensure that projects are setup for success. Many projects fail not because they were poorly managed per se, they were destined to fail based on poor initial conditions. Lack of management support, insufficient user involvement, ever-expanding scope, poor resourcing, and other top project failures are sometimes due to poor project execution. More often they are due to poor program design and challenging initial conditions. Many of these failures can be avoided through Program Design.

The Steps of Program Design

So what are the outputs of Program Design? Exhibit 3 depicts the five major steps/outputs of Program Design, followed by a brief description of each.

Exhibit 3 – Steps for Program Design

Step 1: Outcome Definition: Projects and programs require investment. And investments require a return. Therefore, the first step is to determine what outcomes the business needs to achieve. Then the outcomes need to be quantified. Only if they are quantified can we later evaluate alternative solutions. How many times have projects been undertaken without having true business outcomes?

Step 2: Business Processes: Organizations deliver value through the execution of business processes. Having defined and quantified the outcomes, we need to identify which business processes need to be changed to achieve them, and which need to remain the same.

Step 3: Capabilities Impacted: It is not enough to say that a process needs to change. We need to define what capabilities must be changed and how they should be changed. For example, we may need to change the capacity of a process, or its responsiveness (start to finish time), or its ability to accept change (flexibility), or the emotional mindset of the people. If we do not specify which capabilities must be changed, we have no way to validate potential solutions.

Step 4: Accountability Structure: Accountability is the fuel that drives organizations and business processes. Accountability is the ability to account for a result. We need to define all the accountabilities required and relate them to both the outcomes and the capabilities. Then we need to assign each accountability to actual people. And each person needs to have a stake in achieving each outcome. It’s not about managing stakeholders. It’s about creating a stake and then assigning a holder for that stake. It’s about designing the stakeholder structure.

Step 5: Solution Sets (Projects): In today’s environment, most outcomes require multiple solution sets to be achieved. Each individual solution is a necessary part of the total solution. To achieve the outcomes requires all the solution parts to be produced. Not achieving the outcomes only requires that we fail at one. So we can see that there is always a bias towards failure. At a simple level, each solution set could be considered a project.

For each step, we determine the conditions required and ensure that these conditions are optimized. Since none of the projects has started, program design becomes a PMO function. The PMO drives the design of programs for success. This is a more active and engaged role. The PMO also carries out the authentication following project delivery. That puts the PMO in an excellent position to learn from successes, near misses, and failures since they have sufficient span of vision to assess business success and requisite conditions.

Program Design Flows from Strategy

Outcome based Program Design is an approach that flows from strategy. Its starting point is radically different from most current approaches. Programs are not defined based on putting together related projects. Instead, a program is created to achieve specific outcomes. Projects are then identified and associated with each solution component. That way, we can ensure that projects are not initiated based on local preferences but rather based on strategic need. A program will consist of one or more projects—one for each solution set—and processes. At the least, each program will contain pre-activities to design the program at the front end, and post-activities to authenticate the outcomes at the back end.

These are the assumptions and conditions associated with this approach:

1. We must clearly define the outcomes and quantify them in business terms.
2. Significant and organization-wide effort are required to achieve the outcomes.
3. The program is defined first, then the required projects.
4. The program’s focus is to deliver to the outcomes.
5. Even a single project should have a program wrapper.
6. The business success of a project cannot be determined at the completion of the project. Therefore, it must be done as part of the program—going beyond the scope of vision of the project.

The pre- and post-processes are the two bookends. The pre-processes define the projected outcomes in measurable business terms. The post-processes authenticate the actual outcomes realized. Success can really only be measured in terms of extent of outcome achievement. These activities cannot be executed within a project, especially the authentication since it can take years to verify results. They really have to be done at a different level.

The program is a good place to put these activities and the PMO can be the unit that executes them in an objective manner. That way, we can ensure that there is a permanent record of every program, its intent, and the extent to which the outcomes were realized. We could say that each program needs to have a profit and loss statement. And we can have a balance sheet that shows the running result of all our programs, just as the enterprise does. That way we can always know how well our project efforts are paying off.

We first open a program and equate it with the desired outcomes. We may not yet know how many individual projects will be part of this program. The intent is to identify all the solution components first, then determine how many separate projects we need to deliver the total solution. This is radically different. Projects are not conceived at the functional level. Instead, projects are conceived to deliver each part of the total solution required to produce the outcomes.

At the program level, we should be managing something different from what is being managed at the project level. A program is not a form of higher-level quality assurance. It is a different thing. At the program level, we are managing to the outcomes. We are managing the accountability required to achieve them. At the program level, we are continuously re-evaluating the outcomes and re-estimating the quantification of the benefits. A change in the benefit outlook is just as important, often more important, than a change in the cost or schedule for a particular project. A scope change should be evaluated first at the program level. Will the scope change affect any of the outcomes? Will the benefit be larger or more certain? If not, then why are we entertaining the change? If yes, then what is the impact and is it worth the additional costs? These are all business questions. These are all program level questions.

Conclusion

The program should be the base structure in project management. Every project should be delivered inside a program wrapper. Because the focus of a program is on enterprise value, it is the proper center for achieving business success.

It is time to focus on delivering measured and realized enterprise value. Because value is realized after a project has completed, it cannot be authenticated during the project lifecycle. If it cannot be authenticated, then that means that we do not have a feedback loop to drive improvement and learning. A focus on programs as the center of attention can change that.

Program design includes accountability design. Accountability is the art, practice, and science of building stake. It is during program design that we build the stakeholder accountability. Without designed, assigned, and accepted accountability, no program should proceed. This means that unless accountability is fully defined, assigned to specific people, and accepted by them, it would be a risk to go forward. I think that this alone could increase project success rates significantly

Program Design and Authentication adds the necessary feedback loop necessary if we are to make project management indispensable to business results.

Program Design is about changing the initial conditions in order to improve outcomes. Every organization should consider the benefits of adding Program Design and Outcome Authentication to their PMO function, to truly become value centered.