Many problems in software development, especially in the area of development speed, arise from unstated, unrealistic expectations. One survey even found that 10 percent of all projects are canceled because of unrealistic expectations (Standish Group 1994). It is in your interest to try to set expectations explicitly so that you can bring to light any unrealistic assumptions your customers might have about the schedule or deliverables.
One kind of unrealistic expectation can arise from the schedule. Many projects have their schedules set by their customers before the requirements and resources are fully known. As I've mentioned elsewhere in this book, agreeing to unrealistic schedules creates unrealistic expectations in the minds of your customers. Working with your customers to establish realistic expectations about their schedules is a key to success.
CROSS-REFERENCE
For details on the problems associated with overly optimistic schedules, see Overly Optimistic Scheduling, Overly Optimistic Scheduling.
Making the effort to understand your customer's expectations can save a lot of friction and extra work. In 1992 I had a customer who wanted two changes made during beta testing of the Windows product I was working on. They presented both of these as "must have" changes. The first change was to add a button to a toolbar so that the user could click and insert a new output page rather than going through some menus to do the same thing. The second change was to add a "blank output" page that would allow users to drag and drop pages from their word processor, spreadsheet, charting program, or other application into this product, preferably using hot links so that when they updated the pages in the other application the changes would automatically flow into our application.
For more on managing customer expectations, see Managing Expectations (Karten 1994).
The first change was no problem. It would take about one-half day to implement and a little time to write new test scripts, but that was about it. The second change was a different story. It would have required full OLE support, which in 1992 was supposed to take about one full-time developer the entire duration of the project.
After asking a few questions, it turned out that between the two features, the customer thought that the new toolbar button was the more crucial item. Once they understood that it would take from 6 to 9 staff months to implement the blank output page, they said "No way! It's not that important. Forget about it." Since dragging and dropping was easy for them to do, they had assumed that it would be easy for us to implement—believing it to be a 1-day or 2-day change.
You've probably had experiences in which your customers misunderstand something so basic that it didn't even occur to you that it was possible to misunderstand it. Customers sometimes think that if you're done with a prototype, you must be almost done with the product itself. They wonder where the "any" key is. They put diskettes into disk drives upside down and backwards. They think that if they can see color output on their screen they should be able to get color output on their laser printer. They move their mouse to the edge of the table and don't know what to do. They think you should know all of their requirements without having to explain them to you. (These are, by the way, all real examples.)
Yet despite how it sometimes seems, customers aren't stupid; rather, it's that they just don't understand what goes into software development. That's fair, because sometimes developers don't understand their customers' business environment, and customers think we're stupid for that.
Part of our jobs as software developers is to educate our customers so that they understand software development better, which makes it possible for us to live up to their expectations. (See Figure 10-3.) When customers become educated—when they have experience with software in general, with automation in their job areas, and as participants in software projects— productivity of the entire project improves (Jones 1991).
Sometimes customer expectations make it impossible to succeed. I know of one in-house software organization that delivered three projects to an internal customer within a 3-month period. One project finished early. The customer accused the developers of sandbagging their estimates. One finished on time.
The customer accused the developers of estimating conservatively and stretching out their work to match the estimate. One finished late, and the customer accused the developers of not being committed to the project.
Creating unrealistic customer expectations about schedule, cost, or functionality for any reason—to get a controversial project approved, to get adequate funding for a project, to be the low bidder, whatever—creates a virtually insurmountable risk to any project. Software projects have a hard enough time performing to middle-of-the-road expectations. Creating inflated expectations sets up a situation in which the project will look like it's in trouble even when it's going smoothly. With inflated expectations, developers look like losers even when we do a good job. People who inflate expectations damage their credibility, and they undermine their working relationships with their customers. People who overpromise might have an easier time initially, but they will have a rougher time in the long run. Therefore, part of the developer's job is to set realistic expectations.
