At some point in every IT professional's career, he realizes that the secret to having happy customers is not fulfilling their every wish and desire but keeping their expectations reasonable.

Low expectations are the secret to satisfaction, if not happiness.

You can deliver a great product, exactly to specifications, and still have an unhappy client. You can deliver one that's late, pared down, even over budget and still have a happy client

For many of us, this epiphany is accompanied by a harking back to the original Star Trek series, in which Scotty, the ship's chief engineer, constantly underpromises and overdelivers. In every engineering crisis, he seemed to declare some deliverable impossible because of the constraints of time, resources or physics, only to deliver it immediately following the intervening commercials.

Although Scotty was great at managing expectations about the deliverables of his work, I don't remember him managing expectations more broadly.

And so it is with us in IT. Our insights into the importance of managing expectations rarely seem to develop beyond that first realization. We seldom think past that to consider other expectations we should be managing and how to do so.

To manage expectations effectively, you need to pay attention to these four issues:

• Product

• Process

• Roles

• Relationships

Product. Whenever I hear people talking about managing expectations, they are usually referring to keeping a project within scope. They talk about how to limit their customers' expectations of what a project's product will do.

But managing expectations about product goes beyond simply keeping clients informed about what features will be in and, perhaps more important, what will be out. You also need to keep them calibrated on which of their myriad of desired features will be deferred and whether and when they can expect to see them appear. Avoiding the conflict of discussing deferred features altogether is a poor choice. The false expectations raised will come back to bite you.

Process. Clients have expectations about more than the content of our work. They also need to understand the process that we will be following to deliver it. Say you were at your doctor's office and he pulled out a needle and stuck it in your arm without warning. The content of the medical care would probably be sound, but I'll bet you wouldn't be happy about how it was delivered.

This is not the same thing as keeping clients informed on the internal details of the project process. Many clients don't want to know and are not equipped to really understand the fine points of process. They need to understand how progress is measured and reported. They need to understand the timeframes and how and when to expect information to be presented to them. And it's important for them to get some sense of the risks that may threaten the project. The more they know what to expect about how the project will progress, the better they'll be able to handle the inevitable bumps in the road.

Roles. You must also manage clients' expectations on the roles that both you and they will play in a project. They need to know what your responsibilities and theirs will be. They have to have a sense of what, if any, boundaries exist around the roles. For example, they need to know if it's appropriate for them to attend internal team meetings or to contact other team members. They need to know the range and limits of their own authority and yours over the project. And they need to know how to appropriately influence the course of the project.

Relationships. Finally, you must manage their expectations about your relationship. Clients need to know what to expect from you, how frequently you will be in contact and the nature of the information that will be communicated. They need to understand the range and limits of your expertise. And they need to know what you expect from them as well. They need to be prepared for the tone of your interactions: Will they be formal, stiff and perhaps in writing, or will you be communicating through friendly, informal chats?

The reason that you must manage all these non-product dimensions of expectations is that clients are often not very good at discerning the quality of the products we deliver. They are not technical experts, so they gauge their satisfaction based on proxies — on other characteristics of their interactions with you. You can deliver a great product, exactly to specifications, and still have an unhappy client. You can deliver one that's late, pared down, even over budget and still have a happy client.

So if you want to have better client relationships, thinking more broadly about managing clients' expectations is a great place to start. Once you've figured out what expectations to manage, the trick is figuring out how to do it. But that's a topic for another day.