Title: Grain Storage MIS: A Failure of Communications (27 March 1998)

In the early 1980s I was given full responsibility for a software development project for the first time. A Northumbrian farmer bought, sold and stored grain on behalf of other farmers. The Sunday colour supplements were writing about the new "micro-computers" and this farmer saw an opportunity to automate the administration of his business. It was my job to find out what he needed and build a suitable software system. The project was a nice little earner for my employer, but in every other respect it must be regarded as a failure. The rest of this paper examines what went wrong.

From the farmer's point of view a computer was a box with lots of flashing lights which, by some technical wizardry, performed all the administrative functions of a business. A micro-computer with a floppy disk or two and a printer would do everything his business needed. And all he had to do was buy one.

We tried to explain that it wasn't quite as simple as that. Computers need software to tell them what to do. He would need to choose what software to use. In particular, he would need to decide whether to use an off-the-shelf package, have something tailored to his needs or have some software written specifically for his business. He looked at us as if to say, "It didn't sound that complicated in the Sunday Times".

Of course, we could advise him, but expert advice wasn't cheap even then. The farmer suspected he was being conned, but he had to trust us. His discomfort was almost tangible.

We tried to allay his fears by explaining the process of selecting an appropriate computer system. First, we would need to know something about his business so that we could assess how it could benefit from a computer system. We would then present a number of options and he, the client, could choose one.

His response was somewhat pained. He couldn't understand why the farmer, who knew nothing about computers, should have to decide what hardware and software to buy. That was the job of the consultant. That was what he would be paying for.

Wearing our salesman's hats we seized the opportunity. "All right", we said. "We will make the technical decisions. All you have to do is to tell us how you run your business". We had a deal.

Up to this point I was a technical expert providing support to the sales team. From then on it was my responsibility to keep the client satisfied. It was the first time I had dealt directly with the client and the first time I had been asked to develop a business administration system. It was new territory, but the way forward was clear enough. The farmer would describe the processes involved in buying, selling and storing grain; I would translate his description into software. He knew the business, I knew about software and we both spoke English. All the essential ingredients were there. I anticipated no significant problems. This was, of course, a big mistake - the biggest mistake of my career to date.

It quickly became apparent that standard software packages would not meet the customer's requirements. The farmer entered into various contracts with other farmers. Under the storage contracts grain was charged by weight and period stored. There were also sale and purchase contracts with provisions specific to the type of business. The client wanted these various contracts to be at the heart of the computer system and no standard package would handle them.

We offered the prospect of a cheaper system based on a standard database package, but the client preferred a fully customised solution. So I started to ask how the business operated. The farmer mentioned a few salient points and assumed that I would be able to fill in the details from my general knowledge of commercial computer systems. I didn't like to tell him that my experience of such systems was negligible. In the hope of hiding my ignorance I nodded knowingly and went away to start on the design. Perhaps I could get the information I needed about the requirements by discussing some specific design suggestions.

The project tottered along in this vein for some time. We wrote some code, but we never seemed to be getting any closer to delivering something useful. There was more than one crisis meeting with the client. Eventually, I moved on to other projects. Two years later my employer was still writing software for the farmer. To this day I do not know if he ever saw any benefit.

There are many lessons that can be learned from stories such as this. I learned how important it is to define the requirements, to do it properly and to do it before the design. But above all, I learned that good communications are essential to successful collaboration between a client and his consultant.

One final thought. Sadly, it is my experience that these things can only be learned by experience. How else can we explain why the software industry continues to make the same mistakes over and over again?