Let's Talk About Spex, Baby

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.

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?

Ready?

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

a….

CLOCK!

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.