4.1. triple constraints (time, scope, cost)

Arch. Dania Abdel-Aziz
Triple constraints
(time, scope, cost)
3/13/2018 1Arch. Dania Abdel-Aziz/ Lecture 4.1
University of Jordan Year
2017/2018
Second Summer Semester

Contents
3/13/2018 Arch. Dania Abdel-Aziz/ Lecture 4.1 2
Introducing Constraints Techniques
• Triple constraints
• Success Sliders
• Project Constraints
• What Do You Mean, “All Scope”?
• This is More That Just Mechanics

The concept of Triple constraints is simple and quite effective.
• On any given project, there are fundamentally three constraints,
1. The amount of work you’re going to deliver.
2. The amount of money you’re willing to spend.
3. How long the project can run.
Triple constraints
(time, scope, cost)

Project cost: the amount the customer has agreed to pay for acceptable
project deliverables.
• The project cost is based on a budget that includes an estimate of the cost
associated with the various resources that will be used to accomplish the
project.
Project schedule (TIME): time table that specific when each activity should be
start and finish.
As the name implies, these are constraints imposed upon a project, “you
must finish by 12/31/17” that will be used to determine if a project was
successful or not.
Triple constraints
(time, scope, cost)

Triple constraints
(time, scope, cost)
Project scope (/Quality): is the scope of a project/ all work must be done to
satisfy the customer that the deliverables meet the requirements or
acceptance criteria agreed upon at the onset of the project.
• The scope itself is generally identified up front so as to give the project the
best chance of success.
• Although scope can potentially change during the project life-cycle, a
concept known as ‘scope creep’
Note that the common success measure for the scope aspect of a project is
its inherent quality upon delivery.

As the triangle image demonstrates, you can constrain on up to two
dimensions, but not all three.
Triple constraints
(time, scope, cost)
Thus, you could engage with a project sponsor in an earnest discussion about
where you would put the prioritizing focus for a given project.

Three common cases:
1. Single Constraint.
2. Double Constraint.
3. The cop out.
Triple constraints
(time, scope, cost)

Single Constraint:
• The first example is a pretty straight forward single constraint where the
delivery of a set number of features is most important, while schedule &
budget being less important.
Example;
• Hospital project (health care facility).
• Hotel project (luxury).
• would be Blizzard entertainment, who explicitly
refuses to announce release dates in advance for
their games, rather insisting they build them
properly.
Triple constraints
(time, scope, cost)
“done when it’s done“.

Double Constraint:
• In this case, we are prioritizing one of the two constraints over the other.
Example:
• Stadium for Olympics.
• Festival at the roman theatre.
• A colleague working with an entertainment
company. He had a specific team (fixed budget)
and was building a new application for an
upcoming sporting event. Thus, if they didn’t
release by a given date, the application was
worthless. In this case, the scope of what they
release was actually the least important thing.
Triple constraints
(time, scope, cost)

The cop out:
• In this case, the sponsor basically puts the focus exactly in the middle,
saying that everything is important.
• One of the failure models for this approach.
As you can imagine, this does not set up a
project for success, as we have no
flexibility along any dimensions.
Triple constraints
(time, scope, cost)
Cop out : An excuse designed to shirk responsibility. Placing
blame on something else to make things easier for yourself.

SUCCESS SLIDERS

Success Sliders
Success Sliders ”exploring more than just three dimensions when considering
the success of a project”.
It was introduced by Rob Thomsett.
• This technique offer the ability to break apart that ambiguous concept
called “scope”, or prioritize other dimensions like quality and team
experience.
Indeed, you can use this type of model to prioritize along a virtually infinite
number of criteria.

Success Sliders
There are two common implementations of this technique:
1. Force ranking.
2. Single prioritization.

1. Force ranking.
• In this example, a number of stakeholders
each individually had to force rank the
priority of a number of different criteria
such as:
• “Stability”,
• “Adaptability of system”,
• “High Quality”,
• “Deliver Project on Time”.
• Each individual stakeholder’s values are
represented with a different colour.
The precise list may vary from project to
project.
Success Sliders

• This example shows how different
stakeholders show their perspective of
priorities so that discrepancies can be
discussed and reconciled before a
project falls into duress.
Success Sliders

