This is not an article about the “Iron Triangle.” Rather it is an article about its contemporary replacement - the "ECPM Framework Scope Triangle." This Scope Triangle offers a systems view of complex projects and their effective management. As such it provides the ECPM Framework with a tool to support problem-solving, change management and business decision-making. That same tool can be applied to the PRINCE2 Framework with equal impact.
To begin our discussion know that there is a significant difference between the project variables defined in PRINCE2 (Costs, Timescales, Quality, Scope, Risk and Benefits) and those defined in the ECPM Framework (Cost, Schedule, Resource Availability, Quality, Scope and Risk).
Note that PRINCE2 includes Benefits and the ECPM Framework does not. Benefits are defined within the business value that is generated from the project deliverables and in the Business Case that justified the project.
The biggest and perhaps most important variable is Resource Availability. It is clearly identified as a project, program and portfolio constraint in the ECPM Framework but is absent from the PRINCE2 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 - DEFINING VARIABLES
The ECPM Framework includes the Iron Triangle (Cost, Schedule, Scope define the three sides of the Iron Triangle) but it is much more than that. It is a system defined by the 6 variables shown below
Risk overshadows the other 5 variables in the ECPM Framework Scope Triangle. It can impact any of the other 5 variables. In the complex project landscape, risk is so impactful and potentially damaging that one of the team members should be given responsibility for risk management. Assigning that responsibility is essential to effective complex project management. The responsibility spans the entire project life cycle and therefore the risk management life cycle from Identification to Assessment to Mitigation to Monitoring. A risk management plan is developed with the collaboration of the project team. Recall that the project team includes decision-making responsibilities of the client and so risk management decisions are also client decisions. Risk is continuously monitored and reported upon at each project status meeting.
The project deliverables and the process that produced them will have been defined as part of project requirements elicitation. There is also an implied "fitness for use" against which the process and the product are measured.
The following two types of quality are part of every project:
- Product quality: As used here “product” includes tangible artifacts like hardware and software solutions as well as business processes. The traditional tools of quality assurance and quality control are used to ensure product quality. In a complex project situation product quality is an evolving quality. Incremental solution development must include a continuous review of the convergence of product quality as measured against product performance requirements.
- Process quality: Process quality is the enabler of product quality and for that reason it should continuously reflect a best effort. The focus is on how well the project management process works for this project; how it can be improved for this project, and how it can be improved for future projects. A continuous process improvement program for complex project management must be in place.
A sound quality management program with processes in place that monitor the work in a project is a good investment. Not only does it contribute to client satisfaction, but it helps organizations use their resources more effectively and efficiently by reducing waste and revisions. Quality management is one area that should not be compromised. The payoff is a higher probability of successfully completing the project and satisfying the client.
Simply put, scope defines what is in the project and what is not in the project. Much of this can be described through a necessary and sufficient set of project requirements.
Scope is a statement that defines the boundaries of the project. It tells not only what will be done, but also what will not be done. In the information systems industry, scope is often referred to as a functional specification. In the engineering profession, it is generally called a Statement of Work (SOW). More generally it has been called Project Overview Statement (POS), Project Initiation Document (PID), Document of Understanding (DOU), Scoping Statement, Project Charter, or Project Request are also in common use. PRINCE2 projects begin with a Project Mandate. Project Mandate precedes the PID which is also part of the PRINCE2 Framework. The POS is part of the ECPM Framework Ideation Phase. It is quite similar to the PID but there are some distinct differences too.
Whatever its name, this document is the foundation for all project work to follow. It should be the primary input for all project performance reviews, status meetings, change request approvals and problem resolution. For that reason, it is critical that the scope be correct and be up to date. Beginning a project on the right foot is important, and so is staying on the right foot. It is no secret that a project's scope can change. In the complex project world, you do not know how or when, but scope will change. Detecting that change and deciding how to accommodate it in the project plan are major challenges for the complex project manager.
The dollar cost of doing the project is another variable that defines and constrains the project. This includes not only the development costs but also the ongoing maintenance costs of the deliverables. Total cost is a variable often used in project prioritization processes. Cost is best thought of as the budget that has been established for the project. This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.
Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project. The client can simply offer a figure about equal to what he or she had in mind for the project. Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project. Consultants often encounter situations in which the client is willing to spend only a certain amount for the work. In these situations, you do what you can with what you have. In more formal situations, the project manager prepares a proposal for the projected work. That proposal includes an estimate (perhaps even a quote) of the total cost of the project. Even if a preliminary figure has been supplied by the project manager, the proposal allows the client to base his or her go/no-go decision on better estimates.
The client specifies a time frame or deadline date within which the project must be completed. To a certain extent, cost and time are inversely related to one another. The time a project takes to be completed can be reduced, but costs will increase as a result. The schedule reflects not only the timeframe within which the project is executed but also the labor hours needed to produce the deliverables within that timeframe. That extends the reach of the schedule into the commitments made of resource utilization across that schedule. That is the root cause of most resource contention problems that arise during the ECPM Framework Project Execution Phase.
Time is an interesting resource. It can't be inventoried. It is consumed whether you use it or not. The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible. Future time (time that has not yet occurred) can be a resource to be traded within a project or across projects. Once a project has begun, the prime resource available to the project manager to keep the project on schedule or get it back on schedule is time. A good project manager realizes this and protects the future time resource jealously.
The resources are any finite consumables (people, rooms, computer time, equipment, etc.). In the short run there is only limited capacity of each resource. Some of it has already been allocated to other in-process projects as well as committed to future projects. Resource Availability deserves considerable discussion as it is a constraining variable that impacts all the other variables as well as active and to be approved projects. At the enterprise level, Resource Availability is the link to portfolio management in that the resources are finite, at least in the short run and are allocated across all approved projects by virtue of the strategic plan. So while there are constraints that operate on a single project (time, for example), Resource Availability is a constraint that is binding across the entire project portfolio. It is the ultimate enabler of the strategic plan! It is the binding constraint across all projects in the portfolio.
In many organizations, Resource Availability is not taken into account when projects are approved for execution. Resource Availability encompasses both skill availability and schedule availability.
- Skill availability means that the project portfolio should be balanced with respect to skill and competency requirements. If every project required only senior project managers, what do you do with the junior project managers? That further begs the question about proposed resource requirements for the project. Trade-offs and between project manager negotiations for skills and competencies of the team members are common.
- Schedule availability is a bit more forgiving in that schedules can be adjusted to remove resource conflicts. That requires attention to the critical path and slack management. Another tool that has helped is "Management Reserve." It will be discussed in a future article.
Not taking these two availabilities into account as part of project approval becomes a major obstacle to project completion because it leads to resource contention problems and scheduling conflicts during project execution. In other words, it throws the project system out of balance. Project Portfolio Management is out of scope for PRINCE2 at the project level and resource contention is not even considered as a factor in project approval. Even though the Project Board may have knowledge of available resources, these considerations do not appear explicitly in the PRINCE2 Framework. The situation is different at the Program and Portfolio levels. It is clear from the above discussion that a sound human resource management process is critical to project plan achievement. Unfortunately not too many organizations can boast of having such a process in place. Commercial products fall short of meeting the complex project management requirements.
Including resource management during ECPM project planning as a constraining variable is straightforward as long as the appropriate Resource Managers are invited to participate in the planning activities. They have command of the resource schedule and intimate knowledge of the availabilities and capacities of their resource inventory and can make informed decisions about resource availability for both current and future projects. It is not obvious that the PRINCE2 project team has those resource managers in attendance.
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 PRINCE2 is discussed in this article. The Iron Triangle, which is not discussed in PRINCE2 or the ECPM Framework, does not offer such a rich interpretation.
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 are 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 PRINCE2 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.
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 Figure 4.2, 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. Variables 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.
PUTTING IT TOGETHER
The ECPM Scope Triangle is now defined. It will have a number of applications to PRINCE2 as will be discussed in the second part of this article.