Just give us the requirements!

In spite of all the progress in agile ways of working, value streams and DevOps there remains, buried deep in the doctrine of the modern enterprise, the idea that users give IT people requirements and the IT people build what they ask for.

In the crucible of delivery both sides fall back to this mindset for comfort. The user community, unable or perhaps unwilling, to comprehend why IT can't or won't deliver what they perceive they need, demand the final say. The IT community, frustrated by being asked to build something they feel is a poor solution, or will lead to trouble down the line, are fed up of being ignored.

Similarly IT folk will reject - as none of their business - any attempt by users to influence technology choices. Just tell us what you want to do and we'll choose what is best for you (sometimes without sounding patronising). End users who are being implored by management to embrace technology find the barrier to entry high and often aggressively guarded.

This quietly simmering conflict is often aggravated by technology vendors who seek to influence both sides to secure a sale. Pitching impressive outcomes, efficiency improvements and fancy user interfaces to business executives often reignites the conflict. The executive, hooked on high-level sales pitch, and not wishing to appear impotent in their own organisation, says 'why can't we have that?', resulting in protracted dialogue of recanting their established reasons why the vendor's product doesn't fit into the current IT architecture and explaining (or using as an excuse) the likely cost to change.

The motivated vendor also pitches the IT organisation with claims to support the latest automated deployment, testing and scaling technology to reduce IT costs. Alas these augments are often lost when relayed to business folk who see a load of up-front cost and operational risk to their business for some fancy technology words they don't understand and down-the-line benefits they'll be long-gone to be recognised for. All risk and no reward - no thank you, just build what you are told!

And so the 'order giver, order taker' mindset persists inside organisations. To achieve a true partnership both sides need to give a little. Business users need to recognise they don't have a monopoly on good ideas and that for the good of the enterprise a feature that saves IT cost may be more important than one that improves their productivity. In truth, users rarely know what they want until they see it, so in many ways true requirements begin life inside the mind and perception of the developer who guesses what the user might value based on the art of the possible and then (hopefully before too long) has the opportunity to say 'did I get it right?' IT organisations equally need to recognise that the business users are exposed to a vast range of technology (often the latest stuff) in their personal as well as professional lives. IT people no longer have a monopoly on the options. Within their specialism business users may know the 'state of the art' better than their IT colleagues do - they are worth listening to.

In my own view, the further up the technology stack you go, and the more business-specific the requirement is, the more the user perspective needs to be taken into account. The end user community usually neither knows, nor cares, what the preferred brand of server is, the choice of operating system or the flavour of database. However, when making choices between specialist vendors, graphical interfaces or productivity aids then the users voice should be in the lead.

There are always exceptions of course, my favourite being security, which is both deep down in the technology but can have a fundamental impact on how business is done and the cyber risk profile the organisation is exposed to (a topic for another day). Another challenging area is how to organise data. For analytic and data science users the structure of the organisation's data dictates their everyday work - vastly more time is spend wrangling data than doing actual data science. A data structure that is optimal for IT may impose an unacceptable burden on users - with poor query response times and increased latency in decision making. Should data structures be designed by IT or by business analysts? Clearly it's a bit of both.

These days making smart technology choices is often the differentiator between a successful business and a slowly dying inefficient and ineffective enterprise. We need to involve all our talents to make the right choices, and recognise everyone has the right to be heard in both the 'what' and the 'how'.

(Views in this article are my own)