As anyone with a background in IT will tell you, if something isn’t working, whether it’s hardware or software, the best solution by far is to fix it as quickly as possible. What they might not realise is that the same logic applies to the way IT departments interact with the rest of the organisation.
There’s no doubt that there’s something fundamentally broken in the way IT people and ERP users (managers, business experts and staff) communicate about the software they need to buy or build. Too often, requests made by those in the business are not adequately met by the software that the IT department is able to provide. So what’s the answer?
First, let’s look at how the relationship between IT and the business is supposed to function. In theory, the role of the IT department is to conduct a substantial study into how to convert a problem that has been defined in detail by the user into a working solution. The reality of this dynamic is, however, very different.
In practice, IT staff rarely find that the desired solution is described adequately by the users, let alone in the detail they need. After all, it’s easy to forget that specifying software requirements is also a discipline, and that most users (other than a handful of business experts with an IT background) have no experience of how to do it properly.
As an analyst/programmer, I have often noted that IT users only really know what they want until the moment they actually get what they requested. This can be a nuisance for IT, because the users’ environments are also usually in a state of continuous flux. Often, user requests have to be resolved within one or two days, based on information that has to be filtered from fairly complex data structures.
Issues can arise as a result that perhaps weren’t in evidence the day before. This, in turn, creates two problems: firstly, users have to effectively explain to IT what they need to resolve their issue, and secondly, IT also only has a small window of time to conjure up a solution.
All of which should lead us to question why, if business users don’t have the technical background they need to specify their requirements, don’t IT staff develop sufficient knowledge of ‘the business’ to be able to help this process? As an experienced, card-carrying member of the IT industry, I’ve been asking this question since way back in 1986.
At the time, I was working as a ‘gendarme’ in the IT department of the Belgian state police. We were building advanced information systems, and it was challenging work in which I could deploy my IT expertise well. On one day, I had a discussion with a colleague (a fellow student of mine and an active agent), which had a major impact on my view of IT.
My colleague dropped a clipboard on which he had just sketched out an accident. When I picked it up for him, on the back I saw the layout of the output from our ‘judicial system’ on which I had recently cooperated. Each week we sent print-outs to update the units on crimes in their area. This print-out was barely two days old. I asked my colleague whether he could make good use of the information. When he answered: “Sure Jacques, particularly the back, for making sketches”, it shocked me, particularly when I discovered in the following days that he clearly was not the only one who thought this.
My IT colleagues and I assumed that we knew the organisation well, and yet we were apparently developing systems which very few people needed. The more I thought about and investigated it, the clearer it became that something was lacking in IT training. What this tells us is that having IT knowledge on its own is not enough.
IT staff often know too little of the processes and challenges employees face, and in order to do their jobs effectively, they need to join the real world. Thinking that we only need to teach IT staff how to create a properly working solution based on a correctly specified request, can only mean that we will continue to train ‘incomplete IT staff’.
What this means is that we have two clear choices. We can keep pointing fingers at each other, and complain that we don’t understand each other, which won’t get us anywhere. Or, we can work to prepare our IT staff to work better in ‘real world’ scenarios, where the dogma that ‘the business specifies and IT makes or buys it’ no longer works. It seems clear that IT staff need to immerse themselves more in the field for which they are producing solutions.
The traditional message of ‘Sorry, we are not continuing with you because you only have IT knowledge and no understanding of our business’ or insistence that IT staff follow several supplementary university courses is not going to work. Instead, we should insist that IT staff have a genuine interest in the issue they have been tasked to resolve, so that they can help the business in specifying the request.
In doing so, they will clearly be able to identify the problem, the pressure point and how software can make a difference. Analytical abilities and logical insights are core qualities for an IT person – so why not also make use of these qualities in understanding the issue? If an IT person defines solution directions from this insights, then good solutions will follow more quickly. To paraphrase a well known phrase, if it is broken, then do fix it!