The Product Side
5 tips on writing specifications for custom software
So, you need to write some custom software for a business customer of yours. Most projects fall apart due to miscommunications so keep the following points in mind:
1. Tell me what you want, what you really, really want!
When someone says something, don’t take it at face value. Try to find out the reason behind.
Why does the customer ask for a specific feature, how will users interact with the software, why does the programmer say that something cannot be done?
Finding out the “why?” gives you more creative freedom and can help you design a better solution.
And also do not forget whom you’re building the software for. The end user. If they don’t like it, they won’t use it (at least not without a serious amount of complaints). They ’re the ones you have to keep happy.
2. Prepare the specs on your own
Do not let customers give you the final specs, but instead prepare your own version of what you understood. It’s really great when the customer has spent the effort to think what they need and write it down. It’s even better when they have created structured business specs. However, for the project to be a success you have to make sure that you have understood it properly, so write it all down in your own words. Then check with your customer, to verify that your understanding is correct and that this is what they really want.
3. Always write the meeting minutes yourself
After a meeting, any meeting (with the customer or with colleagues) make sure that you write the meeting minutes and communicate clearly to everyone, what was discussed, what was decided and any action items (along with who will do each item and up to when).
You need to be the one controlling the communications and clearing any misconceptions. It’s way easier to do it right after the meeting, than later.
4. Use a prototype to explain specs to customers
Many people who create business specs, do that on MS Word and come up with lengthy documents. Truth of the matter is that most people won’t bother reading these documents and the documents only come handy when you need to investigate what went wrong (something like “on page 53 it clearly says that …”). However, then, it is too late. The damage is done.
It is way more efficient to create a simple prototype to explain what the end product will look like. You may wish to use wireframes, UI designs, or even MS Access forms. They all do the trick.
Another question is whether you should get a sign-off from the customer on the specs & the prototype. Although it is certain that the final product will be different than the prototype (achieving an accuracy of 80% is a viable aim), having the customer formally accept the specs & prototype, is always helpful.
5. Use the same prototype to explain specs to the dev team
Now the prototype has another great benefit. You can use it to explain to your development team what the end product will do. You see, programmers don’t like to read functional or technical specifications either…
—
Do all of the above work? As a matter of fact they do. Using the above simple tips, I have consistently managed to achieve a 30% — 40% reduction on the time spent creating custom software and validated the approach in more than 25 custom projects.
Why don’t you give it a try?
