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

Uncommon Sense (for Software)

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

Wednesday, March 15, 2006

Death by a thousand cuts

One of the biggest software project killer factors is requirements management - or more accurately, lack of requirements management. You've seen it: requirements that either keep growing, long after development has begun, or change more regularly than you could possibly keep track.

(I once worked for a company where the leadership team was still arguing about what the product was supposed to be, a month before it was supposed to be done.)

Everyone knows that requirements management is a problem. So if knowing is half the battle, then what's the other half? Why isn't there a well known, clear solution? What does it actually mean to "manage" requirements?

The trouble with most cases of changing requirements is two fold:

  • Each individual change is small enough to slide under the radar: If it only takes a developer 4 hours to knock off a new feature, where's the harm? So it's not tracked...

  • Since the changes aren't tracked (and tallied), the sum of the changes quietly adds up, but is never addressed in the schedule.


Before you know it, you're now 2 months behind schedule, and sliding fast. This is like death by a thousand cuts. A single paper-cut may be little more than a nuisance, but a thousand at once can make you bleed to death. I saw a movie once (can't remember what it was) where the bad guy was stealing money from a bank by hacking into their computers and collecting all of the fractions of a cent that resulted from certain bank transactions. Since it was fractions of a cent, it was virtually untraceable, except that over billions of transactions, it eventually added up.

Most people intuitively know that changing requirements mid-cycle is bad, but they don't realize how often it happens, or what the impact is, so they're powerless to adapt for it and schedule around it. Since they don't see the impact, they have no incentive or reason to knock it off. And in the end, it's not the changing requirements that kill us (adaptability = good), but the fact that we didn't plan for them or that we let them get out of control that does. It's the unwelcome surprise.

Managing requirements doesn't necessarily mean determining them all up front, before development begins, then freezing them through a development cycle, and saying no to every request until the thing ships. That's just not realistic. Adaptability afterall, is a key strength in business.

Well, if not that, then what? The first part of the solution is quantification. It's no use trying to use anecdotes to show people how "requirements keep changing and it's going to make us late." Chances are, the only examples you'll have at your finger tips are those "4 hour" requests that don't have the shock factor you're going to need illustrate your point. Remember, no single change request is the problem, it's the cumulative effect where dealing with. So if you can't demonstrate the cumulative effect, the message just comes off as complaining and falls on deaf ears. To show the cumulative effect, you need to have tracked them - all of them. That's the only way you'll have a shot at credibly demonstrating the impact. Each one may only be 4 hours, but x3 per week is a minimum of a 30% reduction in some poor developer's productivity, not even including the context switch (arguably another 20%). Then there's the fact that every seemingly 4 hour request actually balloons to a full day when all's said and done.

Suppose you've quantified the impact early on. Let's say, in the first 2 months of a 6 month project, you've calculated that requirements changes have added up to 2 weeks worth of extra effort. Not only are you now 2 weeks behind schedule, but if the trend continues, you're likely to add another 4 weeks of requirements change in the remaining 4 months of the schedule, for a total impact of 1.5 months of your original 6 month schedule. All for seemingly little requests here and there.

So managing requirements doesn't mean Big Up Front Design and no changes mid-cycle, it means:

  • Tracking and trending the changes

  • Using the trend to assess impact

  • Making good decisions around how much of this change you should plan for in your schedule


Only by tracking the seemingly harmless change requests can you see their cumulative effect before it's too late. Not letting them surprise you and catch you flat-footed is key. Only by using real data instead of anecdotes can you have productive conversations about requirements change with those that need to know.

4 Comments:

  • You're making me salivate for Devshop...screenshots, beta, anything, soon?

    By Anonymous Geof Harries, at March 16, 2006 12:43 AM  

  • Hey Geof,

    Glad to hear it ;). Actually, I'm quite literally putting the finishing touches on the new web-site today. It should be up before the end of the day tomorrow (Friday). It's weighing in at about 8 pages or so, with screen shots. Although I can't quite give away all of my secrets before launch, this site does give a pretty good summary description of what Devshop is all about. Plus, it's a place where I'll be able to add new content running up to launch, as it becomes available.

    By Blogger Craig Fitzpatrick, at March 16, 2006 7:44 AM  

  • hi, death by 1000 cuts ... couldn't be explained better. great article! (maybe a tad too long.)

    phil

    p.s.: i'm very curious about devshop, too! but how do i enlarge the screenshots? i can't see a thing! ;-)

    By Anonymous phil, at March 22, 2006 5:46 PM  

  • Hey Phil,

    I'm working on wittling down my lengthy posts. Glad you like it though.

    I'm being a bit of a tease with the screen shots, I know! ;) I'll be letting more of the cat out of the bag over the next couple months.

    Stay tuned!

    Craig

    By Blogger Craig Fitzpatrick, at March 22, 2006 5:55 PM  

Post a Comment

Links to this post:

Create a Link

<< Home