Managing user expectations matters because people judge a new system against what they were led to expect, not against its specification. A sound system that arrives a month later than promised, or without a report everyone assumed would be there, is experienced as a failure, and users who feel let down go back to their spreadsheets. The remedy is not to lower expectations. It is to make them accurate: tell users early what is coming, what is not and when, involve them while there is still time to act on what they say, and then keep the promises you made.
This article is about the people who use a system day to day, whether they are your staff or your customers. Managing a client’s expectations of a supplier is a related subject that we cover in tips for managing customer expectations.
Why user expectations decide whether a system succeeds
The business case for a system assumes that people will use it as intended. If they do not, the saving in time or the improvement in accuracy never arrives, however good the software is.
Disappointed users rarely complain formally. They work around the system instead. An export to a spreadsheet becomes the real record, a paper form survives “just in case”, and within a year the organisation is running two processes where it meant to have one.
First impressions also last. A system that confuses people in its first week acquires a reputation that later improvements struggle to shift. The same system introduced with accurate expectations and help on hand gets the benefit of the doubt.
Where false expectations come from
Silence. If users hear nothing during a project, they fill the gap with rumour, and the rumour is usually either that the system will do everything or that it is coming for their jobs.
Enthusiasm from the sponsor. The person who won approval for the project has spent months explaining how much better things will be. Users remember the claims and not the caveats.
The old system. People expect the replacement to do everything the old one did, including the shortcuts, quirks and workarounds that nobody wrote down because nobody thought of them as features.
Prototypes. A convincing mock-up looks finished to anyone who does not build software. Shown without explanation, it sets a delivery date in people’s minds.
Dates given as facts. A target mentioned in passing is repeated as a commitment.
Consumer apps. Everyone carries a phone full of software made by very large teams. A business system built on a sensible budget will be judged, a little unfairly, against that standard of polish.
How to set expectations during the project
Start by finding out what users expect. Sit beside the people who do the work and watch a full cycle of it before the requirements are settled. You will find the unwritten features of the old system, and users will have had a first chance to be heard.
Then be specific about the first release. Publish three short lists: what the system will do on day one, what will follow later, and what is being dropped, with the reason. The first list is the same one a supplier needs in order to quote, and our software project planning worksheet has a section for it. The third list is the uncomfortable one and the most useful. People accept a missing feature far more readily when they are told in advance than when they discover it.
Much of the trouble comes from the gap between what is said and what is heard.
| What gets said | What users hear | A more accurate version |
|---|---|---|
| ”It goes live in March.” | A promise | ”We are aiming for March and will confirm the date in February, once testing is finished." |
| "It will do everything the old system does.” | Every report and shortcut will still be there | ”These twelve tasks work on day one, these three come later and these two are going. Here is why." |
| "Here is the new system.” (showing a mock-up) | It is nearly finished | ”This is a drawing to check the layout. Nothing behind it works yet." |
| "We will look at that.” | It will be done | ”It is on the list. We will tell you by Friday whether it is in this release.” |
Show working software to users as it is built, in small groups, and let them try it with their own data. Involve them in the checks that decide whether each part is finished; the importance of acceptance criteria explains how those are written. Each session corrects the system and corrects expectations at once.
Finally, give users one named person to ask. A question answered in a day prevents a week of speculation.
Go-live: the week expectations are tested
Whatever was said beforehand, opinion forms in the first few days of real use. A few things make a large difference.
- Train close to the date. Training given a month early is forgotten. Short sessions in the week before, using the real system, work better than a long one.
- Say what will be harder at first. Everyone is slower on an unfamiliar system for a week or two. Tell people so, and tell their managers, so that a temporary dip is not taken as proof that the system is worse.
- Have someone on hand. A person who can answer questions on the spot, and a developer available to fix small irritations quickly. Fixing three minor annoyances in the first week does more for confidence than any announcement.
- Publish the known issues. If something does not work yet, say so, and say when it will. Users who find a fault that was already listed conclude that the team is in control.
- Keep the old system available to look things up. Read-only access for a period removes the fear that something has been lost.
After launch: small promises, kept
Expectations continue to need attention once the system is in use. Give users a simple way to report problems and suggest changes, and reply to every item, even when the answer is no. People who never hear back stop reporting, and their frustration goes somewhere less useful.
Release improvements in small, regular batches with a few lines explaining what changed. This shows that the system is being looked after and gives a realistic sense of how quickly requests are dealt with.
Agree in advance how quickly faults will be handled and tell users what to expect. A support arrangement with stated response times lets you make promises you can keep. A statement such as “urgent faults are looked at within the working day” is better than “as soon as possible”, which each person interprets differently.
A check to make before you launch
Ask five users, not managers, these questions a fortnight before go-live:
- What do you think the new system will do for you on the first day?
- What do you think it will not do?
- When do you expect to start using it?
- Who would you ask if you were stuck?
- What are you most worried about?
Compare the answers with the plan. Every difference is an expectation that needs correcting while there is still time, and the fifth answer tells you what to cover in training. If the answers match the plan, the launch will be judged on the system itself, which is what you want. The project manager’s part in this is covered in our 10 tips for project managers.