Project management theory established the Triple Constraint (aka, the Iron Triangle) as the key to project success. If the scope is known and fixed, then the schedule and cost must adjust to accommodate scope changes.
The simplicity of this proposition is appealing. At the beginning of the project, all requirements are documented, the design is approved, and nothing should change. Unfortunately, this only holds for very small or simple projects. For all others, it pits project managers against their stakeholders when things change.
Ending this struggle is simple but requires a shift in perspective. Adopting a variable-scope mindset resolves this problem. It accepts the reality that scope is neither monolithic nor fixed. It reduces the friction between customers and delivery teams. It also opens opportunities to improve project outcomes.
Unpacking the Triple Constraint
Foundational project management concepts are rooted in engineering principles developed for large Federal programs [1]. PERT and critical path were developed to assist the Manhattan Project and the Navy’s Polaris submarine program in the 1940s and 1950s. These tools simplified complex relationships into straightforward mathematical formulas.
Project cost is a function of what is being built (scope) and the effort required to build it (time):
Cost = function(Scope, Time)
Transposing the formula to solve for scope creates the Triple Constraint. A change in scope must be accompanied by a corresponding change in cost, time, or both.
Scope Fixed= function(Cost,Time) Variable
This appears to be a reasonable assertion. But is it realistic? Does it describe actual project dynamics? More importantly, has it improved the predictability of delivering projects?
The Project Management Institute’s Pulse of the Profession [2]® survey collects data on project outcomes. Historically, only about half of all projects are completed on time and within budget. Unanticipated changes in scope (scope creep) plague about one-third of all projects. In other words, despite 70-years of effort, we are still struggling with this problem.
The data also shows an improvement in the number of projects achieving their business goals, increasing from 64% to 75% over the past decade. This improvement correlates to the proliferation in Agile projects, which now account for half of all projects. Data from the Standish Group [3] also suggests that Agile projects are more successful than traditional ones.
Realities of Project Scope
Project scope is not monolithic. Rather, it is the aggregation of hundreds or thousands of individual components. Both agile and traditional methodologies decompose project scope into small, discrete items. Even though the frameworks use different tools, the results are similar.
The work breakdown structure (WBS) is a hierarchical breakdown of the scope used on traditional projects. Work packages are the items at the bottom of the hierarchy and are small enough to estimate the time and cost to create that deliverable.
Agile projects use the product backlog to document work (scope). Work is disaggregated into a 3-tier hierarchy of epics, features, and stories. Like work packages, stories are small and can be completed within a few days.
A colleague once said, “If you have a good WBS, you should have a successful project.” This advice seems axiomatic. Data [3] supports the premise that good requirements are vital to project’s success and poor requirements lead to failure.
On small and simple projects, scope can be defined up-front. However, on large and complex projects this is difficult and time consuming. On these projects, scope and design should evolve as new information and knowledge are revealed.
We can think of scope items as fixed, variable, or unknown: Fixed scope items are clear and well-defined. Variable items may be generally understood, but the details have not been specified. Unknown scope items will be discovered during the project. As projects progress, the number of variable and unknown items will decline as more is learned.
Office buildings need electricity (fixed). However, local utilities often provide design specifications after construction has started (variable). In addition, when the owners conduct a walkthrough, they may request that additional lighting be installed (unknown).
Technology projects fit a similar pattern. Foundational requirements are well understood and developed as part of the initial platform build (fixed). Planned user features are known, but the details may not be fully documented (variable). Previously unknown features are identified as feedback is generated.
Rolling wave planning and iterative delivery practices allow us to manage emergent scope. We can decompose scope to the appropriate level of detail as it is needed. This allows us to start building sooner, get better information, and reduce wasteful efforts.
Shifting to Variable-Scope Mindset
Creating a scope backlog sidesteps the challenges posed by the Triple Constraint. The backlog is a rank-ordered list of all work needed from the delivery team. Ordering compels stakeholders to make explicit trade-offs. This forces difficult decisions “to the left,” moving them earlier in the process; and putting the responsibility squarely on the customers.
The backlog is also emergent. New items can be added, unwanted ones deleted, and priorities can shift. This invites iterative planning, which reduces over-planning, unnecessary features, and wasted effort. It also eliminates the “if I don’t ask for it now, I will never get it” trap.
It is easy to estimate the delivery team’s capacity. Capacity is the amount of work a team can complete in a specified time. Over the short-run, capacity is relatively fixed. The overall project duration and budget are set externally by the sponsor. Resources are constant due to lags in finding and acquiring additional resources—people or machines.
With a prioritized backlog and a known capacity, project scope can be visualized by “drawing the line” of what can be accomplished. The level of effort for each scope item can be estimated. Negotiating scope is now fully within the customers’ control and is a matter of moving items above or below line.
Scope is now variable and team capacity and time are now fixed.
Scope Variable = function(Team Capacity, Time)Fixed
The dynamics of the triple constraint have now shifted to align with our project realities. Team capacity incorporates the budget constraints, resource acquisition limitations, and time are fixed. Scope is now emergent and variable. This increases flexibility, reduces wasteful effort, and makes customers, stakeholders, and team members happier.
In the long-run, scope, schedule, and cost may change. But we know what John Maynard Keynes said about the long-run.
© 2021, Alan Zucker; Project Management Essentials, LLC
See related articles:
· Successful Projects: What We Really Know About [3]
· Questioning Gravity: Is the Triple Constraint Really Relevant? [4]
· The Project Box—Evolving Beyond the Triple Constraint [5]
To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website: http://www.pmessentials.us/ [6].