© Best Practices in IT Leadership, Mosaic Media, Inc.
 Keeping the Customer Involved
3 Steps to Success 
 BY MARY POPPENDIECK

 One of my clients develops registration software for state agencies. State governments keep track of many things: cars, electricians, boats, planes, companies, medical professionals, even collateral on corporate loans. A state registers all these items for a fee, adds them to its database, then sells information from the database to bring in more fees. 

Within a given state, however, registration systems may differ a lot from one agency to another, but registration systems for the same thing (e.g., companies) are similar from state to state.

 So, if a system for registering companies is developed in one state, other states may want to purchase the same software. Of course, a state’s unique laws may require that the system be modified, but once a developer understands the domain and develops a successful system, it makes sense to sell their expertise to the same agency in other states. 

In the current development environment, there is increasing pressure to adapt existing solutions to other problems in similar domains. This approach assumes that by starting with a proven solution, a developer can deploy software faster to better meet customer needs. 

To adapt an application to a different environment, it’s important to understand the fundamental differences between environments and to distinguish these from cosmetic differences. Customer involvement is the key to accomplishing this dual objective. 

My client’s problem was to take existing registration software developed for an agency in one state, and adapt it for use at a similar agency in another state. To bolster the client’s chances of success, I devised a threestep process to get the new customer involved in the software revision. By following this process, the agency was able to help define the modifications needed to the existing system while validating the unique requirements of its state.

Step 1: Demonstrate the existing system at another site. If possible, have customers visit a site where an existing version of the system is in use. It’s one thing to have customers talk to vendors, but another when they see the system in action and can discuss its merits with their peers. The developer should facilitate the meeting, encouraging present customers to discuss the system’s advantages, surprises (pleasant and unpleasant) they experienced on startup, and how their workflow changed after the system was implemented.

Step 2: Perform a gap analysis based on a demonstration of the existing system. The best way to determine what changes are needed to the base system is through JAD (Joint Application Development) sessions, using the existing system to demonstrate available features. During the sessions, demonstrate and discuss each feature of the existing system in detail. The objective of these gap analysis sessions is to determine how, with minimal changes, the existing system will work in the new environment, and to determine what changes are needed.

It’s usually easy to engage customers in gap analysis sessions with demonstrations: they see what’s being proposed and visualize how the new system will work. Thus they tend to give better input on what must be customized to meet their needs. They can more easily imagine how to adapt their workflow to the new system, thus helping to identify essential and nonessential changes.

Step 3: Deliver and test in iterative steps. Deliver the application in well defined six-week iterations, changing only one section of the application at a time. Part of the delivery should be an acceptance test of the completed portion of the system. In the state registration system, our first iteration dealt with adapting the process of filing registrations to the new state. Even though the rest of the system remained unchanged, users could now input their own data into the system and see just how the registration process would work.

Iterations maintain customer involvement in two ways. While the programmers are preparing the iteration, the customer is involved in designing the acceptance test for that iteration. When the iteration is delivered, the users do a detailed evaluation of the software. To be sure, allowing users to evaluate the software at the end of an iteration means they will want changes. Discovering the critical changes early, before the whole system is developed, results in a significantly better system with a minimum of extra effort.

 Hands-on exposure pays off

In summary, the best way to engage customers in the development process is to give them handson experience from the start—during requirements gathering and at frequent intervals during development. Minimize the stacks of paper documents that require reading and signoff, and maximize customer interaction with the system itself. Just as it is difficult to decide whether clothes will fit without trying them on, it is difficult for customers to decide whether a system will fit without trying it on. In general, users enjoy trying on new systems, but abhor paperwork and signoff documents. Substituting “dressing rooms” for “catalogs” will almost certainly get and keep any customer’s attention.

MARY POPPENDIECK
© Best Practices in IT Leadership, Mosaic Media, Inc.