Customer Shadowing

CustomerShadowing is a technique which was utilized in gathering requirements from customers of the VcapsProject. This process though simple, is quite powerful, and provided useful insight into business knowledge and functionality. The basic principle in CustomerShadowing is to observe the customers as they work without interfering in their work process. Some guidelines were established to minimize the distractions that observing can cause, and to enhance the ability of the observer to gather information.

CustomerShadowing Guidelines

Shadower Responsibilities

Explain to the customer the questions needing resolution. (see Questions to be Answered)
Ask probing questions about why certain tasks are being done. Make sure, however, the customer understands that their process is not being questioned but rather, understanding the underlying reasons behind their work processes is necessary to obtain a thorough understanding.
Explain to the customer that they may stop the CustomerShadowing process at any time if they feel it is interfering with their work.
Explain to the customer to think aloud while they are undertaking a task.
Inform the customer that the shadower is present only to observe their processes and will refrain from explaining how the current system does (or does not) work and future solutions to any problems. In other words, promises or speculation will not be given during this exercise.

Documentation and Feedback

Feedback a summary of notes to the shadowed customer, as soon as possible, for review and any clarification.
Compile team notes at regular intervals to draw out commonalties between different customers.
Review findings with entire shadowed group every other week.

Questions to be Answered

What problems (in business terms) are customers trying to solve?
What inputs are needed to derive and answer?
What output information is desired?
How does this task fit into their overall process?
Is there a specific order they use to solve a given task?
What tasks must "always" take place?

Benefits

While observing the customers, several benefits clearly became evident.

Business processes that were being supported (or in many cases not being supported) were discovered. Actual business functionality was often gleaned from the process of CustomerShadowing.
It was discovered that the VCAPS System was defining the Customer's Business Process, instead of the Customer's Business Process defining the System. The Sales to IBOM UCC mapping is an example of this. System users only need to do the mapping because of the way the object model was constructed in the VCAPS System. This is a constraint imposed by the old system, not a requirement
Users were spending a high percentage of their time massaging data into a format the system required instead of the system providing functionality for them.
User interface standards are not enforced across the system. This includes the actual design (look and feel) of windows, the use of common components across windows, and common models to implement the behavior. Observers quickly came to the conclusion that since these standards were not enforced, users had a very hard time trying to accomplish their tasks. They would typically spend hours, or even days, relearning how to perform tasks that they executed only once per quarter. A consistent interface and an accurate set of desk procedures were lacking.

So would this be a case where ... "The Shadow Knows!" :-)

I am confused by the apparent contradiction in the philosophy and action given at the top of this page.

The basic principle in CustomerShadowing is to observe the customers as they work without interfering in their work process.

is followed by

Ask probing questions about why certain tasks are being done.

I can't see how to do both. This isn't to say that asking probing questions isn't good... it is to say that I can't see how to not interfere and also ask probing questions. Help? --AlistairCockburn

This only makes sense if you understand the VcapsProject culture. At the time it was common when a customer asked a question or a user submitted a bug for some jangster to launch in to a searing tirade about how the system was not being used properly. Not interfering means patiently watching a user inventing new ways to use the system without criticism. You ask probing questions to discover the root inadequacy that is causing the system to be used in such unforeseen ways. --DonWells

There's one other thing to remember about this process. The customers have to agree to be shadowed for certain period of time. It's not like we just showed up at their office and plopped down next to them and said, "Oh, don't mind me, but I'm gonna watch you for a few hours." We had to get agreement not only from the shodowees but from their management as well. We went through a couple short meetings to explain the process and what we hoped to get out of it. The guidelines were there to help illustrate that we would try to be as invisible as possible, but at times, we would need to ask some questions to get to the heart of what our customers were trying to accomplish. They understood that there could be some interruptions before we started the shadowing. That's why we put in the very next bullet point (after "Ask probing questions…") that states, "Explain to the customer that they may stop the CustomerShadowing process at any time if they feel it is interfering with their work." Maybe we should have said "excessively interfering", but our customers understood what we meant.

Like anything else, this is a give and take process between yourself and your customer. Both have to be willing to exchange a little bit of productivity in the short term (developer not developing, customer not working as fast as possible) for the betterment of the end result of the project. The big benefit of CustomerShadowing is to watch how someone actually uses the tools at their disposal to reach a certain goal. It gives the shadower a clearer picture of the problems that need to be solved on the business side. --TomKubit