The reverse triple constraint of projects in trouble

Assuming you suspect or know that one of your projects is in trouble the first step is always an extensive project review. After such a review you hopefully have the necessary information for decision-making as well as the team’s support for the recovery of the project. It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to the stakeholders. When the project first began, the triple constraints most likely looked like what you see in the figure below.

Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes distressed, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image/reputation as shown in the figure below.

This happens almost every time I join a troubled project. After focussing on these the project actually runs a lot smoother and high-value outcomes are prioritized and supported. So the big question is why don't we start projects with the reversed constraint triangle? Why put our image and reputation on the line by letting it come that far? Why work on things that obviously do not have such a high value because when it comes hard on hard they are not needed? Why make the quality first a priority when we already feel the pain of bad quality?

The funny thing is that agile methods like Scrum try to do exactly this. Focus on value and quality. This automatically helps your image/reputation. When the time in a Scrum project is fixed this automatically means that cost is fixed as well, but your scope is flexible. In other words, only the most valuable things are done in a good quality. When the scope is fixed, your time and costs are flexible. Still, the team will start working on the most valuable things first and you can stop the project at any time, and have valuable results. No high-risk big bangs, valuable results are delivered every sprint.

The reason I say that agile methods try to do this, and not actually do this, is because they are hindered in most organizations. The acceptance and adoption of new ways of decision making, budgeting and planning for projects lay way behind of the acceptance and adoption of using agile delivery methods in projects. And those projects are suffering because of it.

When projects suffer long enough they get into trouble, and oops, suddenly doing it differently (read better) is possible...