.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Monday, September 19, 2005

An isolated occurance might be managable but a trend can kill you.

Suppose you're running a software project and a task that was originally estimated to take 5 days actually took 8 days (60% longer). What impact to the schedule might that slip have?

The intuitive response is to think that the person that owned that task is now 3 days behind schedule. The intuitive response would be wrong. If managing software projects were that intuitive, the global failure rate on I.T. projects wouldn't be 70%.

Worse, it might be tempting to think that there is no impact, because that person can make up the 3 days later in the schedule. (If you ever convince yourself of this in a software project, go stand in the corner and think about what you've done.)

Here's the not-so-intuitive "real" story on that 3 day slip:

Firstly: We can make up those 3 days later. Really? You mean there is 3 full days in the schedule where this person is supposed to be sitting on their butt doing nothing, and we'll just use those 3 days to make up for this slip? No way. 9 times out of 10, a slip like that is not recoverable just by "willing" it to be so. If you actually do have buffer time to account for slips like these, pat yourself on the back. (But hope you have enough buffer to account for this sort of thing repeating itself.)

Secondly: Working overtime probably won't help. Do you know what it takes to make up 3 full days working overtime? Best case, suppose someone could work an extra half-day each day (4 extra hours). That's 6 days, more than a week, of working a day and a half shifts. If they can only sustain 10 hours per day (2 extra hours per day), then that's 12 days (over 2 weeks) of overtime to make up for a measly 3 day slip. Overtime makes up for schedule slips at a surprisingly unhelpful rate, and burns people out at the same time. Not to mention the poor quality code they produce while seriously demotivated and tired - poor quality code that they'll have to come back and fix later with, what... More overtime? And, while working overtime to correct for one slip, chances are that something else has slipped that will require even more overtime after that. Eventually the whole schedule just blows up.

Thirdly: Even if you re-jig the schedule so that the 3 day slip doesn't seem to hurt the product at all, what will you do with the next slip, and the one after that? Because unless this is your first software project, this isn't the first slip, and it won't be the last.

Finally: Don't you dare go reduce the amount of time scheduled for some future task unless you actually reduced the amount of requirements for that task. Otherwise, you've just swept the problem under the rug for now and it'll come back to bite you twice as hard later.

Crap. So, now what? Stop looking at a slip as an isolated occurance. What ever caused the slip, however it might appear isolated and unique, it is in some way part of a larger trend. Whether it was an error in the original time estimate, or the fact that this person got pulled off the project to go do something else for a while (a distraction), these things tend to repeat themselves if not managed as a trend.

The differences between an occurance and a trend are their perceived impact and the way you deal with them. The impact of a 3 day slip might seem small and recoverable, but if it is part of a trend (say every 10 days worth of work, there's a 3 day slip), its impact is much larger. An isolated occurance might be managable but a trend can kill you. 3 days is nothing, but 30% on a 6 month schedule is almost 2 months.

If someone on the team was off on a time estimate by 30%, what do you think the chances are that every other time estimate this person has given will be 100% accurate? Not very good. By the time someone has completed a few tasks, there's enough data to predict a trend that can have far more impact on your schedule than an isolated occurance, but thankfully is also easier to manage because a trend is more predictable.

The same goes for any time that this person may have been taken away from the project to go do other work. Was this the first time? Do you think that it could ever possibly happen again? Probably. By the time it happens a few times, again, there's enough data to form a trend.

So, if on average, tasks are slipping by 3 days for every 10 days worth of work, the pace of the project is off by 30%. By thinking about this as a trend instead of an isolated occurance, your approach to solving the problem is likely different. For an isolated occurance, you may be tempted to crack the whip and just try to get people to work harder or longer to make up for the 3 days slip. But as soon as you recognize it as a trend, you know that will never work - it's not sustainable. Your next option should be to re-cast the schedule, but this time you've got some real data (say, average Time Estimation Error or Distraction Rates) to pad the schedule with, thus negating the effects of the trend. Each trend that you spot and measure, gets some padding. Problem solved - well, immediate problem solved. You may still want to then attack the particular trends that are tripping you up in the first place, like improving your Time Estimation Error rates or reducing the Distraction Rates, but at least your project will be insulated from them while you figure out how to improve the trends themselves.

Better yet, if you tracked the trends from your last project, then you've already built them into this project schedule right? If not, then you should have enough data after the first month of a 6 month project to extend the trend over the balance of the project to figure out what its impact could be.
 

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home