Traditionally, project managers are told to optimize the project 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 challenging 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.
In this article, 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 timeboxed. 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 timeboxed and negotiable.
Quality is both timeboxed and imperfections are expected.
Cost is proportional to duration.
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.
In other words, scope is constrained by duration and must fit the box, and what can be accomplished is negotiable. Accepting that scope as 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 the 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.
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 more than 63,000 defects, yet it was still a major improvement over the previous 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.
There is a near-proportional relationship between the duration and total project cost. Cost can be estimated as:
Total Cost = Daily Labor Costs x Number of Project Days
Two important assumptions allow us to simplify the cost dimension: Labor is the primary resource and additional resources cannot be effectively added to the current, inflight 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. TripAdvisor 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.
Brooks, F. (n.d.) The Mythical Man-Month: Essays on Software Engineering (anniversary ed.).
Foley, Mary Jo. "Bugfest! Win2000 has 63,000 'defects.'" ZDNet. (n.d.), February 14, 2000. http://www.zdnet.com/article/bugfest-win2000-has-63000-defects/.
Jones, Capers. "Software Quality in 2012: A Survey of the State of the Art" (slide deck). May 1, 2012. http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf.
Waze App Version History and Changelog (n.d.), apk4fun.com, retrieved August 24, 2015. http://www.apk4fun.com/history/893/.
For more agile tips, go here.
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe