Triple Constraints – When nothing can give, what does?

Triple Constraints
The Triple Constraints or “Iron Triangle”

In project management, people often talk about the triple constraints, or the “Iron Triangle”.  It describes the concept that when a project encounters obstacles there are a limited number of things that can be adjusted; the schedule can be slipped, the scope can be decreased or money can be spent to purchase additional resources or tooling.  There aren’t a lot of options outside those three, but sometimes a project sponsor is unwilling to bend any of the edges of the triangle.  What happens then?

People who have been involved in more than a few projects understand that unforeseen  things will happen.  When a project sponsor is unwilling to be flexible on schedule, scope or cost the team often goes into hero mode in order to bring the project back on track.  The unfortunate truth is that this rarely works.  As people start putting in longer hours they get tired and start making mistakes.  This typically has the effect of putting the project even further behind.

In reality, when we’re not willing to bend one of the three sides of the iron triangle, we are actually bending the hidden fourth edge: quality.  People will start advocating decisions to cut corners.  Testing often gets thrown out the window in the interest of saving time.  In the end, quality suffers, and in many cases the project misses its schedule, scope or cost goals anyway.

My recommendation for every project you work on is to have the project sponsor decide which of the constraints they are willing to let bend when difficulties arise.  I also recommend that instead of including just schedule, scope and cost in the  list of options, that quality is also one of the choices.  Most people are not willing to sign their name to slipping quality when the project starts failing.  Furthermore, explicitly listing it as an option will drive home the reality that that’s what will suffer if one of the other options isn’t chosen.

In the next few posts, I’ll talk about different techniques that can be used to plan Scrum projects once we’ve chosen which edge of the triangle we’re willing to flex.

Playing around with SpecFlow

I’m starting to do some tinkering with SpecFlow. I’m pretty excited to learn the tool so I can start adding ATDD style testing to my solutions. I’ll follow up with my progress.

UPDATE:  So far, so good.  I got the necessary packages added to my solution and got a couple SpecFlow features up and running.  Watched about 30 minutes of a Pluralsight video and was up and running.  I wouldn’t say I’m ready to do anything super fancy, but in that time, I was able to learn how to set up some basic parameterized tests using the framework.  And it was easy.  I like easy.  I’ll post up some examples in a bit.