A fascinating discussion ensued the other day on the project: involving technology users in specification of systems is important but how should an IT or other technology project be organised to achieve that? Sounds simple. But it’s not. The problem is this.
If one is setting out to procure an IT system, one needs to have a specification for the system to be purchased. That system specification can then be appended to documented instructions to bidders and to relevant terms and conditions of contract under which the quotation should be made. The specification, instructions and terms can then be sent out to possible vendors to elicit quotations.
At the centre of the discussion is the language used. Let’s assume that the system employs a credit card reader. Should one set out the technical specification by using language like “the system shall use a hand held credit card reader tethered to the point of sale machine using a robust cord”. Or should it be even more specific by specifying that “the credit card reader shall employ a PIC12C509 microcontroller”. Join these together and add a few more perfectly reasonable statements and you’d surely get a very well specified device.
So what’s the issue? Why does the language matter?
There are two problems with this form of specification writing. The first problem is that it requires the specifier to be a subject matter expert. And that’s a problem in system specification.
Research (and lots of anecdote from failed systems like the UK National Health Service NPfIT project) shows that getting user involvement and buy-in is key to success when the IT comes to be rolled out and pressed into use. User involvement is a cognitive process. Users have to start by participating. Participation deepens to become involvement and even commitment to the project and to the ensuing change. Remember, IT will only lead to competitive advantage (more sales and more profit) when pre-existing complementary human resources are exploited. The end-user must be involved from the outset.
But users can’t participate in and help build the specification discussed here. They’re not subject matter experts in credit card reading technology. They are experts in their own business. We must use language that users understand and would themselves employ when talking about the system.
And the second problem requires us to use a level of analysis that is of high enough abstraction to allow many vendors to be compliant. Very exact specification using detailed specifier experience and knowledge narrows the number of vendors able to bid. Maybe it doesn’t matter if it is a hand held device tethered using a cord. Why can’t it be a fixed device connected by wireless? And who cares if it uses a PIC12C509 or not. That may be old technology anyway. Surely what matters is that the specification meets the user need and perhaps a relevant standard like ISO 8583 for message format and data flow?
So to satisfy both points the specification has to employ user language. It’s not the specifier’s job to solutioneer. The specifier has to be agnostic towards the technology that vendors may offer to afford the user the utility that they require. For sure, there are mandatory elements like the standards to be met but for the most part the language should read ”the user shall be able to…”.
In the example above we might say that “the user shall be able to offer customer credit cards to settle their bill on a point of sale device employing international standard ISO 8583”. It’s for the vendor to make an offer of something suitable.