Friday, October 10, 2008

Snowflake Specifications

One easy mistake to make when making preliminary estimates is picking one method as the sole basis for estimates, for example functional areas. Although it's tempting to think that you know what's required when a functional requirement like "add a new user" or "report on daily revenue" shows up in the RFT, the truth is you don't have a clue. The part that requires a swanky front end and persisting the information to the database is what you see, and that is easy to estimate. The seventeen step user approval process, and the half a dozen external payments systems the daily revenue report has to interface with aren't mentioned anywhere, and if you think a RFT is going to include this information, you don't work in Australia.

The real killer in these situations is business rules. Clients rarely know all of the rules they follow, sometimes because their old system does it transparently, sometimes because they do it so often they don't even think about it, and sometimes for no discernible reason. If you ignore the number of business rules that govern an area of functionality then you run the risk of seriously underestimating any changes to scope that might occur. Each new business rule, no matter how small, will take time to implement and it can really add up.

Consider the situation geometrically. Think of a functional area as a triangle, bounded by its business rules (no really, do). The developers and the business analysts get together and come up with an initial estimate for a supersoldier breeding program based on the requirements provided by the tax department. Several months later, the client comes in and mentions that even though only people over 6'4" are allowed to be users of the system, if they also have brown hair, then they only have to be 6'3". Now your triangle's sides have another little triangle jutting out of the side, because there's a new business rule, but it's only a little one, and it doesn't increase the functionality much. Oh, and also if the user has blue eyes, all the height requirements are reduced by 1". Now each of the little triangles has a littler triangle jutting out of it. Half a dozen such meetings later, and it's time to re-estimate the functionality.

If you know your maths, the area now in scope should be a familiar shape, if not I guess it's just a pretty snowflake. On its face, the scope of the functionality has increased, but to less than double its original value. A price for the change can be generated based off the original estimate and nobody interrupts the development team. After all, they haven't started working on it yet and they're all flat out working on other features.

So, what's the problem? Well, the functionality may not have increased much, but the business rules defining the functionality could blow all the way out to infinity and functional requirements still wouldn't change much.

I know it sounds simple, but make sure your initial estimation method has enough flexibility to account for a variety of types of changes. If you don't, you'll end up getting snowed under.

No comments: