Flexing Iron Triangles

Any Project Manager will be able to quote to you the three vertices of the famous “iron triangle” of project management: Scope, Resources, and Schedule. Every project is a combination of these three elements:

• Scope: What we’re going to do
• Resources: How much money we have to spend to get it done
• Schedule: How much time we have to get it done

I’ve had managers who jokingly said that they want everything yesterday for free. Usually when a manager says this, or a variation of this, they are usually really asking me for options on scope, on resources, or about the schedule. Sometimes these are variable and sometimes they’re not. I need to ask the manager precision questions around the business need for the deliverable to get the right answers and move the levers of the triangle appropriately. What features do you really need? Who is the customer? What is the venue? Who is the presenter? When is the presentation? How many will be present? Sometimes you can narrow the use cases down to a scope that can be accomplished in a given timeframe in this way. When managers become intransigent around these questions, that’s usually a sign you have a bad manager, or you aren’t asking the questions very well.

The idea is that you can often fix any two of the vertexes. For example, if you have a fixed set of resources and fixed cost, your schedule is going to vary; or, you can reduce the number of features in a product to get it done in a given timeframe. A key takeaway of the iron triangle is that you cannot fix all three sides. Such a system becomes over-constrained.

In software development organizations, over-constraining the iron triangle is very common. Something, however, must give. When a software development effort is over constrained, the usual result is:
• High bug rates
• Low morale
• Late schedules
• Cut features
• Failure to adopt new technologies
• Low productivity

What gives is obvious: quality. We have metrics already within our own organization to prove this. We have high inspection yields and high bug densities in our software, which indicates if we spent a little extra time checking our work, our quality would dramatically improve. We can correct this by injecting quality processes as standard operating procedures and setting expectations that this will be the way we will work from this point forward. We will be doing inspections. We will be writing unit tests. We will be doing peer reviews. Code will not be checked in until it passes all of the StyleCop and FXcop rules we put in place. Etc., etc. Software development will appear to slow down, but quality will go up. This is about setting expectations and pushing quality upstream. When doing your estimates, remember wide-band delphi estimation is about uncovering assumptions: did you include testing in your assumptions? Stress testing? Performance testing? Inspections? These are things software engineers do. Coders don't.