The Triple Constraint In Waterfall & Agile

This post was originally created as an internal tool for the staff at Ventive. It is used here with permission.

The Triple Constraint

There are three axis’ of any project that are naturally bound to one another regardless of project management technique.  These three axis’ are the project’s scope (the list of requirements to be accomplished), schedule (the time frame to finish the project), and budget (the available funds to complete the project).   An increase to the project’s scope can’t be done without proportional increases in the project’s timeline and budget.  Similarly, a client who reduces their requir

ements will enable the reduction of the project’s spending and the project’s schedule.  The same interconnection holds no matter which area is first impacted.  A client may have greater sensitivities to time (I want it faster) or funds (it needs to cost less) than scope.

These three axis’ are known in the PM literature as the triple constraint or the iron triangle.  Communicating internally and externally using the triple constraint is a standard technique for a project manager.  In general clients may not be aware that they exist or how they interact.  If the client is unaware of these constraints, it is the PM’s responsibility to teach this reality to the client and continuously refer to this throughout the project’s life cycle.


PM Techniques:

The two most popular project management techniques are Waterfall and Agile.  Each technique has strengths and weaknesses and rather loud proponents on each side of the discussion.  Ventive uses a hybrid approach to Project Management that has both agile and predictive components.  This hybrid approach has roots in Interative and Incremental Development (IID), which dates back to NASA’s Mercury program.  Our hybrid approach allows us to efficiently deliver quality to our clients while creating an environment that improves the stakeholder experience.

Many of our clients are familiar with some of the terminology in Waterfall and some of the terminology in Agile and its important for you to understand these terms and their functions.


Waterfall is the most prominent technique in project management in practice and in the literature.  The technique is built off the premise that all of a project’s requirements are known at the beginning of a project.  In addition, all of the work necessary to create the deliverable must be known.  Not only does this work have to be known, but the way that each task and each resource interacts with one another also must be known.  This creates a huge requirement for the discovery phase of a project.  Not only would a Project Manager (PM) need to know all of the requirements, but they must also know how all of those requirements interact with one another.  

We know the least amount about our projects at their beginning.


Another limitation of the waterfall process is the methods for client interaction.  In waterfall the client is involved in the initial phase of determining requirements, but is then removed from the process until the final verification.  If a client misses identifying a requirement early on that requirement can still get integrated, but the changes are managed through a process that is often built to be difficult and more costly for the customer.  Between the exclusion of client input and the cost associated with their delayed input, Waterfall can be an expensive and frustrating process for a client.

Waterfall is best used in projects with high certainty and low complexity.  Construction projects still rely heavily on Waterfall regardless of their complexity which often explains why many projects will deliver behind schedule and over budget.  Several tools have been developed to reduce the uncertainties associated with this model of development.  Some of the techniques and tools for project management developed for waterfall have applications in Agile and IID.

Tools such as Work Breakdown Structure (WBS), Gantt Charts, Pert Diagrams, Critical Path, and Critical Chain are predominantly found in waterfall project management.  Some clients will have familiarity with these topics.  It’s not uncommon for a client to request products associated with these topics during the project’s life cycle.  Many of these products give a false sense of understanding a project’s progress.  While they are often highly detailed products, they are just as often wrong.


Waterfall projects start with a description of a project’s scope and then go through a phase to discover the acceptable budget and schedule in order to deliver that scope.  This effort requires inquiries along two different axis.  This means there are more unknowns than knowns in the project.  Typically the PM works with the client along the axis towards schedule and cost.  While all three are interrelated there is no set formula.  By pursuing two directions at the same time the team (PM & client) will inherently miss things.  In destructive settings the PM and client will both blame one another for missing important information along these axis.  The reality is that the people aren’t to blame, the procedure has inherent flaws.  

Waterfall does not always lead to destructive conflict.  It only results in destructive conflict if both parties fail to recognize the limitations of the method.  If these limitations are acknowledged early on and mitigated waterfall can provide a fast, predictable, and positive experience for the client and the PM.


Agile is arguably the second most popular technique for project management, however instead of focusing on projects it actually focuses on products.  And instead of it being a technique it’s actually a series of principles.  Confusing?  Because it’s thought of as a specific project management technique and it’s not a great deal of those who’ve heard of agile have difficulty understanding what it is and what it isn’t.

Agile’s story in part begins back in February of 2001 when seventeen people gathered in Snowbird Utah to try and develop a consensus based upon their successes in software development techniques.  The consensus over techniques were never reached.  Instead they shared techniques and realized that they shared 12 principles.  The 12 principles of agile are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Several methodologies have emerged to support these twelve principles and provide a framework to development teams.  Agile has become an umbrella for several disciplines of product development.  Two of these most popular methods are Scrum and Extreme Programming.  image1

Scrum’s framework contains rigid rules for roles and responsibilities designed to maximize the productive output of each person in the process.  The rules for other techniques are similar, but less rigid in the other techniques.Several methodologies have emerged to support these twelve principles and provide a framework to development teams.  Agile has become an umbrella for several disciplines of product development.  Two of these most popular methods are Scrum and Extreme Programming.  

Scrum captures the product requirements and stores these in a backlog.  During sprint planning the backlog is sized for complexity and business value (priority).  The product owner (client) and the development team determine which backlog items get added to the sprint.  Sprints are specific time frames of development (usually 2-4 weeks).  Each day during the sprint the team conducts a daily scrum meeting.  At the end of the sprint the team reviews their progress, shows the client the working product, and reviews what went well or what they need to improve on for the next sprint.  Then the cycle repeats.

Scrum clearly includes more customer interaction than waterfall, but doesn’t create the cohesive narrative that waterfall offers the client.  The logical process takes faith to see through the staccato development process.

Agile’s impact on a project’s scope, schedule, and budget are significant.  They essentially flip the triangle on its head.  Because the agile team is set from the beginning at a predictable rate the project’s cost becomes fixed per cycle.  The schedule is also predetermined and fixed at the start since the client and the development team agree to the length of time of each development cycle.

image7In this technique the client has to be comfortable with an unpredictable scope evolving to meet their needs over time while structuring fixed payments each cycle regardless of progress.  Despite Agile’s proven track record of effectiveness over several decades, the technique is still uncomfortable to many clients as it shifts the burden of uncertainty to the client.

Hybrid Approaches

image10The hybrid approaches fall somewhere on the spectrum of predictive (waterfall) and agile.  The two options to use when referring to these hybrid models are to give top billing to the primary technique.  It’s common to hear PMs refer to their techniques as Agile with Predictive components or Predictive with Agile components.  These hybrid labels allow the client and PM to speak a common language with a great deal of flexibility in between.

While there is a spectrum of projects that are best done using purely agile techniques not every client can adjust to a completely agile project environment.  The hybrid approach allows the inclusion of the most effective techniques for the situation and the company’s culture.  Each PM needs to be able to pull in the correct processes for Predictive and Agile management to facilitate the client’s needs.

One way to view these systems are to recognize what each brings.  Agile project management explores avenues of value with the client.  Predictive models are prescriptive in nature and generally fixed.  Let’s say Aesir Industries contracts us to develop a website to manage a financial database including customer and account information.  Prior to going live the software must go through a technical audit.  In this case the software will likely be developed using agile components where the client is reviewing the backlog and updating the course of the project over time.  The remaining work with the audit will be fixed and follow a specific predictable formula.  This means the project will transition from an agile framework to a predictive one.  Overall the project will be agile with predictive components.