Scope, Schedule, and Resources – You can’t have them all

Imagine the scene.  You are starting a new project.  At the kickoff meeting the stakeholder introduces the mission of the project, the business analyst hands out the requirements document, the project manager hands out the project plan, and the development manager gives his best “Do it for the Gipper” speech.  You look through the project plan and see that it specifies a release date (several months in the future), the resources that will be involved, major milestones to be met, and everyone’s assignments.

The team looks over the stack of paper in front of them, and roll their eyes. “Here we go again” is on everyone’s mind, but think better about voicing it out loud.  Out come the smart phones to see what family events and vacations will have to be cancelled due to slipped release dates and last minute death marches. 

Why does this happen?  And seem to happen often enough that everyone who’s been a developer for more than a few years all have a similar story. 

The Iron Triangle of Project Management

There are three factors of software development that must be considered.  What will go into the release, how much the project will cost (largely a factor of the number of resources involved), and how long it will take to develop.  This triangle is traditionally represented a number of ways, but I prefer the figure to the right.  It shows the balance between these three factors.  If any one of them is changed, it will offset the triangle, and the other factors will have to be adjusted accordingly.

Increasing the scope (for example) will extend the right side of the triangle, and schedule and cost must be extended to keep everything in balance.

This is not news to anyone in project management.  In fact, it’s a well known fact for all types of projects, software, construction, and manufacturing.  In theory, it makes perfect sense.  If I need to build a house, I take the blue prints and can calculate with a high degree of certainty how many people I will need (and for how long), what the cost of the materials will be, and how long it will take to build that house.

The Fundamental Flaw

This theory holds up as long as everything on the project is roses and unicorns.  But what if there is a significant rainfall that floods the build site and construction is delayed for a week?  What if there is a hurricane on the coast, and this creates a shortage of drywall?  What if the construction company has never built a straw-bale house before? Now instead of repeating the same job that they have done hundreds or thousands of times before, they can only guess how long it will take.

And this is the fundamental flaw with the iron triangle.  Scope can never be absolutely predicted.  It can be accurately predicted for tasks that you have done many times before.  Do you drive to work?  How long does it take? Your answer is probably something like “About X minutes”.  It’s about because of the variables that occur in life.  Maybe the traffic lights are against you one day, but you catch them all green the next.  What if there’s an accident?  Could you predict that it would take you 90 minutes to get to work when yesterday it only took 30?  Certainly the scope of the work was the same.  Driving from home to work.  But the schedule (and one might say the cost due to increased fuel consumption) changed significantly.

Estimates are not Exactimates

How do you estimate the amount of time a task will take?  Is it something that you have done before?  Or is it just like something you’ve done before.  Or maybe you have never done anything like it.  How do you tell decide how much time do you need in the schedule?  Most developers who are honest with themselves will usually admit that it’s all a guess.  Sometimes it’s a SWAG – Scientific Wild A$$ Guess.  But usually it’s just a WAG – dropping the science.

How many times have you given your estimates to you development lead and he/she doubles them. “Developers are always too optimistic”.  Then these numbers are handed into the project management office, and they add another factor on top. “Last project ran late, so we will build in some slack to make sure we deliver on time”.

Then these numbers are carefully factored into the project plan, and the promise of is handed out to all parties – stakeholders, management, and any other interested parties.  “We will deliver this amount of work on this date and it will cost this much” is the triumphant announcement.

And once again the cycle commences…

The Death March

As the project is commencing, and everyone is carefully reporting their hours and status, the problems start to hit.  Maybe not big ones at first, but they begin to add up.  That 8 hour task took 16.  Bob got sick and missed a week of work. Susie’s baby came early, and is on maternity leave.  The chance of delivering the promised scope at the promised time with the approved budget becomes slimmer as time marches on.

Concessions have to be made, but the iron triangle is, well, iron.  One can’t just pull one side longer and keep the same shape.  The date has been promised to external organizations.  Perhaps there’s a marketing campaign that is set to launch at the same time as the new software.  Maybe customer contracts are in place.  Regardless of the obligation, the date is usually the last thing that can move. So the only chance is to throw hours at the project.  Overtime gets approved, and all are expected to work extra.  Just a few hours at first, but then more as the triangle gets more unbalanced. 

More often than not, the overtime progresses into a death march.  Developers are eating dinner at their desks, working through lunch, make life sacrifices for the sake of the project.  Quality starts to degrade due to exhaustion and less careful programming.

There an old saying that nine women in a month can make a baby.  However, this principle often gets applied in these situations when management approves bringing in extra headcount to try and save the project. 

Maybe the extra head count and overtime work does save the project.  But did you notice what happened?  The cost/resources side of the triangle got extended to account for the change in scope.  Despite the best efforts (and intentions) of all parties involved, the reality of the situation couldn’t be avoided.

Making The Right Choice

Reality is clear.  You can’t fix all three sides of the triangle.  As an organization, you have to decide what is most important to you.  Is it release date?  Then fix the date, and make the concession that the software will have as much scope as was able to be completed in a quality manner in that time frame.  The advantage of fixing schedule is that it produces the side effect of fixing the cost.  If you have X team members, they will be working Y hours per week until release.  Cost then is fixed at X*Y*Z where Z is the number of weeks until release (of course in reality you have things like vacations, sick leaves, etc. that must be factored in).

The opposite is true as well.  If you have a fixed budget, you can extrapolate a release date by doing the above calculation solving for Z instead of the right hand side of the equation.

Fixing scope isn’t as clear cut of a story.  Since scope relies on inaccurate estimates, that side of the triangle will keep moving, adjusting schedule and cost along with the changes from estimates to actuals.

So decide what matters.  Put a stake in the ground for your release date.  Or your budget.  Than realize that the rest will be what it will be.  But at least you can keep your promise the stakeholders, the customers, and most importantly, to the team.

Happy Coding!