2. Single prioritization.
The ultimate goal is a single prioritization.
This example is different in two counts.
• First, it represents a single set of agreed upon values.
• Second, it is not force ranked, but rather a budget.
Success Sliders

• You can only increase the priority of one
dimension by lowering the priority of
another.
• This sort of tool, especially when used
with a number of stakeholders, can be an
excellent way to work through different
expectations and amongst different
stakeholders.
However, this technique also introduces
some limitations.
• It can’t quite distinguish what the
absolute criteria is.
• We can focus on dimensions, but are the
top 3 deal breakers? What about the top
4? There still is some ambiguity we need
to cut through.
Success Sliders
This is a screen shot from a tool made available by
Mike Cohn on his website.

3. PROJECT CONSTRAINTS

3. Project Constraints
Jim Highsmith proposed the use of identifying project constraints to as a way
of reinventing the triple constraint.
His argument is that those dimensions can be prioritized into:
1. “Fixed”.
2. “Flexible”.
3. “Accept”.
but those can additionally be illustrated with threshold criteria.

Example:
• The primary constraint is schedule, the application must launch by 3/1/11.
• The flexible constraint is budget.

Example:
• In this case there is an existing team, so while there is a little bit of
flexibility with the budget, this dimension shouldn’t move too much.
• The final constraint is that they can generally accept an application that
can provide scores and game highlights.
• Thus we see the project team must deliver the application by the specified
date while adhering to the general burn rate it currently has in order to
opportunistically deliver whatever functionality it can within those
constraints.

The concept of a fixed constraint compared to a flexible constraint can be
applied to the broader set of criteria.
Example:

“ALL SCOPE”

What Do You Mean, “All Scope”?
Regardless of which of these more detailed techniques you may use, clearly
breaking apart the “scope” dimension is critical.
• Many projects blindly say something like, “our new system should deliver
all the scope of the old system”, without really doing any analysis of
exactly what that is.
• Indeed, finding that the question of scope can usually be broken into
smaller pieces:
1. Break by users.
2. Break by business objectives.

1. Break by users:
Some projects have a wide array of user.
Ex, applications in general is used by different user times or clients who use
an application differently.
In this case, you may want to identify different dimensions to prioritize.
Example:
you could take an online book store and break it apart by the different roles
and say something like the functionality for an online book shopper is the
highest priority, as they are the ones actually buying the books. Support
for wholesalers providing the books and your administrative support staff
may be lower priorities for your first release.

2. Break by business objectives:
Many projects have hard interdependencies or down stream processes that
require time in order to deliver their own functionality.
Example:
hypothetical project book store project.

THIS IS MORE THAT JUST MECHANICS

This is More That Just Mechanics
While these exercises might seem pretty straightforward and simple,
sometimes they can be quite contentious.
There are some anti-patterns when trying to use these types of techniques:
“We already know what the priority is” – frequently a project manager or
sponsor may state quite simply that this level of detail is not important,
because they already agree on it.
In these cases, sometimes the easiest thing is to ask them simply to write it
down and compare it to what some other major stakeholders think.
Frequently, this will reveal enough inconsistency that they realize they need
to entertain a more detailed discussion about criteria

“But I’m the sponsor, Isn’t this simply my decision?” – sometimes project
sponsors may feel offended that you are trying to democratize what they
see as their decision to make. It’s very important to be clear about the
point of this type of exercise and how you will use it to make decisions.
• Chances are, a project sponsor funding the project will ultimately make
the prioritization decisions and define the final criteria.
• Use success sliders or constraints to surface the expectations and
perspectives of other stakeholders so that the sponsor can make the best
informed decision.
• There’s a chance they may know something the sponsor doesn’t and the
discussion will help lead the group to a better decision.

“This is ALL important” –
• Some groups of stakeholders may be unable to parse more detailed
criteria. Rather, they may have a very hard time saying precisely what is or
isn’t critical for success.
• This is usually where a force ranking, can be most valuable.
• Before even engaging in a discussion about which dimensions are truly
must have, or even the precise dimensions, stakeholders must simply
prioritize in a force ranked order.

Thank you 

4.1. triple constraints (time, scope, cost)

More Related Content

What's hot

Similar to 4.1. triple constraints (time, scope, cost)

More from Dania Abdel-aziz

Recently uploaded

4.1. triple constraints (time, scope, cost)