WCS logo

Your Source for Project Management Training

Home Page | Course Overview | Partnering with Westwind | FAQ | Testimonials | Free Project Process Charts
Some Articles we have Written | The Project Management Guide | Our Books | How to Contact Us | Our Corporate Profile

Project Management Articles

Managing Customer Requirements: Requirements vs. Expectations

As any project manager can attest, the major reason that IT projects fail is that scope changes are not properly controlled. Project management theory emphasizes the importance of the first step in scope control: properly defining it. Without a clear definition of scope, you cannot even identify scope changes, far less manage them.

This has led to a justifiable focus on the mechanisms to define scope: a list of deliverables, a clear statement of work, a requirements definition, and numerous other tools that help achieve clarity. Nevertheless, projects that do everything right in defining and managing scope are still at risk because the demand for clarity causes project planners to exclude or ignore aspects of the project where clarity is less easily achieved: the area of customer expectations.

A typical expectations problem arises when a customer, reviewing a data entry screen for the first time, frowns and says, “It looks awfully cluttered. Can’t you clean it up?” The screen may have met all of the formal requirements, but it did not meet the customer’s—probably undefined—expectation that it would be “neat,” whatever that means. In this article, we will consider the difference between requirements and expectations and how to manage each.

Scope of the Product vs. Scope of the Project

One of the confusions that infects any discussion of this type is that there are two kinds of scope, leading to two sets of requirements and expectations. The most common meaning of “scope” is the scope of the product. Frequently overlooked is the scope of the project.

The scope of the product deals with such issues as the business boundaries of a system that is being developed; the project deliverables such as code, documentation, or diagrams; business rules to be encoded; forms, screens, and reports; and any interfaces to other applications. By contrast, the scope of the project deals with the manner in which the project will be managed, and includes conformance to a methodology, status reports, communications, and project planning. If it is not understood, the project scope can be especially dangerous. One project manager had planned to produce programming specifications as narrative descriptions but discovered that the methodology required fully developed program structure diagrams—a process that took far longer than had been planned.

Requirements and Expectations of the Product

In a broad sense, every requirement is also an expectation: the customer expects that the requirement will be met. But by “expectations” we usually mean more subjective characteristics of the product such as appearance, responsiveness, ease of navigation, accuracy, robustness, forgiveness, understandable error messages, usable help facilities, and intuitive operations.

It is sometimes unclear whether a specific characteristic is a requirement or an expectation. Consider robustness as an example. A robust system is one that detects and reports errors and provides the user with options for continuing. A non-robust system crashes. Clearly customers have the right to expect their systems not to crash routinely, but, unless the stakes are extreme, it is also unreasonable to expect that they will never fail. What, then, is a reasonable measure of robustness? Total number of crashes? Crashes per user? Crashes per hundred hours of use? Crashes per hundred function points? These are all possible targets for a system, but in reality, robustness is rarely stated as a requirement. It is, instead, a subjective expectation to be measured by feel.

A working definition of the differences between requirements and expectations is that the former are objectively stated and clearly defined, while the latter are subjective, and loosely understood. It is this characteristic of fuzziness that makes managing expectations the problem it is. For example, consider appearance. While the customer may have standards for such appearance issues as web page design, to which the product is expected to conform, it is more commonplace that the design is left to the developers who, without guidance, will design something that is appealing to them. Similarly, “intuitiveness” may be defined as a characteristic in which the most likely response to a screen state from an untrained user is the correct one. But to present this as an objective is difficult and likely to lead to confusion or disputes with the customer.

Another way of looking at the difference between requirements and expectations is that the former describes what the product is, the latter, how it works.

Managing Requirements and Expectations

Managing requirements is easy to define, if not always easy to do: you manage requirements by meeting them. You ensure that all deliverables are delivered, that business rules are correctly interpreted and encoded, and that all the elements of the scope are met.

Expectations, however, are more problematic. Because they are subjective and rarely explicit, it is almost impossible to meet them. Therefore, you manage expectations by shaping them. As a project manager, one of your jobs is to ensure that the customer’s expectations are being molded as the project progresses. For example, once a screen is designed, you immediately present it to the customer for review. If you get the objection that, “It’s too cluttered,” you can now ask the customer what changes would satisfy him. Note the wording of the last sentence. By asking what changes would satisfy the customer, you are creating a tacit agreement that once those changes are put in place, there will be no further objections. This approach leads to closure more quickly than by simply asking what changes the customer wants, which carries the implication that there will be more changes to come.

