Viewing the PRINCE2 Project as a System in Balance: Decision-Making and Problem Solving

The ECPM Scope Triangle was introduced in Part 1. In Part 2 we are going to discuss applications of this valuable tool.

The biggest and perhaps most important among the six variables that define the ECPM Scope Triangle is Resource Availability. It is clearly identified as a project, program and portfolio constraint in the ECPM Framework but is absent from the P2 Framework at the project level. The program and portfolio level are out of scope here.

There are just a few graphics used in the ECPM Framework that should be burned into your project management brain. They are intuitive and powerful decision-making tools. The ECPM Framework Scope Triangle is one of those graphics.

THE ECPM FRAMEWORK SCOPE TRIANGLE – A SYSTEM IN BALANCE

On the first day of a project, the project system is in balance. No work has been done yet. Due to the dynamics of the situation, this balance may be short-lived. Something changes that was either expected or not expected even though its timing may be unknown. Literally every change has a domino effect on the other variables and causes a change in one or more of the 6 variables. In order to restore balance to the project, a change in one or more of the other variables will have to be made. In that sense, the ECPM Framework Scope Triangle is a management tool for problem resolution, schedule repair, and change management. This systems view of project management is a useful problem-solving tool and change management tool and is explored in detail in the ECPM Framework book (Wysocki, Robert K., 2014, Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing). Its adaptation to P2 is discussed in this article. The Iron Triangle, which is not discussed in P2 or the ECPM Framework, does not offer such a rich interpretation.

---

{module ad 300×100 Large mobile}

---

The 6 variables that define the ECPM Framework Scope Triangle form an interdependent set of variables that define the project as a system in balance. To understand this interpretation, visualize the triangle as a geometric figure that encompasses an area (the area occupied by the scope and quality) that is bounded by the three sides of the triangle. Those sides are just long enough to encompass that area. If one of the sides should shrink (budget is reduced, schedule shortened or a previously scheduled resource is no longer available), then the reduced length of the corresponding lines are no longer sufficient to encompass the area defined by the scope and quality. The interpretation and its explanatory figure is conceptual. Don’t try to draw the triangle. It can’t be done. A very common situation arises from scope change request that increase scope. Decreases are rare. In these cases, the area occupied by scope expands and the sides of the triangle are no longer sufficient to enclose the larger area. Something has to change. The length of one or more lines must be increased (increased time or cost and/or more staff assigned to the project), so that the larger scope can be bounded by the larger triangle.

I have had over 25 years of client experiences using the ECPM Framework Scope Triangle. It has been a valuable addition to my project management toolkit, and I can recommend it to you especially if you are a P2 Practitioner or Professional.

PRIORITIZING THE ECPM FRAMEWORK SCOPE TRIANGLE VARIABLES

Except for risk, the other 5 variables can be prioritized as an assist to problem-solving, change management, and other management decision-making. The figure below is an example of one such prioritization schema. It applies to only one project. Every project is different. The matrix shows that the time constraint is the least flexible, and the cost constraint is the most flexible. Also, note that scope is quite flexible as should be the case for any complex project.

Prioritized ECPM Framework Scope Triangle Variables

When alternatives solutions to a problem or change management approval arise, this matrix is easily applied to help prioritize and then make the best choice. For example, in the figure above, since cost is the most flexible, choices that impact cost would receive a higher likelihood of being implemented than those that involve time or resources. Prioritization should be done during project planning to remove any bias that might arise from the problem solving or change management events. That prioritization exercise must involve the client, too.

Problem Solving & the ECPM Framework Scope Triangle

here are a variety of problem-solving models that are in common use. The one that I am recommending is simple and can be used in a variety of contexts within the ECPM Framework. It was developed by J. Daniel Couger (1995, Creative Problem Solving and Opportunity Finding, Boyd & Fraser Publishing Company) and aligns quite well with the divergent/emergent/convergent process used in the Ideation Phase of the ECPM Framework. The Couger model follows the linear process:

• Step 1: Delineate opportunity and define problem
• Step 2: Compile relevant information
• Step 3: Generate ideas
• Step 4: Evaluate and prioritize ideas
• Step 5: Develop implementation plan

Something has happened that put the project plan at risk. Late shipments from suppliers, equipment malfunctions, sickness, random acts of nature, resignations, priority changes, errors, and a host of other factors can lead to problems that affect deliverables, deliverable schedules, and resource schedules. The project team owns the problem and must find a solution.

This situation is very different for the Project Manager in the case of a change request. When a change request has been made, the Project Manager has some leverage with the client. The client wants something and might be willing to negotiate an acceptable resolution. That is not the case when a problem arises on the project team. The Project Manager does not have any leverage and is in a much more difficult position.

When the unplanned happens, the Project Manager needs to determine who owns the problem and the extent of the problem, then take the appropriate corrective measures. Those measures often include helping the owner of the problem find an acceptable solution following the escalation hierarchy. Minor variations from the plan will occur and may not require corrective measures. There are degrees of corrective measures available to the Project Manager: In trying to resolve a problem, the Project Manager begins at the top of the escalation hierarchy and works down the hierarchy, examining each option until one is found that solves the problem.

The ECPM Framework Scope Triangle enables you to ask the question, ″Who owns what?″ The answer will give you an escalation pathway from project team to resource manager to client to sponsor. The client and senior management own time, budget, and resources. The project team owns how time, budget, and resources are used. Within the policies and practices of the enterprise, any of these may be moved within the project to resolve problems. In solving a problem, the Project Manager should try to find a solution within the constraints of how the time, budget, and resources are used. For these solutions, the Project Manager does not need to go outside of their sphere of control.

