A raft of project management literature has been written about ‘managing expectations’, most of which almost entirely misses the point.

Mismatched expectations come from mismatched measures of success.

To illustrate: a B2B project team had as its measures of success “on time, on budget delivery of a set of automated transactions”.

The governance committee had a slightly broader view of success — namely that the company met the associated regulatory requirements and was not embarrassed amongst its peers.

The business stakeholders were looking for a smooth transition, reduced workload and ongoing meaningful jobs.

These are three different sets of valid expectations and measures of success.

It is not that the business stakeholders’ expectations were wrong, just different. However, too many project teams would consider these measures of success as “outside of their scope”. Yet failure to think through all three sets of expectations and then manage them accordingly is a major cause of perceived project failure.

In the UK many years ago a perfectly good new payroll system had to be abandoned because the workers “expected” that the new system would remove the need for them to have to line up outside (often in the rain) to collect their pay packets. No one on the project team thought of this. This is was a “business measure of success”. When this expectation was not met they went on strike until the old system was restored.

Getting out of alignment with stakeholder expectations is easily done. For example, a Sponsor when asked what his business stakeholders would expect from his project said, “That it fits our way of doing things” — but he then promptly went into a Steering Committee meeting where he agreed to adopt the new system “vanilla”, knowing it did not fit their way of doing things. Now he had created a mismatch of expectations that had to be addressed. This isn’t always easy.

Just telling your business stakeholders, in effect, “We’ve decided to ignore your desires and expectations for an improved process that actually fits your requirements in order to reduce our technical design and development risk” is unlikely to win friends and influence people.

So the issue cannot be ignored.

If their reasonable (and unreasonable) expectations are not going to be met, then this needs to be well communicated and explained early and frequently. They might not like it but they’ll still get xyz benefits.

It is the same as, say, building a house. You may desire marble bench tops but you cannot afford them, or they may be unsuitable, or they may clash with the rest of the house, or whatever. Life is full of disappointments. You need to agree with your stakeholders on what’s important.

People want to know early what is and is not going to be delivered so that they can either adjust their expectations or make other changes to ensure the project will deliver to their expectations.

Managing expectations has to be coupled with managing support for the project. If your perceived ability (or failure) to meet expectations gets to the point where your stakeholders see little to no value in your project, then you have a real problem.

So, the challenge is to identify all three levels of expectations — project, governance team and business stakeholders, then identify any misconceptions that need to be dispelled and sustain the support for your project.

To achieve this you need to know what they value — what’s important to them and their definitions of success and failure — and then position your project in their terms. Most project communications strategies don’t achieve this, hence so many problems with ‘stakeholder management’.