By William Graham

Last week, in “The perils of ignoring the user,” we looked at some of the problems that can result when end users are kept out of the development process. In part to show the good things that can come of user involvement and in part to show that developers can make a difference, we’ll now look at how a small team on a large government project won the users’ trust and had a positive impact.

The system

The system was for the federal government and had three major thrusts:

  • Reporting on how prepared the unit is 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

The process, for the most part, encouraged following specifications but not necessarily solving real user problems. Further, end-user involvement was almost nonexistent. (For a more complete description of the project, see “The perils of ignoring the user.”)

The team
Approximately a year or so before this system was to be fielded at my location, my small programming team was charged to isolate and automate one part of this system’s functionality—the part dealing with readiness and status reporting.

As our first task, we identified the rules and policies governing the process. This was pretty straightforward: A service regulation provided the basic guidance on what to report and how to do the arithmetic. The next step was just as critical: Determine specifically how the users at the bottom end of the food chain implemented the business process of readiness and status reporting. The easiest way to do this—we thought—was to visit the people who do the everyday work of gathering and reporting the information.

At first glance, this didn’t seem to be too great a challenge. Just call the folks on the phone, tell them we wanted to help, and look for the red carpet when we went out to visit. Suffice it to say that some of these folks were just a little cynical. People had shown up at their doorstep before saying they were going to help. So there was a little inertia to overcome at first.

Tough going
All told, we have 12 user enclaves on our installation. Even though we didn’t get around to visit and interview all 12 sets of users initially, we did eventually make contact with and get feedback from all 12 offices. Our process wasn’t complicated:

  • Design a user interface based on forms they were already using and reports they were already producing.
  • Use the interface to implement the basic pieces of the business process—the things that weren’t open to interpretation.
  • Solicit user feedback and modify the features accordingly.

When we thought there was a “chunk” of functionality that was pretty well complete, we showed it to a couple of users and asked questions like these:

  • “What should happen when you press this button?”
  • “You think this form is confusing? What would you do to make it less confusing/more convenient/more easily understood?”
  • “What kind of report do you need to see?”
  • “What? You have the beginning and ending date, and you still need us to compute the number of days for you?”

After we’d been beaten up badly enough, we went back to our computers, plowed in the suggestions we’d received, and then repeated the process with a couple more users.

Check your ego at the door. More than once, we scrapped perfectly elegant, beautiful functions because the users didn’t want them.

Winning them over
We did something else that most of the users in this community considered to be a pretty stand-up thing. We wangled computers and honest-to-goodness, legitimate, legally licensed general-purpose software for them. And we didn’t put any restrictions on how they could use the computers. And we wired the premises so they could access the wide area network.

The computers weren’t anything fancy. Some of the users got absolutely brand-new, high-speed/low-drag mid-tower computers. For others, however, the best we could do was upgrade what they already had on hand to a faster processor and install more memory and higher-capacity hard drives. All of them received a full suite of Microsoft Office Professional, the full commercial version of PKZip, and a set of Norton Utilities. This was the first time some of them had had a computer in the office. And if this bought some degree of loyalty and enthusiasm for what we were doing, hey—I’m not a proud man—I’ll take it however I can get it.

Where are things today?
Now, some four years after we first started our little piece of software heaven, our system has migrated across the continental United States and to installations in Alaska, Hawaii, Honduras, Germany, and Bosnia. It’s being used by Army and Air Force units and by elements of the National Oceanic and Atmospheric Administration. It has spread by word of mouth, and it has been carried along when military members relocated. And it continues to evolve based on feedback from our far-flung—and mostly, pretty happy—users.

Five points to remember
So, what’s the bottom line for the developer who wants to benefit from user involvement? How do you go about it? Here are some guidelines.

  • Identify all the possible user communities and determine what their interests are.
  • Spend quality time with your users. Make sure you know what they do for a living and how they do it; informal business procedures are often not documented but are followed just as closely as the documented processes.
  • Involve your user communities early and often. Use rapid prototyping, iterative deliverables, spiral development—whatever buzzword you want to apply. Early involvement by the user will usually result in “joint ownership”—the idea that he or she “owns” a piece of the system. It’s important that the pride of ownership extend to the user community.
  • Fight for meaningful feedback. Some users may be more than willing to be led to a conclusion that’s not necessarily their own.
  • There are going to be times when your different users have different opinions, and you won’t be able to reconcile them. Consider forming a self-governing users’ group to settle intractable differences; it keeps you out of the fray and doesn’t alienate you from any of the groups.

Most developers will agree that user involvement is a good thing and that no involvement is a bad thing, but working with users can sometimes be frustrating and time-consuming. Don’t give up. The feeling you get knowing that you fielded a system that users really like is absolutely addictive.

William Graham works for defense contractor DynCorp Technical Services and is involved with software development, testing, customer support and training, technical writing, and network support.