Apr 18, 2019
Specification: Insert picture of Salt-N-Pepa here.
I think we all really underestimate how difficult it is to write a technical specification. Let’s give an example.
Imagine you’re tasked with purchasing ‘A Mobile Phone’ for the NHS Trust that you work for. We all use mobile phones and so writing a specification for a phone should be simple, right?
Well, I ran an experiment. I asked friends on Facebook the following question and they kindly responded.
One of my favourites from that lot was “Keeping kids quiet”! :D But seriously, that’s actually a useful feature of a mobile phone for a substantial group of people. Easy to miss on a spec and shows the importance of user interviews.
Try it for yourself… Can you think of 3 ‘Must Have Features’ of a mobile phone?
Really? You tried?
OK. So the point I want to make is that THE MOST USED FEATURE of a mobile phone rarely makes that list. There’s a feature on a phone that accounts for around 90% of ALL usage? Confident that you’ve got that captured in your specification?
So, the BIG reveal…
The most used feature of a mobile phone (by about 90%) IS…
I’m just going to fill the page with drum rolls so you can’t sneak peek the answer.
More drum roll
And more specifically, having the time displayed on the front when it’s locked.
That’s a phone. Imagine trying to write a specification / invitation to tender, for an appraisal, job planning, or e-Rostering system?
Our equivalent of the CLOCK, and our MOST USED FEATURE (by a similar 90% margin) is Customer and Technical Support Access. Despite this, it’s not uncommon for us to see an ITT or specification that doesn’t even mention it! Let alone give it a significant score.
I think we can all agree that writing detailed specifications is very hard. So what’s the answer?
I suggest that we consider articulating our problems, not the solutions
Software development has been this way for some while. We’ve moved away from Big Design Up Front and The Waterfall Model to Agile Software Development that put an emphasis on broader aspirations with detail being left until the point of implementation.
Procurement practices and specification writers would be well advised to take a closer look at the user requirements capture process. In future, I’d like to see technical specification that look more akin to the ‘Card, Conversation, Confirmation’ paradigm in Agile methodologies
There’s an excellent book on this subject, as my dog eared copy will testify. It’s primarily written for a technical reader but I think many of the chapters would be useful to a non-technical reader trying to understand specification design.
Or it could be that I’m just an eternal rebel who hates to be pinned down on detail? You decide.
Have a great Easter all!
You should sign up to our newsletter because it will keep you up to date with Medical HR, technology and what SARD JV are up to. We promise not to send you a load of sales bumf. Newsletters have a typical email open rate of around 15-20%. We aim to keep our open rate above 60%. That means we'll only add you to the list if you really want to be added and work hard to send you interesting stuff.