The Triple Constraint Flipped

Share with othersProject management theory identified the Triple Constraint (aka the Iron Triangle) to be the key to project success. Once the scope has been established and fixed, the schedule and cost must be adjusted to accommodate any changes.
This proposition is simple and appealing. All requirements are documented and approved at the beginning of the project. This is not true for small projects. It applies to all other projects and pits project managers against stakeholders when things change.
This is a simple task, but it requires a shift of perspective. This problem can be solved by adopting a variable scope mindset. It accepts that scope is not fixed or monolithic. It reduces friction between customers, delivery teams, and it also helps to reduce customer frustration. It also opens up opportunities to improve project outcomes.
The Triple Constraint: Unpacking
The engineering principles that were used to develop large Federal programs are the foundation of project management concepts. PERT and critical path were created to aid the Manhattan Project and Navy’s Polaris submarine program in the 1940s, 1950s. These tools simplify complex relationships into simple mathematical formulas.
The scope of the project and the amount of effort required to build it (time) determines how much it will cost.
Cost = function (Scope, Time).
The Triple Constraint is created by transposing the formula to solve scope. Any change in scope must be accompanied with a change in cost, time or both.
Scope Fixed= function (Cost, Time) Variable
This seems to be a reasonable assertion. But is this realistic? Does it describe actual project dynamics? Is it able to predict the outcome of projects?
The Project Management Institute’s Pulse Of the Profession(r), a survey, collects data about project outcomes. About half of all projects are completed within budget and on time. About a third of all projects are subject to scope creep (unanticipated changes in scope). This means that despite 70 years of effort, we still struggle with this problem.
Data also shows an increase in the number projects that achieve their business goals. This has increased from 64% to 75% in the past decade. This is due to the rise in Agile projects which now account for half all projects. The Standish Group data also shows that Agile projects are more successful then traditional ones.
Realities of Project Scope
The scope of a project is not singular. It is the summation of hundreds or even thousands of individual components. Both traditional and agile methodologies break down project scope into smaller, more manageable items. The results are the same, even though the frameworks use different tools.
The work breakdown structure (WBS), is a hierarchical breakdown for the scope of traditional projects. Work packages are the lowest items in the hierarchy. They are small enough that it is easy to estimate the time and cost required to create the deliverable.
Agile projects use the product backlog for documentation (scope). The work is broken down into three levels of epics, features and stories. Stories are smaller than work packages and can be completed in a few days.
A colleague once said that “if you have a good WBS, then you will have a successful project.” It seems like this advice is a given. Data supports the idea that project success is dependent on having good requirements. Poor requirements can lead to failure.
Scope can be defined upfront for small projects. This can be difficult and time-consuming for large, complex projects. As new information and knowledge is discovered, so should scope and design.
Scope items can be classified as fixed, variable, unknown, or unknown. Clear and well-defined scope items are fixed. Variable items can be understood but not specified. Unknown scope items may be discovered