Software projects tend to be expensive endeavours. With average salary for a single senior engineer topping USD 100,000/year an engineering project just maybe the most expensive engagement that the client has had to make.
It is no wonder then that the client would like to derisk the project as much as possible. The most obvious route to this outcome is to specify in great detail what it is that you want.
As a client you can then go wild specifying exactly how the screens will look like. Design flow diagrams, state diagrams, UML diagrams and just about any other diagram you can Google.
What you may not understand is that by over specifying the technical details you put your project in more jeopardy. To understand why, let us look at a classical engineering problem.
In the earlier days of the elevator business, Lift companies faced a barrage of complaints from their users on the lifts being too slow. The most obvious way of solving this problem would be to splurge on research to find out how to make the lifts faster and then spend further in development to bring the insights to life.
Thankfully an engineer identified the real problem. The issue had nothing to do with the speed of the lift but rather the perception of slowness. In short people were bored. The ingenious solution, install mirrors. This was a perfect solution, cheap to install, could be retrofitted into existing designs and the riders loved the chance to explore their vanity!
At iHub we run projects through a design sprint. The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
The design sprint helps answer the question, are we building the right product?
This sprint has proven to be the one with the highest ROI. Not because any software is built to handle the problem but because the team consisting of the developers and the client work on problem identification.
When a client walks in and hands the technical team a detailed specification document, the implicit assumption is that they know the problem and they have the solution for it. This assumption is woefully wrong.
What if it’s not, what if the Business Analysts from the client’s side actually have it nailed. Is all that remains simply for the developers to knock it off?
Unfortunately no. Change is the only constant. As the product gets developed and the idea moves from the more abstract realms, new requirements are guaranteed to arise. This changes will then become a monster of a political problem. A lot of work by a lot of people goes into writing out a detailed spec document. Changes to the document imply that somehow the authors were wrong.
People will more strongly cling to their ideas in the face of contrary evidence. The phenomenon is so well known, psychologists have a name for it Confirmation bias This human factor is almost certainly going to run your project to the ground.
Yet even if the project was somehow able to escape all the previous pitfalls, over specification tends to make the project more expensive than it needs to be. Specifying too much detail at the beginnning of the project means that you can not use commercially available software. While the third party option may not look exactly the way you envisioned it, it just might be able to deliver all that was required of it without much hustle. The economics of buying over building have been proven, let them work for you.
Finally, even well meaning clients may just lack technical insight into their own problem. A spec document in this case is then thinly veiled software design. Software architecture is a field in its own right, practitioners of it have earned their stripes from tens or even hundreds of projects before this one. Do you really want to dismiss all this experience?
How do you handle over specification within your own projects? Talk to me in the comment section below or on my twitter @jchex