In my last blog I looked a Process Related Classic Mistakes from Rapid Development: Taming Wild Software Schedules by Steve McConnell, which although it’s now been around for at least 10 years, and times have changed, is still as relevant today as when it was written.

As Steve’s book states, classic mistakes are classic mistakes because they’re mistakes that are made so often and by so many people. They have predictably bad results and, when you know them, they stick out like a sore thumb and the idea behind listing them here is that, once you know them, you can spot them and hopefully do something to remedy their effect.

Classic mistakes can be divided in to four types:

• People Related Mistakes
• Process Related Mistakes
• Product Related Mistakes
• Technology Related Mistakes

Today’s blog takes a quick look at the third of Steve’s categories of mistakes: Product Related Mistakes, which include:

• Requirements Gold-Plating
• Feature Creep
• Developer Gold Plating
• Push-me, Pull-me Negotiation
• Research Orientated Development

Requirements Gold-Plating

Defining a luxury Rolls Royce of a product when an economical hatchback is all that the user requires. This is adding unnecessary features or function points. Users tend to be less interested in complex features than either Marketing or Development and complex features add a disproportionate amount of time to the development schedule.

Feature Creep

The average project experiences about a 25% change in the requirements over its lifetime. This will add at least 25% to the schedule.

Developer Gold Plating

Developers like to play with new technology and are anxious to try new things out - even if its only as a means to bolstering their CV’s. They also like adding features because they’re ‘neat’ or ‘cool’ and will take no time at all. There’s no such thing as a free lunch, all new features need to be tested, documented, supported, reviewed etc. etc. Add these features in the next release after evaluating whether or not they’re really required.

Push-me, Pull-me Negotiation

This is bizarre! Some managers approve a schedule slip on a project that is progressing more slowly than expected and then add in additional new tasks after the schedule change to make the schedule wrong again.

Research Orientated Development

If your project pushes the state of the art limits, requires new algorithms, hardware designs and higher speed then you’re doing research not development. Research schedules are very problematic and usually wrong. Beware, don’t expect to advance the state of the art to rapidly.