In any software development project, there is going to be risk. If a project doesn’t have risks, you shouldn’t do it! After all, as the saying goes: “no risk, no reward”. However, based on the experience of your management team, you can recognize risks in advance that are likely to occur and either mitigate, have a contingency plan, or evade them entirely.
One of the most common risks is what I call the “Tree swing risk”, and it’s exemplified by this image:
I posted this image to the Code For Cash Instagram account and it got a lot of likes. “So true!” people responded. It’s resonated with almost everyone’s experience, yet rarely managed-for.
This essential risk describes the customer not receiving what they had envisioned in their mind. This outcome leads to the negative emotions of surprise and disappointment. When this happens, “rework” is needed, often at a cost to both parties – it leads to a situation where nobody is happy. Often, the developer is fired.
How do we avoid this risk? Through creating an “idiot-proof specification”.
An idiot-proof specification has clear acceptance tests that are binary “yes or no” answers regarding functionality that the application clearly has or does not have. These are usually in the form of behavioral tests: “Can the user create an account with their email address?” “Can the user recover their password through the site?” “Can a user create a Widget through the site and have it be saved into their user dashboard?” “Can the user export the Widget to PDF format?” “Does the PDF show three different vantage points depicting the widget?”
An idiot-proof specification has visual wireframes. My favorite tool for this is Balsamiq mockups, but any reasonable tool that allows you to build mockups/wireframes will enable the customer to visually confirm that you will be building what they envision. It’s also the case that while most engineers are “left brained” and communicate through text, most managers and executives are especially “visual thinkers” and respond best to visual stimuli. A visual mockup of the deliverable cements everyone to the same page. A visual mockup need not to have beautiful, branded user interface design elements, as long as it is specified in written form whether or not the final deliverable will have a beautiful design. Always specify this case – whether or not the deliverable will be beautifully designed – in writing, and have both parties initial that!
An idiot-proof specification may be shopped on the market. This means that the software may be built by the lowest cost credible bidder on the market; indicators of credibility run the gamut from “has GitHub or portfolio” to “passes reference checks” to “meets standards of our procurement department”. Once you have an idiot-proof specification, you are in a better position to benefit from an outsourcing model.
A specification should be created in conjunction with an experienced developer (who knows what is possible), the customer (who understands the market) and the end-user who will be using the application day-to-day. A specification is something that should be paid for (by the customer). It becomes the customer’s intellectual property.
There is a saying: “a fair fight is the result of poor planning”. Almost all software projects go over budget, and those are usually due to the materialization of risks that weren’t accounted for – i.e. work that was unexpected rather than work that was expected yet ran over budget. Having the specification in hand enables a better understanding of expected work. In case you want another cliche, how about “measure twice, cut once”.
Of course, there is also the question of what should go into the specification and what is extraneous. These will be addressed in future blog posts, but for now, I recommend googling the phrase “minimum marketable feature”.
Code For Cash blog 