Managing Client Expectations

Managing Client Expectations

Too many projects have been sunk by failing to deliver what the client expected, even when the results were defined. There is a difference between definition and expectation. If you produce an inquiry screen that displays a customer's name, address, phone number, and credit status, you will have met the definition. However, if the client says, "I didn't know it would look that cluttered," or "It takes too long," or "It's awkward to get to this screen,'' then you have not managed the client's expectations.

Problems in expectations are the direct result of two errors: failing to build client expectations at the start of the project and neglecting the client while the work is in progress. If you did not take the time to uncover the client's vision for this system, you will now face the unpleasant experience of having the client disapprove what you have worked so hard to produce.

Neglecting the client means that not only have you worked on the system in isolation, you have forgone any opportunity to manage expectations. Managing expectations is not simply finding out what the client wants; it is guiding the client to expect what you can provide. The first rule of managing expectations is "no surprises." Whenever the client sees anythinga report, a screen, a document, or a programit will be familiar; the client will have seen its precursor before.

This means that as a deliverable is in progress, you will show it to the client as it evolves. If the deliverable is a document, you will review the table of contents first, then each section as it is developed. If it is a screen, you will first demonstrate a mockup. Then, as the screen is developed, you will show it to the client at various stages. The client should be aware of how your menus work and should have seen some examples of navigation before you deliver a final result. In other words, the client is intimately involved with the deliverables as you produce them.

However, in all of this "show and tell," remember that your purpose is to manage expectations. Your client will make valuable comments, which you will undoubtedly want to incorporate into the deliverable, but at the same time, you are establishing what your project will provide. If the client is concerned that navigation is awkward when it is as simple as the application will permit, you can simulate operations for the most frequently performed transactions, or demonstrate that experienced users will not be impeded. By demonstrating your menu paths in advance, you have uncovered the client's expectations and, you hope, adjusted them.

Even when you cannot change a client's expectations, you now understand where the problems will lie, and you will be able to act. Over the course of the project, you may find that your client's expectations change as familiarity with the system increases. By uncovering expectations sooner, you are able to take action both to modify them and to meet them.

Make It the Client's System

If you successfully manage the client's expectations, the system you deliver will be the client's, not yours. When you deliver your system, you deliver something that may be acceptable and that probably works, but that is not exactly right. When you deliver the client's system, you also deliver a sense of ownership, an attitude that the system belongs to the client and is right for the application. Managing expectations converts mere acceptance into enthusiasm.

Managing the Right Client

Most problems in acceptance come about because those who accept the system are seeing it for the first time. Typically, they will succumb to two temptations: to attack what is new and to justify their involvement by criticizing what they see.

One of the precepts of sales is "Sell to the decision maker." There is no point in trying to sell a product to someone who does not have the authority to buy. Similarly, you must manage the expectations of the decision makers. You do not want to discover that the person you have been working with and whose expectations you have shaped is not the person responsible for accepting the system. If the client's sociology denies you access to the decision maker, you had better prepare for an unpleasant reaction at acceptance time. To the extent possible, you should involve the people who will be responsible for approving the system and authorizing its implementation.

User Acceptance

For most projects, user acceptance is the ultimate test, the trial lurking like a beast preparing to shred the noble efforts of the team. User acceptance is a barrier that you know will be difficult to surmount. However, it will be even harder if you do not define what acceptance is.

User acceptance is the process of demonstrating to the user that the criteria established for acceptance have been met.

Clearly, if the criteria for project acceptance were not defined during the project, it is not possible to demonstrate that they have been met. Acceptance then becomes a matter of negotiating the criteria and hoping that the outcome of the negotiation does not depart too far from what the project has already produced. On the other hand, if the acceptance criteria have been defined and agreed to, acceptance becomes little more than a formality.

The technical purpose of user acceptance is to transfer the system to the user and to get paid. However, user acceptance can be an opportunity to create enthusiasm. Why settle for mere acceptance when you can generate excitement? Smooth user acceptance requires that you insist on one of two options:

1. The system will be formally accepted by the client project manager and user team leaders who have been directly involved in the development of the system.

2. The system will be formally accepted by nonparticipating client representatives who will be bound by the recommendations of the client project manager and user team leaders who have been directly involved in the development of the system.

In both these options, the decision to accept the system is made by those who were involved in its development. Nothing else is acceptable. If you cannot get the client to agree to one of these options, treat user acceptance as an activity rather than a milestone. Decompose it into initial user demonstrations, substantial time for modifications, and final acceptance.

What If?

The Client Team Changes During The Project, And The New Team Has Different Expectations.

When there is a significant change in the members of the client team, particularly senior ones, you will probably be faced with a new set of expectations, with the result that you may have to redirect your project. The cost and schedule will probably be affected.

Actions

Determine why the team is changing. If it is because of internal transfers or promotions within the client organization, your job will be easier than if the original team members were replaced because of dissatisfaction with the conduct of the project.

As soon as possible, meet with the new client team members and orient them to the project as if they were new members of your team.

Present the project approach and the effort to date as positive achievements and steps toward attaining the benefits that the client expects.

If the new team insists on making changes, point out that they will be treated as scope changes, with impacts on the budget and schedule.

The Client Changes Expectations During The Project.

Assuming that the client's expectations had been clear, their changing is a sign of dissatisfaction with the project. The client either does not like what has been delivered or is not happy with the manner in which it has been delivered. In either case, the project is in jeopardy and you are professionally at risk.

Actions

Initiate a heart-to-heart talk with the client, starting with a statement like, "You don't seem pleased with the way the project is going. Is there something wrong?" Then listen for the response (see the description of neutral listening in "Listening" in Chapter 6). If you can identify some problems and agree on an action plan to resolve them, the issue will probably disappear.

Escalate to your management. Let them know that the client seems unsatisfied and that some higher-level intervention is needed.

The Client's Expectations Seem to Shift From Day to Day.

When you reach acceptance, you risk the client's finding fault with much of the system, even components that were reviewed without comment. Final acceptance will be difficult and time-consuming.

Actions

Notify your management that you have a potential issue in acceptance.

Keep a log of the changes in client expectations. Make sure that you date each entry.

When the client changes an expectation, confront him or her. Say something like, "On August 17, we reviewed this screen, and we agreed that it was acceptable. What has happened to change that?"