Reg Roundtable It’s an omni-channel world, they say, and the dissolving lines between organisations and their customers, and their suppliers, are countered by the multitude of ways they might be hitting your systems. Systems that might be driven as much by the apparent whims of other departments as traditional IT planning.
We gathered a dozen IT execs for our last roundtable before the summer holidays to work out where the boundaries are for today’s IT department and what we can do to stop IT becoming just a glorified part of facilities management.
Your users aren’t customers
Our IT Decision Makers (ITDMs) immediately attacked a basic premise of our meeting that boundaries were a good thing, explaining how a good offence was a superior defence. The thing they seem to hate most in the world isn’t Oracle after all, but the Waterfall methodology.
This was seen as discredited in the 1960s and was only briefly mentioned on my (1980s) CompSci degree briefly in terms of “dying out”. But it persists, especially in the form of treating your users as customers.
An article of faith amongst all IT Pros is that the users haven’t a clue, yet we persist in asking people we know to be clueless what it is they want. Then we act all surprised after nine months of hard work, when they either complain or simply don’t use it at all and ask pointed questions about where all the money went.
Because we’ve treated users in a transactional way, gathering requirements and building something that does what they said they wanted, we’ve built a wall that all too often is seen by them as something we just chuck things over.
One thing you will find hard to accept in this article is that programming is a creative process. We have got so accustomed to the idea that “creative” is something done by arts graduates on drugs that the self image of most developers recoils from being seen as flaky/creative.
But software development is creative. You are creating something that did not exist before. Developers work with a perfectly flexible medium that is bounded only by their own ability.
This means of course that nearly everything you might create is useless. It might be clever, fast and quite possibly do what the specification says, but that’s not the same as useful.
External vendors will sit down with customers, find out what they want and deliver it, so the question amongst users has always been why they are forced to use central IT when they are performing the important role of understanding the business?
It is common for an external software house to know more about a business than the people in central IT. A legacy of failure to deliver and the fact that cloud services are not only now widely available, but marketed heavily to decision makers outside central IT is a harsh and growing pressure.
The ITDMs saw this as fine for dull systems that fulfil some compliance requirement, but for innovative projects it sucks.
Shops still exist despite it being cheaper online because there are so many things that we need to touch and feel to decide whether we like. Amazon et al do lots of pictures and text, but our ITDMs were very clear that prototyping is the only way to get new innovative ideas across.
Of course, most of that innovation will be crap because you don’t know what it is that the users need, partly because they don’t know and partly because they do a different job.
So the ITDMs advocate making your developers actually sit with users for a good while, so as to pick up where they are in pain and where we can make their lives better. Well, nearly all of them did.
At some firms there are bridges to be built after long years of non-delivery. They were clear that you have to clear some space and make your group “delivery ready” else you’ll raise great expectations with a cool new way of helping them do their jobs, then come back with “yes, but we have to do the new expenses system first”.