What happens, however, if the customer’s suggestions are impractical or would lead to other problems? In that case, you now have the opportunity to point out the effect of the suggestion. For example, you might say, “Sure, we can clean up the screen by moving that part to a second screen, but you should understand that, in production, this will be inconvenient for your users who will now have to flip back and forth between screens. It may seem cluttered at first, but your users will quickly become used to it and will appreciate having all the data available on one screen.”

If the customer concurs, however grudgingly, you have now shaped that expectation; the customer still may not fall in love with the screen, but it will be acceptable and there will be no objections when it is time to sign off on the project. If the customer does not concur and insists that you create a second screen, you can do so—subject to change control if the scope definition was clear—and if the inconvenience in switching back and forth becomes an issue later in the project, you have documentation supporting the rationale for that design decision.

Your best tool in managing expectations is disclosure: keeping the customer involved throughout the project. You need to make available screen shots, design documents, report layouts, performance results, and any other characteristic as soon as they are available.

However, there is a potential problem. While this advice may appear reasonable, be warned that you will probably meet resistance from your project team. Most developers prefer to keep their work under wraps until it is delivered. This is simple self-preservation; they do not want to be subject to requests to make changes when they are in the midst of development. They also do not want to be inundated with e-mails and telephone calls complaining that some function, which is not yet fully developed, does not work properly. To forestall this problem, you need to inform the customer that you are delivering an interim result that is a work in progress, that it may not work as required at this stage, and that all comments must be delivered to you, not to any of the team members. In this way, you insulate the team from the customer’s unwarranted concerns while uncovering the warranted ones.

Requirements and Expectations of the Project

The scope of the project encompasses the manner in which it is managed and includes items such as the schedule, the budget, and communications. It is common to speak of the customer’s expectations with regard to schedule and budget, but if the criterion of a requirement is its ability to be objectively defined, then meeting the schedule and the budget are not expectations, they are requirements. (If the project is being delivered at a fixed or ceiling price, customers may be less concerned with the budget than they would be for a time and materials project, but as a project manager, you can be sure that somebody will be watching to ensure that the budget is not exceeded.)

You should also deal with communications as an objective requirement. At the start of a project, one of your first actions should be to ask the customer how often he or she would like to see a status report. Some customers are satisfied with monthly status, while others want to know progress weekly. This is not a matter of your company’s internal standards for status reporting. If your customer asks for weekly status reports and your standards are monthly, your preferred response to the customer is not, “Sorry, we only do status reports monthly.” Deliver whatever the customer requests that is within reason.

It is also a good idea after you deliver the first status report to meet with the customer and ask if it is adequate, if there is material on it that is not important, or if there is anything else that should be added. In this way, you are treating status reporting as a requirement: defining it clearly at the start of the project, and fulfilling that requirement as the project progresses. As a general rule, if the customer ever calls to ask how things are going, regard that call as evidence of a breakdown in communications.

How do you handle the situation where the schedule or budget will slip? The ineffective way is to wait until the end and hope that the customer does not notice. However, recall that requirements are met and expectations are shaped. Since you cannot meet the requirements, you must now modify the expectations. The key to this is early gradualism. You do not want to wait until the project is nearly over and you discover that you will be two months late. That will not please the customer who, up until now, has been operating under the illusion that everything was on track. Instead, you need to warn the customer as soon as possible that, “We’ve hit a bit of a glitch and we are assessing what effect there will be on the project.” This alerts the customer that there is a problem, even though it is not quantified. You can also say something like, “The repeat function is complex and is causing us some problems. I’d like to suggest that we defer it until after the project. We will deliver it, but not with the first phase. Is that OK?” If the customer concurs, you have just established that the project can be delivered in phases and have opened the door to moving other areas of functionality into the “second phase.” Then, as the project progresses, you can begin to provide more specifics such as a revised delivery date.

Of course, these tactics assume that you and your team are doing everything within your power to meet the original schedule and budget, but that it won’t happen. Your job in this case is to alert the customer so that any plans or actions that assume the project is complete, such as the announcement of a new web site, can be deferred to fit within the revised schedule.


For the most part, customers are reasonable and understand the uncertainties in any IT project. If they feel abandoned or left out of the process, they will react with anger or dissatisfaction to any departure from their conceptions of the ideal project. Treat them as participants, to be consulted and informed, and they will understand and accept even substantial deviations from their original expectations. By recruiting them into the process, you are trying to get them to regard the project, with all its lumps, as partly theirs. Few people criticize their own work.


Back to Articles | Return to top | Return to Home Page