Letter: Keeping end-users happy

Several years ago, I found myself working as the lead analyst/programmer in charge of maintaining a complex, real-time, data collection system. The end users fell under an operations division; a separate IT division provided computer support. Most of the time, the user community provided requests for changes directly to me -- and with some ad hoc coordination, I usually managed to turn them into new and improved software.

Naturally, none of this happened in a vacuum. Every week some senior manager in operations grumbled about how long it was taking to implement software changes -- and just as frequently a senior IT honcho would start complaining about scope creep and the need for additional time to implement changes. Fortunately, these things seldom occurred at the same time. But one large project got caught smack dab in the middle.

The project involved upgrading the database application to support enhanced data entry, improved user query/display capabilities, and some offline analysis capabilities. Operations would provide detailed specs; IT would implement them on a strict schedule. Senior management announced that no deviation from the specs would be allowed. Given that decree, it seemed fruitless to point out that the specs might not be what the users needed.

I succeeded in bringing the project online within the agreed time frame. Senior managers on both sides were happy. However, when end users began using the new system, they were less enthusiastic. Although the new system did improve user capabilities a bit, it was a far cry from the great leap forward that everyone was expecting.

Most of the complaints centered on the interface for retrieving and displaying information. By now I knew what was needed, so I decided to write an improved user interface on my own time. Late one night, a couple weeks later, I demonstrated my new interface to a line supervisor in operations. His response was pathetically enthusiastic. "Wow!" he cried. "This is exactly what we need!" He begged me to leave the test version running for his people to "try". (Sorry, no.) "OK," he said, "then how can we get these capabilities added?"

Since many people in both divisions were quite sensitive, I provided some suggested language for incremental change requests, and a timetable. The requests, which followed my language exactly, started arriving from operations the next day. In two weeks I started delivering "new" software that magically matched the requested capabilities perfectly. Senior management was surprised to see so many change requests, but when I reminded them that incremental changes to new systems were common after start-up, they approved them. Both operations and IT were amazed that the improvements were being implemented so quickly; the end users were happy; and, of course, I came out looking like a champ.

A number of lessons can be gleaned: first, it's hugely important to get end users involved in designing specifications. And since senior management is far removed from day-to-day functions, it should leave the design work to lower-level staff. Finally, when managers are busy fighting turf battles, nobody wins -- and the users at the bottom of the food chain end up sucking pond water.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about DABHIS

Show Comments