Questioning Gravity: Is the Triple Constraint Really Relevant?

Posted on Posted in Agile, Project Management

The “triple constraint” is to project management as Newton’s Laws are to physics.  “Better, faster, cheaper—choose two” is so ingrained in the canon that we don’t question its applicability. The phrase has become a rhetorical distraction to effective project management.

For many software projects, actively managing the triple constraint is not a relevant concern. This is not to say that time, cost and quality are not important. They are important project metrics. But, they are not inputs to a successful outcome.

Traditionally, project managers are taught to maximize scope subject to constraints on time, cost, and quality. The paradigm creates the expectation that we can mix precisely these priorities to yield a successful project. While the paint store can blend colors into a rainbow of discrete options; a project manager cannot similarly mix the variables precisely.

The triple constraint is an illustration of project management adopting engineering principles to model its eco-culture. Constrained optimization is found in engineering, manufacturing and economics and is an applied use of calculus. A familiar example is the farmer who seeks to maximize crop yield subject to limits on:

  • Land (how much land is available),
  • Labor (how many farmhands can be hired),
  • Capital (how much money is available for machinery, seed, and fertilizer)

For software projects that share the following characteristics, the triple constraint does not need to be actively managed. The characteristics are:

  • Duration is short and fixed. In other words, the implementation date is preordained.
  • Scope is negotiable. Scope is defined as a set of prioritized function points to be implemented incrementally 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. This is a corollary to the teachings from the Mythical Man Month, adding resources to a short project will not result in significant productivity gains.

Competitive industries have very short product lifecycles. Firms in these industries will launch new product offerings quickly to stay ahead of their rivals. When I worked in telecommunications, we typically launched new products every quarter with smaller changes implemented monthly. In this environment:

  • Project durations were short, typically no more than four months, and implementation dates were fixed in advance to match marketing plans that had little flexibility.
  • Labor was the primary project resource driver. New resources could be added over the course of multiple project cycles, but could not significantly contribute to the current project.
  • Quality was defined as ‘good enough’ to implement.  Order processing systems were critical to install new customers and network capabilities were critical to customer satisfaction. Downstream systems like billing and revenue reporting would often implement with known, non-critical defects.

Technology companies provide prime examples of competitive firms do not appear to be bound to the triple constraint. Apple has released 24 versions of iOS in the past 7 years. Waze, the mobile traffic and navigation app, released 11 updates in the last 18 months with bug fixes coming just a few days apart.

What are the implications of managing a project where the triple constraint is not relevant?

The project team no longer needs to worry about juggling the time, cost, and quality triangle. Rather, the focus shifts to the product being developed. Successful project teams are adept at quickly delivering software that meets the immediate needs and enhances its functionality over time. In other words, these projects conform to the principles in the Agile Manifesto.

The Agile movement and the Scrum methodology have incorporated this paradigm shift into their framework:

  • Scrum teams have a fixed number of members.
  • The product owner defines the minimum viable product that is developed over a series of sprints.
  • The overall duration of the project is fixed with working software being developed and implemented in each sprint.

Released from the gravitational pull of the triple constraint, project managers and project teams can focus their energies on the primary goal of software development—delivering working product.

Next month, I will introduce an alternative paradigm for thinking about scope, time, cost, and quality.

© 2015, Project Management Essentials, LLC

Sources:

APK4Fun – Download APK for Fun Android Apps & Games. (n.d.). Retrieved September 13, 2015, from http://www.apk4fun.com

Bach, J. (1995). The Challenge of “Good Enough” Software. American Programmer. http://www.satisfice.com/articles/gooden2.pdf

Brooks, F. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.

IOS Version History Chart. (n.d.). Retrieved September 13, 2015, from http://www.thinkybits.com/blog/iOS-versions/

“The Agile Manifesto.” Wikipedia. Wikimedia Foundation, n.d. Web. 27 May 2015. http://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto

Leave a Reply

Your email address will not be published. Required fields are marked *