April 10, 2012

My top ten list on how to succeed with large project (10)s.

#10 Treat the requirement document as an evidence in an upcoming murder trial. With you as accused.

Sellers are sellers and they will always be sellers. Their job is to land deals, sell in stuff and in many cases get a fat provision for doing so. There is a small gap between selling and delivering a solution.
That responsibility lays on the project manager and below him, the system architect and the developers. To add to the problem more and more projects sells for a fixed or semifixed price, risking to give the development crew an impossible task at an impossible price.

What will be constructed is specified in the requirement document. If you want a cv that will not scare away your future employers (because the risk is that you will get sacked when a fixed price project takes a year too long at a cost of x millions) you need to treat this document with utmost respect, because if shit hits the fan this document may prove to be your executioner or your saviour. 
Fuzzy requirements will be the foundation for a fuzzy system and I am not talking fuzzy logic here. Responsibility is a dangerous beast, best treated with respect.

When the project lands on your lap after the seller sugarcoated it, it is up to you to make sure that no work is started without clear requirements. The first job in a project with fuzzy requirements should be to sharpen the specifications, no matter if it is done with analysis, prototyping or with customer workshops. Fixed prices should not be negotiated until customer and consultant agrees in a sufficient detailed way what is going to be built. 

The same rules applies when building the system, beware of gliding requirements or demands that are not specified in the requirement document. You are promising to fulfill whats in this document and you are obliged to make the customer take the consequences as soon as he wants functionality that's not included in this document. 

Of course it goes without saying that accepting a requirement document when you know it lacks vital functionality that the customer will have to pay for later is both unprofessional and unethical. 

You will not keep customers by backstabbing them.

Common sense. Only do when you know what to. 
Wonder why common sense is such a rare commodity. Maybe it has something to do with money.

No comments:

Post a Comment