Requiring everything documented to smallest of detail.

Stop trying to document every miniscule detail in an effort to prevent failure. You are guaranteed failure if you try and create documents that describe everything, quite simply you run out of time to do any high quality development work. You discuss the project, you document it, put in controls, discuss it, document it more, prioritise and re-prioritise, then at the end you want your Developers to finish the whole project in just an impossible 2 months.

In a lot of cases, a high level description in just a few paragraphs is sufficient and gives you the flexibility to change your requirements. When a task is allocated to a developer, the developer can discuss the detail with the users and business owners.

Here’s an analogy. Many large software projects often have more parts than a car. And certainly the parts in a software project will have more complex interaction than the parts in a car.

Suppose you were asked to document all the features that you needed in your ideal car. You also have to describe how all the parts fit together, describe the material and metal to be used. Specified the size and type of every bolt. You would probably take a very long time, then end document world probably be wrong and lack many of the feature that you want.

And because of your complex and rigid change control mechanism you cannot accommodate changes along the way.

A car is fairly simple to understand compared to a complex business application. Yet you regularly try and produce highly detailed requirement and specification documents. That’s crazy.

How about specifying some top level requirements?

So going back to the analogy of the car.

Needs it to run on green fuel.
Needs to be four wheel drive.
Be good if backseats folded forward.

Those brief descriptions are enough for everyone to understand where the project is headed. It means that actual work of creating the application can begin far earlier. Just imagine if you had to produce all the detail of how a seat folding mechanism should work. It would take weeks. Weeks that could be used in getting the project started.

The actual detail can be thrashed out at the time that it is needed. Perhaps you can call it “Just in Time Design”

This Just in Time design technique allows for something that always happens on Software Projects. Users changing their minds and thinking of new requirements. It always happens, it’s good, so why not cater for change? In the case of the car, the user may decide that he know longer needs the rear seats. Thus you have not wasted any time in doing a detailed design.