The next step in the escalation strategy would be for the Project Manager to appeal to the resource managers for problem resolution. The resource manager owns who gets assigned to a project as well as any changes to that assignment that may arise.

The final step in the problem escalation strategy is to appeal to the client and perhaps to the sponsor for additional resources. They control the amount of time and money that has been allocated to the project. Finally, they control the scope of the project. Whenever the Project Manager appeals to the client, it will be to get an increase in time or budget and some relief from the scope by way of scope reduction or scope release.

There are three levels of escalation strategy: project team–based, resource manager–based, and client-based.

Project Manager–Based Strategies

If the problem occurs within a non–critical path activity, it can be resolved by using available slack (Wysocki, Robert K., 2014, Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons). One example is to reschedule the activity later in its ES–LF window or extend the duration to use some of the available slack. Note that this strategy does not affect any other activities in the project. By using slack, you affect the resource schedule for all activities that have this activity as a predecessor.

Another approach is to continue the schedule compression techniques employed in defining the original project plan. This strategy can affect resource schedules just as in the prior case. The last option open to you is to consider the resource pool under your control as the Project Manager. Can some resources be reassigned from non–critical path activities to assist with the problem activity?

Resource Manager–Based Strategies

After you have exhausted all the options under your control as the Project Manager, it is time to turn to the resource managers for additional help. This help may take the form of additional resources or rescheduling of already committed resources. Expect to make a trade-off here. For example, you might be accommodated now, but at the sacrifice of later activities in the project. At least you have bought some time to resolve the downstream problem that will be created by solving this upstream problem. If you have other projects that you are currently managing, some trades across projects may solve the problem.

Client-Based Strategies

When all else fails, you will have to approach the client. The first option would be to consider any multiple-release strategies. Delivering some functionality ahead of schedule and the balance later than planned may be a good starting point. The last resort is to ask for an extension of time. This may not be as unpleasant as it seems because the client’s schedule may have also slipped and the client may be relieved to have a delay in your deliverable schedule, too.

The Escalation Strategy Hierarchy

The problem escalation strategy presented here is based on the premise that you, as the Project Manager, will try to solve the problem with the resources that you control. Failing to do that, you can appeal to your resource managers. As a last resort, you can appeal to the client.

One thing to note here that is very different from the change request situation discussed previously is the leverage to negotiate. As mentioned, you, as the project manager, have leverage when the client has requested a change, but no leverage when you have a project problem to solve. The client has nothing to gain and is, therefore, less likely to be cooperative. In most cases, the problem can be reduced to how to recover lost time. The following six outcomes are possible to this problem situation:

• No action required (schedule slack will correct the problem)—In this case, the slippage involved a non–critical path activity and it will self-correct.
• Examine FS dependencies for schedule compression opportunities—Recall that you originally compressed the schedule to accommodate the requested project completion date by changing FS dependencies to SS dependencies. You should use that same strategy again. The project schedule will have changed several times since work began, and there may be several new opportunities to accomplish further compression and solve the current problem.
• Reassign resources from non–critical-path activities to correct the slippage—Up to a point, you control the resources assigned to this project and others that you manage. You may be able to reassign resources from non–critical-path activities to the activities that have slipped. These non–critical-path activities may be in the same project in which the slippage occurred or they may be in another project that you manage.
• Negotiate additional resources—Having exhausted all of the resources that you control, you need to turn to the resource managers as the next strategy. To recoup the lost time, you need additional resources. These resources may come in the form of added staff or dollars to acquire contract help.
• Negotiate multiple release strategies—This strategy involves the client. Just as in the case of a change request, you can use a multiple-release strategy to your advantage. An example will illustrate the strategy: The project manager shares the problem with the client and then asks for the client to prioritize the features requested in the project plan. The project manager then offers to provide the highest-priority features ahead of their scheduled delivery date and the remaining priorities later than the scheduled delivery date. In other words, the project manager gains an extended delivery schedule but gives the client something better than the original bargain offered—namely, something ahead of schedule.
• Request a schedule extension from the client—This is the final alternative. Although it’s similar to the multiple-release strategy, it offers the client nothing in trade. The slippage is such that the only resolution is to ask for a time extension.

You, as the project manager, should try to solve the problem by starting at the top of this list of six outcomes and working down until a solution is found. By using this approach, you will first try to solve the problem with resources that you control, then with resources that the resource managers control, and finally with resources and constraints that the client controls.

Change Management & the ECPM Framework Scope Triangle

The ECPM Framework recommends a Bundled Change Management Process. Simply put, all decisions regarding proposed scope changes are held until the Client Checkpoint Step. This is different from the traditional approach. To handle change requests as they arise, as is done in the P2 Framework, is not a lean practice. During the Client Checkpoint Step, all proposed scope changes that have not yet been acted upon are considered together. These will include past requests that have not yet been processed as well as requests that arose during the just completed cycle. From among those change requests some will be approved and available for scheduling, others will be rejected, and others will be held for later decisions.

PUTTING IT TOGETHER

We have taken the static Iron Triangle and turned it into a dynamic tool – the ECPM Scope Triangle. All of this is possible because the ECPM Scope Triangle is really a conceptual depiction of a system in balance. It stresses the dependence of the 5 variables that define it.

As a system in balance, it is an aid to P2 LEAN Project Management as it supports problem solving, decision making and change management.