Specifications

Having been involved in many software projects, some commercial, some consulting, some disasterous, I have noticed some trends that I would like to share.

If you are commissioning (read paying or betting your job) a development project, you have to avoid being wishful.  If you just trust that the developers you hired are professionals and will keep you out of trouble it might actually happen that way, but you are playing Russian Roulette.  Even some of the best developers get overtaxed or lazy or stupid or all of these things at once.  If you don’t get very explicit in what you want you will pay for it. 

To avoid some of this I recommend that you:
 – Specify the system in as much detail as possible
 – Provide statements relative to how the system will be used and the intent of the project
 – Emphasis should be placed on what YOU define to be acceptable.  Define terms up front such as “commercial quality” and “easy to use”

The less you leave up to the imagination the better.  Also insist on frequent demos throughout the process with opt out options if things are just too off track.

Always remember that consulting is based on who takes the risk.  In a fixed bid engagement the developer takes most of the risk and therefore the price is uplifted accordingly.  In a time and materials engagement it is the buyer who takes all the risk and often it is the buyer who must ensure things are proceeding according to plan.

In the end it is the specification that will decide if the developers did their job or not…