Customer-oriented practices come in several categories. Here are the categories for rapid-development purposes:
Planning—Customer-oriented practices help you build customer satisfaction into your project.
Requirements analysis—Customer-oriented practices help you to understand the real requirements and avoid rework.
Design—Customer-oriented practices help you build in the flexibility needed to respond quickly to customer-generated change requests.
Construction—Customer-oriented practices help to keep the customer confident about your progress.
Each of these are discussed further in the following sections. In addition, Managing Customer Expectations discusses managing customer expectations.
For details on these practices, see Chapter 7, Chapter 7; Chapter 20, Evolutionary Delivery; Chapter 21, Evolutionary Prototyping; Chapter 36, Staged Delivery; and Chapter 37, Chapter 37.
Here are some planning practices you can use to build customer satisfaction into your project:
Select an appropriate lifecycle model. Provide your customer with steady, tangible signs of progress. Possibilities include the spiral model, evolutionary delivery, evolutionary prototyping, and staged delivery.
Identify the real customer. Sometimes the person you need to keep happy is not the person you have the most contact with. If you're building software for another group within your organization, you might spend most of your time with a contact-person from that group, but the person you might really need to keep happy is your boss. If you're working with an external customer, the customer's representative might not be the decision maker who decides whether to continue the project or cancel it. Be sure to identify the real decision maker, and keep that person happy too.
Establish an efficient method for interacting with the customer. If at all possible, insist that the customer provide a single point of contact. That person will occasionally need to get input from other people or do some consensus-building on the customer side, but there is no such thing as a rapid-development project in which you have to get the approval of six customer representatives for every decision.
Create a win-win project. Use Theory-W project management to identify the "win" conditions for all of the parties involved. Create a plan to achieve the win conditions, and then monitor the project for risks that would keep any party from becoming a winner.
Manage risks. Pay special attention to customer-related risks in your risk-management planning and risk monitoring.
Whenever you gather requirements, the challenge is to gather the real requirements. Sometimes the real requirements are in conflict with the requirements you gather; more often they are simply missing. Sometimes discovering the real requirements calls for digging beyond the surface requirements. This was the problem in Case Study: The Requirements Club: Carl did requirements analysis by the book, but he initially did not uncover the requirements for two key reports. Requirements are often stated vaguely, which creates the possibility of confusion. Customers tend to interpret requirements broadly, and developers tend to interpret them narrowly—another source of friction is born.
Customer-oriented requirements-gathering practices help you to discover more of the real requirements and to maximize your understanding of all the requirements. Obviously, the more time you spend working on the real requirements, the less time you'll spend working on extraneous requirements, and the faster you'll be able to deliver the software that your customer wants.
Figure 10-1 shows the difference between the requirements you gather with customer-oriented practices and without.
Figure 10-1. The difference between typical and customer-oriented requirements-gathering practices. Customer-oriented practices increase the proportion of real requirements you can gather.
One empirical study found that productivity was about 50 percent higher than average when customers had a "high" level of participation in specifying the requirements (Vosburgh et al. 1984). As Figure 10-2 shows, productivity was about 10 percent higher than average with a "medium" level of participation, and about 20 percent below average with a "low" level of participation.
Figure 10-2. Findings for "Client Participation in Requirements Specification" factor (Vosburgh et al. 1984). Active customer participation can produce dramatic improvements in productivity, but it is not by itself a guarantee of success.
Figure 10-2 sounds a familiar refrain. Both the top end and the average are significantly better with greater customer participation, but the low end is virtually unchanged. Customer involvement can help development speed tremendously, but it isn't sufficient by itself to improve productivity.
CROSS-REFERENCE
For details on this point, see Effect of Mistakes on a Development Schedule, Effect of Mistakes on a Development Schedule.
As important as it is to involve your customers in specifying requirements, avoid letting the customers write the requirements spec entirely. The same study that found that productivity increased with high customer participation also found that productivity was lower when customers wrote the spec. In fact, over half the specs written by customers had to be rewritten (Vosburgh et al. 1984).
Here are some practices you can use to involve your customers in requirements gathering:
Use requirements-eliciting practices that help customers figure out what they want—user interface prototyping, evolutionary prototyping, and Joint Application Development (JAD) sessions, for example.
Conduct focus groups that help you figure out what the customer wants.
Videotape customers using the software.
Conduct customer-satisfaction surveys to obtain a quantitative measurement of your relationship to your customers.
Which specific customer-oriented requirements practices you should use depends on what a "customer" is to your organization. If your customer is another group within your organization, you might use JAD sessions and evolutionary prototyping. If your customer is someone who buys shrink-wrapped software, you might use focus groups and customer-satisfaction surveys.
For tips on using videotaping to improve software usability, see Constantine on Peopleware (Constantine 1995a).
Jim McCarthy tells a story that vividly illustrates the value of finding out what customers really want (McCarthy 1995a). McCarthy was working on the development of Visual C++ version 1.0. At that time, Microsoft was getting clobbered by Borland in the C/C++ market. McCarthy's group finally conducted a survey and ran some focus groups, and they learned that the biggest challenge developers faced was not the challenge of using the more exotic features of C++ but of switching to C++ at all. So they defined the primary goal of Visual C++ 1.0 to be to make it possible for developers to use C++ without climbing an incredibly steep learning curve. Meanwhile, Borland continued its focus on expert C++ developers and added support for templates and exceptions and other hard-core C++ language features.
In support of their objective of making C++ easier to use, the Visual C++ group came up with the idea of an Applications Wizard, which is a utility that builds the shell of a C++ application automatically. The result? Visual C++ gained dozens of points of market share almost immediately upon its release.
For more on good design practices, see Design in Technical Fundamentals and Chapter 19, Chapter 19.
You might have done a perfect job of gathering requirements—but you probably didn't. Here is the most productive thing you can do during design to maintain a customer orientation:
Employ design practices that allow your customers to change their minds occasionally.
This boils down to identifying the changes you think are likely and then using as much information hiding and encapsulation as you can. Lack of design flexibility was apparently one of the weaknesses of the project described in Case Study: The Requirements Club, beginning on Further Reading. That development team created a design that couldn't accommodate two new reports without causing major trauma to the system.
If you've laid the groundwork during planning, requirements analysis, and design, by the time you get to full-scale construction your customers will be so invested in the development process that you won't have to worry about them.
Here are some customer-oriented practices that work especially well during construction:
Employ implementation practices that create readable, modifiable code, which will improve your ability to respond to customer change requests.
Use progress-monitoring practices such as mini milestones so that you can inform the customer about your progress.
Select a lifecycle model that provides the customer with steady, tangible signs of progress. This becomes especially important at implementation time because, without it, the project starts to seem as though it's dragged on for eons without really moving forward.
CROSS-REFERENCE
For details on these practices, see Tracking in Management Fundamentals and Chapter 27, Chapter 27.
An interesting aspect of choosing an incremental lifecycle model is that it allows you to deliver working software to your customers frequently. The mere act of handing a working product to your customer every week or month provides more effective communication about your progress than a traditional status report. Customers like progress more than promises, and they especially like progress that they can hold in their hands or see on their computer screens.