The Project Box—Evolving Beyond the Triple Constraint

Traditionally, project managers are told to optimize scope subject to constraints on time, cost, and quality. This is embodied in the expression, “better, faster, cheaper—choose two.” The phrase has become a rhetorical distraction to effective project management. It presumes a magic bullet; if you can precisely balance the constraints you will be successful. In reality, the triple constraint poses a calculus problem that has no tangible solution.

The triple constraint is often depicted as a triangle with time, cost, and quality as the sides and scope in the middle. However, if you Google® “triple constraint,” you will see many variants on the triangle along with several other unexpected shapes.

Last month, I wrote “Questioning Gravity: Is the Triple Constraint Really Relevant?” Today, I introduce the Project Box, which is an improved construct for describing the interaction of time, cost, quality, and scope for many software projects.

The project box describes software projects that share the following characteristics:

Duration is short and constrained. The length of the project or the implementation date is preordained.

Scope is negotiable. Scope is time-boxed. It is either the minimum product that can be implemented in the time available, or it is defined as a set of releases that incrementally add functionality over time.

Quality is defined as “good enough.” Good enough software ships with an acceptable level of defects.

Labor is the primary cost driver.

The ability to effectively add additional resources is limited. Even if new resources were added to the project they would not be fully productive.

The project box simplifies the calculus of managing the project constraints:

Duration is set,

Scope is time-boxed and negotiable,

Quality is both time-boxed and imperfections are expected, and

Cost is proportional to duration.

Time is the primary constraint and project driver. Duration sets the cadence for all of the other dimensions—scope, quality, and cost. In the project box, duration or the implementation date is set outside the project by external factors such as set release cycles, product launch dates, regulatory compliance requirements, or executive mandate.

Scope is time-boxed and negotiable. In other words, scope is constrained by duration and must fit the box and what can be accomplished is negotiable. Accepting that scope is not set is the most significant change presented by the project box. Traditionally, scope is set and duration conforms to that fixed scope. With this new paradigm, the relationship is inverted—time is set and scope conforms to the time available.

In Agile terms, scope is defined as the minimum viable product, or the smallest function set that can be deployed and still accomplish the business objectives. Scope can also be defined as a series of incremental software releases that add additional functionality over time. For example, if you were building an online shopping site, the first release could provide consumers the ability to purchase products; later builds might add elements such as customer reviews and ratings.

Quality is defined as “good enough” which means the software has known defects, but it is fit to use. The good enough standard is broadly accepted by the software industry. A comprehensive study estimates that the number of delivered bugs ranges from 1.75 defects per function point for Waterfall to 0.72 for Scrum. The Microsoft® Windows 2000® operating system shipped with over 63,000 defects, yet it was still a major improvement over the prior version.

We can think of testing effectiveness as an inverted U-shaped curve. At a certain point, additional testing yields diminishing returns. In other words, beyond top of the curve additional cycles of testing and defect fixes no longer yield greater product performance.

Cost is the easiest dimension to manage because it is a function of duration. There is a near-proportional relationship between the duration and total project cost. Cost can be estimated as:

Total Cost = Daily Labor Costs * Number of Project Days

Two important assumptions allow us to simplify the cost dimension: First, labor is the primary resource. Second, additional resources cannot be effectively added to the current, in-flight project. This is a corollary to the lessons of “The Mythical Man Month”—adding manpower to a late project makes it later.

Resources can be added over the course of multiple project cycles. However, within a single project adding resources will have limited effectiveness due to learning curves and the team formation process.

Projects that reflect the realities of the project box abound. Some of the most prevalent examples come from mobile applications. Trip Advisor® updates its software every two weeks. Waze®, the popular navigation app, updated its software 11 times in the last 18 months with bug fix releases coming days apart. Apple has released 24 versions of iOS™ in the past seven years.

The project box represents a paradigm shift for managing software projects. It recognizes the primacy of time and reorients the other dimensions accordingly. To traditionalists, the project box provides a new worldview for managing time, scope, quality and cost. To Agilists, it provides a better representation of their principles and replaces the inverted triangle.

The project box liberates project management. The unachievable task of balancing the sides of the triple constraint is removed. The box shifts the focus to delivering “good enough” working software as quickly as possible.