Some software development approaches have as a central tenet the premise that every project needs a full-time, on-site customer who sits with the developers. The rationale is sound. Only knowledgeable and empowered customer representatives can answer questions and flesh out high-level requirements in appropriate detail. Failing to get timely answers or clarification holds up development and forces the developers to make their best guess. The right customers also can provide quick feedback on proposed user interface displays, clarify points of confusion, and resolve conflicting requirements and priorities.
I fully endorse the premise of intimate, ongoing engagement of appropriate customer representatives on software projects, as well as the need to get input from a wide variety of other stakeholders. My concern about the phrase on-site customer is simply that it is singular. It suggests that a single individual is available who has sufficient knowledge, expertise, and authority to make requirements decisions on behalf of the entire user community. Even if you could find one such highly qualified representative, other demands likely will compete for his time unless he and his management make participating in the project a priority.
User Classes and Product Champions
In reality, most products have multiple—often many—distinct user classes, groups of users who have largely different needs. Certain groups—the favored user classes—will be more important than others to the business success of the project. It’s unlikely that any one person will be able to represent the needs of all the user classes adequately and to balance their interests appropriately when making decisions and reconciling conflicts.
A more realistic approach is to enlist a small number of product champions to serve as key user representatives. More than twenty-five years ago, my small software group at Kodak adopted the product champion approach with great success. In this model, the primary communications bridge across which user requirements flow involves one or more BAs working with one or more product champions, as Figure 1 illustrates.
Figure 1. The requirements communication pipeline connects product champions and business analysts.
As a first approximation, look for one product champion per major user class. Some individuals might be members of multiple user classes and could present the needs of all those groups. In other situations, a large user class might be divided logically into sub-user classes. I encountered this situation on a project building an information system to track chemical usage. Our largest user class consisted of several hundred chemists. We found an experienced chemist, Don, who could supply most of the requirements for the common needs of these users. Don served as the product champion, the primary interface between the chemists and the BA (me, a former organic chemist myself). Don communicated with his colleagues to identify requirements, propose suggestions, and resolve conflicting inputs.
During this project, though, we learned that certain small groups of chemists throughout the company had some specialized needs. Therefore, we lined up several other chemists to work with Don to ensure thorough coverage of the community’s requirements. If this group of representative chemists couldn’t all agree on some issue, Don made the call. Someone has to make these kinds of decisions, and it works best when the decision-maker is a knowledgeable and respected user representative.
On this same project, we had three other important but much smaller user classes. We found a product champion to represent each of these other groups. The four product champions together served as our “voice of the customer.” Ideally, your champions will be co-located with the analysts and developers for the duration of the project so they can quickly answer questions and supply the myriad details that written requirements specifications lack (or get wrong). This is the intent of the on-site customer principle. In practice, none of our product champions ever spent more than about one-quarter of their time working on our projects. Nor were they co-located with the analysts and developers, although they were accessible enough to provide quick feedback when necessary.
I’ve spoken to many BAs, developers, and users who have tried the product champion model. They invariably report that the approach was highly successful, provided four conditions are met:
-
The right individuals assume the product champion role.
-
Each champion understands and signs up for his responsibilities. (See Chapter 6 of my book Software Requirements, 2nd Edition for some typical product champion responsibilities.)
-
Each champion has the time available to do the job.
-
Each champion has the authority to make binding decisions at the user requirements level.
Simply having an on-site customer doesn’t guarantee that he’ll provide the expected contribution. My colleague Julia learned this the hard way. Julia’s original product champion was co-located with the developers yet failed to interact with them in the expected way. As Julia put it, “He sat in our midst and still managed to avoid us all.” This negated the value of having a customer on site. Julia acquired a new champion who interacted much more effectively with the developers and strongly influenced the project’s direction. The moral of the story is that it’s essential for your customer representatives to commit to making the project contributions you need from them.
Surrogate Users
The ideal product champion is an actual member of the user class he represents. This isn’t always possible, particularly when building commercial products for a faceless market. You might need to use surrogates in place of real user representatives. Perhaps a product manager can fill this role or a local subject matter expert can speak for the users, thereby acting as the product champion. Try to avoid the following user surrogates, though:
Former members of the user class. When your product champions are former—not current—users, you have to consider whether a significant disconnect has grown over time between their perceptions and the actual user needs. Their understanding of user needs and how current users would employ the system could be obsolete. However, they might be able to do a good job if they’re still in touch with current users or if the application domain changes slowly.
Managers of the real users. Managers sometimes are leery about delegating decision-making authority to ordinary users. Often, they’re also reluctant to have valuable employees spend a lot of time working with the software team. I’ve heard managers say, “I did that job myself for ten years. I can tell you everything you need to know. You don’t need to talk to any users.” There are two problems with this rationale. First, those managers probably aren’t current members of the user class. Second, busy managers rarely have the time to devote to a serious requirements development effort. It’s better to have managers provide input to the business requirements (why we are undertaking the project, business objectives) and ask them to identify some current members of the user class to contribute to the user requirements (use cases, tasks to accomplish).
Software developers who think they can speak for the users. Rarely, this situation will work. More commonly, even developers with considerable domain experience will find that actual users of the new product will bring a different, and more reliable, perspective. Of course, if the product is intended for use by software developers, your own developers might be perfectly reasonable user representatives.
Now Hear This
Your stakeholders might hesitate to invest the considerable time it takes to have knowledgeable users work with BAs. Here’s how I see it. You’re going to get the customer input eventually. It’s a lot less painful to get it early on, as well as on an ongoing basis during development. The alternative is to wait until you deliver the system, hear complaints about all the things the BA and developers did wrong, and then spend a lot of time, money, and goodwill fixing those problems.
I encounter many teams that would love to have more customer involvement but which are deliberately blocked from talking to actual users. This is a special concern when the customer is not himself an end user, yet prevents the developers from interacting directly with users. In other cases, no one is willing to spend the time to work with the development team on requirements, prototype evaluations, or other opportunities for engagement. If you can’t get your customers or suitable surrogates to invest time in making sure the product meets their needs, I seriously question their commitment to project success.
In an ideal world, a single, full-time, expert user would indeed be sitting within view—“on sight”—of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations. More realistically, the project manager and business analyst should assemble a small group of product champions who can properly interpret and balance the needs of the user classes they represent. Then build a close, collaborative relationship with those product champions so that you can get the VOC—the voice of the customer—as close as possible to the EOD—the ear of the developer.
Author: Karl Wiegers
Karl Wiegers is Principal Consultant at Process Impact. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition (Microsoft Press, 2013), co-authored with Joy Beatty.