Too often, IT Service fails or is perceived to have failed due to unrealistic expectations. Expectations (not the financial or technical realities of service provision) are the rule against which your service will be measured. The trick is not to be passive; you have to understand them, set (or reset) them, and constantly monitor them to ensure you at least have input into, if not control of your users expectations.
True contentment depends not upon what we have; a tub was large enough for Diogenes, but a world was too little for Alexander. Charles Caleb Colton
Too high or too low, both are bad
You could deliver the most reliable, fully functional, user friendly and secure IT services ever; but if the users expectations exceeded that, you perception will still be that you failed.
Conversely, if your users expectations are so low that they never use the bulk of functionality available to them, then again, you have failed.
While for many people this sort of work seems secondary to the actual technical delivery, there’s no point putting all your effort into designing and delivering your service, if you fail to manage expectations along the way. Managing expectations is not just a PR exercise, it’s not “just spin”, it’s educating your users so that they are better able to engage with the services you’re providing to them.
So how do you approach expectations management?
The first thing to realise is that you will rarely approach a situation where there are NO expectations. People are so heavily exposed to technology throughout their lives that there will always be some level of expectation before you start. Therefore, whether you initiating a new project, reviewing an existing service, or just addressing a particular problem, first capture your users expectations. You could do this while capturing requirements, measuring their level of satisfaction with a service, or when getting the description of the problem (as all technical people know, problems often turn out to be poorly set expectations, rather than a fault with the system).
Having captured the existing expectations you should look to try and set expectations, the obvious time being when you specify the solution to meet the requirements you’ve already captured. A dry recital of the technical specifications is not enough here, you need to paint a picture of how the solution will support their business process, relating each feature to a step in the process so they can relate to it and fully understand. Too often technical IT staff send a specification to people who cannot understand it, then complain later on when they are asked to deviate from it. It’s because the users never understood the specification, because it was effectively written in a different language.
Throughout an implementation project, at completion and afterwards, you should continue to monitor your users expectations. Are they being met, or even better exceeded? Have they changed since the beginning of the project or review? Any time you see a downturn which you didn’t initiate, or a mismatch developing between their expectations and the solution, as quickly as possible address that. You can use existing mechanisms to do this, rather than increase your project overheads. Project review meetings, feedback questionnaires, or responding to specific issues as they arise are all ideal opportunities to set (or reset) expectations.
It’s not easy, which is why it’s important
If you can manage user expectations, from the beginning of any engagement with the users (project, problem or review), you greatly increase your chances of success. It won’t be easy, it may well be the most difficult part of the project if expectations are way off reality, but that makes managing them even more important, so don’t neglect this process, or be prepared for failure!