The Iron Triangle revised to reflect people

I had coffee with a fellow software consultant friend recently where we traded war stories about recent IT projects.

Jay told a tale familiar to many of us (Jay is not his real name, but the story is all too real).  He and his team had just recently finished a project where they had to put in very long days for months on end.  One day his son said “Daddy what are you doing here?”  Jay responded that he lives there, to which his son replied quickly “No you don’t, you live at your office!”

Now that the project is over, I asked if the project was ultimately successful, and Jay at first said that it was.  The project met the timeline required by the client, delivered the required features, and was within budget.

It didn’t take long for Jay and I to agree that although the project did ultimately meet the budget, time and scope constraints, it’s not a very rewarding success when you have to consistently work nights and weekends to make it successful.

You may have heard of the “Iron Triangle” before.  It’s the idea that the triple constraints of budget, time, and scope are closely related to each other, like the sides of a triangle.  If you put a further constraint on one side of the triangle, the other two sides must shift to accommodate that extra constraint.

For example, imagine that you give the customer a quote, and they reply: “I want it done in less time.”  The Iron Triangle says that to cut the time required, you are going to have to either decrease the scope (ie, deliver fewer features), or increase the budget (so you can add more people to the project).

The Iron Triangle is a reality of all projects, and fits perfectly fine within Agile methodologies.

The problem comes when the customer does not want to be flexible, and insists on their tight constraints on all three sides of the triangle at once.

That’s where Jay and I agreed we really should think of the Iron Triangle as an Iron Tetrahedron.  Adding a fourth point, which is related to all the sides of the triangle, will turn the triangle into a tetrahedron.  Iron Tetrahedron doesn’t quite roll off the tongue like Iron Pyramid would, but a pyramid has a square base as opposed to a triangular base, and so it’s probably better to be semantically correct.

This top point of the tetrahedron is Employee Morale.  If the customer refuses to be flexible on budget, time, or scope, then beware if you still take the project.  Your only recourse left to meet the customer’s demands is to reduce employee morale.

Yes, working consistent overtime for no extra pay may allow you to meet the customer’s demands, but what kind of life is that?  It still doesn’t guarantee that you will get the project done on time, and your quality level is likely to drop.

Keeping the Iron Triangle fixed and using employee morale as your only remaining leverage will put you on the fast track to project failure and losing your best employees.

I’ve been in those situations before, and you probably have too.  Those were my least favorite projects, and I’m determined to avoid them in the future.

How do you avoid destroying employee morale in order to keep the customer happy?  Here are some tips:

• Establish a collaborative relationship early, so the customer understands you are willing to work with them and have their best interests in mind
• Don’t delay bad news – collaborate with the customer right away on any problems or delays that occur, before they become so bad that the only recourse left is to work overtime
• Plan appropriately, and provide all estimates in ranges. This helps the customer understand that software development is filled with risk and uncertainty, and you cannot give 100% certain delivery dates based on single point estimates
• Keep your team engaged throughout the project. Make sure they understand the customer’s motivations and that they have a voice in forming estimates and suggesting changes to accommodate evolving constraints.
• Avoid giving the customer free time without telling them. If you start putting in unbillable hours early on in the project to keep things on schedule, and you don’t tell the customer, you are setting a dangerous precedent.  They won’t realize you are already working overtime for free in order to keep on track, and so they won’t realize how much they are asking of you later on in the project when they ask for you to put in extra time to meet their deadlines.
• Consider turning down the project. This is perhaps most important and yet also the hardest to do.  But if the customer refuses to budge on their demands, and you know those demands are unrealistic, you need to seriously consider if you want to take on a project that will be virtually doomed from the start and make your team’s life miserable.
• Break the contract down into multiple phases of work. Instead of contractually committing to the entire length of work, consider a contract that only commits you and the customer for a few iterations of development at a time.  That way as it becomes clear to everyone if the constraints are simply too tight, there is a natural break point where either party can leave the contract or renegotiate without losing face.

Staying true to agile principles of collaboration and teamwork, combined with range estimation techniques and strong communication skills will help your team not compromise employee morale in order to meet customer’s demands.

Thanks very much to “Jay” for the great conversation and ideas around this challenging topic.  Jay knows who he is, and unfortunately, many of us have been in the same situation too!