Contents
10.1 Customers' Importance to Rapid Development
10.2 Customer-Oriented Practices
10.3 Managing Customer Expectations
Related Topics
Lifecycle planning: Chapter 7
Principled negotiation: Beating Schedule Pressure
Theory-W management: Chapter 37
A GROUP OF SOFTWARE DEVELOPERS and their customers went to a software trade show by train. Each of the customers bought a train ticket, but the developers bought only one ticket among them. The customers thought the software developers must be pretty foolish.
One of the developers said, "Here comes the conductor," and all the developers piled into the bathroom. The conductor came aboard, said, "Tickets please," and took a ticket from each customer. He then went to the bathroom, knocked on the door, and said, "Ticket please." The developers pushed the ticket under the door. The conductor took it, and the developers came out of the bathroom a few minutes later. Now the customers were the ones who felt foolish.
On the way back from the trade show, the group of customers thought they would be smarter this time, so they bought one ticket for their whole group. But this time the developers didn't buy even one ticket, and some of the customers snickered at them. After awhile, the developer lookout said, "Conductor coming!" All the developers piled into a bathroom. All the customers piled into another bathroom. Then, before the conductor came on board, one of the developers left the bathroom, knocked on the door to the customers' bathroom, and said, "Ticket please."
The moral: Not every solution invented by software developers is good for their customers (and sooner or later the customers will figure that out).
Customer orientation seems as though it might be too intangible to have much of an effect on development speed. Intangible or not, the companies that have made customer relations a top priority have made many of their development problems disappear, including the problem of slow development.
The need to pay attention to your customers becomes obvious when you realize that, in the end, your customers' perception of whether your development is slow or fast is all that matters. If customers don't like your product, they won't pay for it, and if they don't pay for it, nothing else you do matters. Even if you build the wrong product quickly, you've still built the wrong product. Managers, marketers, and senior executives care about development speed because they think that customers care about it. If you can satisfy your customers, you can satisfy your manager, your company's brass, and everyone else.
Who "the customer" is varies considerably from project to project. On some projects, the customer is the person who plunks down $200 for a shrink-wrap software package. On other projects, it's a real flesh-and-blood client who directly pays your project's development costs. On still other projects, it's another group within your organization. Regardless of who pays for the software, it's also beneficial to think of your end-users as customers. Depending on your situation, you might read "customer" as "client," "marketing group," "end-user," or "boss." In all cases, the principles of increasing development speed by improving customer relations are about the same.
This chapter identifies practices that can help to maintain good relationships and puts the practices into context. Specific customer-oriented practices are described in the "Best Practice" part of the book.
In a survey of over 8,000 projects, the Standish Group found that the number one reason that projects succeed is user involvement (Standish Group 1994). Some experts in rapid development have stated that easy access to end-users is one of three critical success factors in rapid-development projects (Millington and Stapleton 1995). Depending on your situation, you could just as easily read that as "customer involvement."
In the Standish Group Survey, the top three reasons that projects were completed late, over budget, and with less functionality than desired were a lack of user input, incomplete requirements specifications, and changing requirements and specifications. You can handle all of these problems through the use of customer-oriented practices. Similarly, you can address four of the top six reasons that projects were canceled with customer-oriented practices.
There are only two things of importance. One is the customer, and the other is the product. If you take care of customers, they come back. If you take care of product, it doesn't come back. | ||
| --Stanley Marcus (of Neiman Marcus) | ||
Here are the two main reasons that you should pay attention to customer relations on a rapid-development project:
Good relations with customers improve actual development speed. If you have a cooperative rather than antagonistic relationship and good communications with your customer, you eliminate a significant source of inefficiency and major development errors.
Good relations with customers improve perceived development speed. Much of customers' concern about development speed arises from a fear that you might not complete the project at all. If you structure your project to provide high visibility for your progress, you increase customers' confidence in you, and raw development speed becomes a lesser concern. Their attention will shift to functionality, quality, and other matters, and development speed will take its place as just one of many priorities.
The following sections describe in detail how focusing on customers improves both real and perceived development speed.
Customer involvement can be on the critical path of a custom-software project. Customers often don't understand what they need to do to support rapid development. They don't allocate time for reviews, management, monitoring progress, or considering what they are asking for. Customers sometimes don't realize that a week's delay in reviewing a key document can translate into a week's delay in delivering the product. A common problem is that customers provide several points of contact, and you can never be sure who you need to talk to get a decision on a particular issue. By focusing on customer relations early in the project, you can select customer-oriented development approaches that eliminate these inefficiencies.
One of the costliest mistakes in software development is to develop software that is ultimately rejected by the customer. You can't achieve rapid development if you have to develop the software twice. Customers don't usually reject whole software systems outright; rather, they reject parts of the software, which means that you have to redesign and reimplement those parts. The overall effect is that you deliver the system late. Avoiding such rework is a key to mastering rapid development.
CROSS-REFERENCE
For a different list of customer-related risks, see the "Customer" entry in Table 5-3, "Potential schedule risks."
Here are some ways that customers can pose risks to the schedule:
Customers don't understand what they want.
Customers won't commit to a set of written requirements.
Customers insist on new requirements after the cost and schedule have been fixed.
Communication with customers is slow.
Customers will not participate in reviews or are incapable of doing so.
Customers are technically unsophisticated.
Customers won't let people do their jobs.
Customers don't understand the software-development process.
A new customer is an unknown entity, and specific risks are unknown.
Establishing good relationships with your customers allows you to do a better job of identifying risks and monitoring them throughout the project.
When you don't get along with your customers, you spend more time managing customer relationships. That takes time, and it can be distracting. While you're thinking about the software architecture, in the back of your mind you're also thinking about how to tell your customers that the software will be 3 weeks late. Those distractions make you less efficient, and they're demotivating. It's hard to put in extra hours for customers you don't like.
Occasionally, I found myself thinking, `If it weren't for the customers, this job could be fun.' | ||
| --Naomi Karten | ||
The problem of friction with customers is endemic to the industry. For outsourced software projects (projects with real clients), the severity of friction between clients and software contractors is great enough that on average both parties consider canceling the project (Jones 1994). About 40 percent of all outsourced projects experience this level of friction, and about 65 percent of all fixed-price contracts experience it.
Friction can arise either from the developer's side or from the customer's side. From the customer's side, sources of friction for developers include demanding impossible delivery dates, demanding new requirements and refusing to pay for them, omitting clear acceptance criteria from the contract, insisting that every last trivial bug be fixed in the first release, and inadequately monitoring the contract's progress.
From the developer's side, sources of friction for customers can include promising impossible delivery dates, bidding artificially low, bidding on projects for which the developers lack necessary skills, developing products with low quality, missing delivery dates, and providing inadequate status reports.
Making partners of customers means they become more likely to understand technical constraints. You start to get rid of the "I need it all now" phenomenon, and customers begin cooperating to find realistic, mutually satisfying technical solutions.