The perils of ignoring the user

Everyone should know by now that you're supposed to involve users in development. But what happens when you don't? Find out in this case study of a very large and familiar institution.

By William Graham

I recently attended a worldwide users’ conference of military aviation maintenance officers, where one speaker pronounced, “I don’t see any need to involve the user community in our development effort.”

“Aha,” I thought to myself, looking around to see if any of my fellow attendees were reaching for weapons. “That explains a lot of things.”

The speaker just barely escaped being the honored guest of a lynch mob.

Of course, the notion that end users should be involved in the development process should not be news to too many people. Still, some people just don’t get it. Here, we’re going to look at a case where the user was disregarded and see some of the contributing factors that have led to the overall decline of the product.

This is the system that Jack built
The aforementioned speaker at the conference represented the project office that was responsible for what is possibly one of the most universally despised pieces of software that his service had ever fielded. In its latest incarnation, the system started fielding in the mid-90s.

The technology hardware and network architectures of the early '90s provide insight into the software architecture. The operating environment included a small, dedicated network running Windows NT 3.x on the file server. On the workstations, Windows for Workgroups ran on top of MS-DOS 6.1. The network architecture was thin coax 10Base2. Altogether, not the latest and greatest, but it was certainly workable.

Additionally, this dedicated system was protected by a system of user validations and menus, and no general-use software (word processor, spreadsheet, etc.) was permitted. Oh—and did I mention that, as part of their normal operations, the users would periodically pack up everything and take it into the woods or the desert and continue their everyday activities for anywhere from two to six weeks?

If you have an interest in support, you may have already seen a problem or two. Among other things, 10Base2 isn’t ideal for periodically packing up and relocating. Add the fact that your coax doesn’t have any physical protection other than its own covering, and you’ve built the foundation for continuing problems. Further compound that with a dirty environment and no environmental controls—limited protection from dust, dirt, and moisture, along with electrical power provided by generators designed to provide power for low lights and analog communications, not computers and digital communications. All of this adds up to a fertile environment for unrest in the user community.

As far as data processing and data flow were concerned, this system had three major thrusts, including:
  • Reporting on how prepared the unit was to perform wartime functions (readiness).
  • Life-cycle management (the rebuild/replacement cycle) of major aircraft components.
  • The flow of repair parts through the supply system.

This is the process that ordered the system that Jack built
If you deal with any segment of the federal government, this project may shed light on some other areas you may have wondered about.

At the time this system was begun, the federal government had in place a very restrictive contracting process for anything involving computers and computer systems, including hardware, software, and services; all requirements had to be described in minute detail, and vendors were required to deliver exactly according to specifications.

However, depending upon the scope of the project, a significant amount of time could pass between the time the need was originally identified and the time the final product was accepted by the government. Factor in the amount of time it would take for the government to complete the delivery and implement the system worldwide, and it’s likely that the world would have moved on. Although the solution the contractor delivered fulfilled the original requirements, it was no longer the answer to the users’ prayers: Their needs had changed in the length of time it took to “finalize” the requirements and deliver the “solution.”

Yes, there were hooks in place that would allow the government to change the specifications, but there were usually significant amounts of money attached to any changes, and changes would only further delay a system that was usually behind schedule already.

Notice that in this process:
  • No one from the end-user community was able to take a look at what was happening in the software development effort.
  • No one from the end-user community had a vote about how the interface looked, worked, or how it “felt.”
  • No one from the end-user community was able to provide any kind of course-correction after the contract was awarded.
  • No one addressed the possibility that the needs of more than one user community must be accommodated.

These are the people who use the result of the process that ordered the system that Jack built
In this case, there were actually two major user communities, one at each end of the data flow. One community, a higher headquarters, received information from the system. The other set of users entered data to provide information for the first set of users. Generally, that should not be a problem. However, a significant issue here was that most of one user community didn’t have any meaningful input about how the software would look, feel, operate, respond, or how business rules would be applied. The other community, since it was receiving pretty much what it wanted, didn’t care. The whole ball of wax can be summed up in just a few words: angry, disaffected users at one end and smug, complacent users at the other. And between the two user communities, there was a flow of largely inaccurate data.

So what’s the impact on Jack’s house?
What kinds of problems do we have with this system? There were actually several, only a few of which could be traced to the software development. But all are a reflection of poor user involvement:
  • The physical architecture was archaic and not very robust—very prone to fail.
  • There was no point-and-click interface, so the operating environment was cumbersome and not very friendly—100 percent keyboard entry.
  • Because the developers didn’t seem to fully understand the complete business process, the system provided inaccurate readiness information—life’s blood for an aviation unit.
  • The information that came out of the system sometimes had little resemblance to the data that went in.
  • No adequate infrastructure was available to provide support to the end user at the bottom of the food chain.
  • Nothing was in place to provide continuing training to the end users—an absolute requirement in a largely transient organization.
  • The database system was a closed architecture; the only user interface, other than the supplied application software, was an arcane query language.

The net result: a system with software that users loved to hate.

Learn from others’ mistakes
Granted, the fact that users should be involved early and often in a development project is not news. However, there is always pressure to cut corners. The project may be on an aggressive schedule, with no time for meetings with users. The project may be on a tight budget with no funding to visit users. But make the mistake of cutting these corners, and you run the risk of having results like those described above in this case. And if you cut these corners as a developer, you could put the entire project in peril.

Editor's Picks