As someone who has spent the majority of his career in IT, the Expectation Gap is something I have become very familiar with.
All too often we build systems which meet the requirements; we believe we have done a good job; but when we hand it over to the user we can see the disappointment as the reality of what we have developed hasn’t met his expectations.
This is the Expectation Gap.
It’s like when you go to see a new movie it has a great cast, great special effects, and it’s a great story, all of the ingredients that you would have specified, but unfortunately the finished product is a let down.
Why is this, it’s because it didn’t meet your expectations. None of which are expressed in the requirements of great cast, special effect and story.
What you were expecting was to make an emotional connection, to have characters you care about, to have your emotions stirred and to come out of the cinema feeling good.
More often than not, we express our requirements, but not our expectations. This is where the Expectation Gap is created.
How can someone meet our expectations, if we never communicate them.
We may feel that our expectation are obvious, and therefor don’t need to be stated, but by not sharing them we are opening ourselves to disappointment.
Focusing on expectations, as well as requirements, will lead us to significantly higher customer satisfaction.
We should go out of way to ask what people are expecting, as well as what their requirements are, and we may find that they requirements and expectations are not aligned.
Back in the 90’s I worked on utilities billing system, when we developed the first phase we had a specification document that was over 500 pages, it was incredibly detailed, but when it was delivered, it didn’t really meet expectations, it worked fine, but it wasn’t as good as it could have been.
When we started the design of of phase 2, I had a meeting with the billing manager, and told him we wanted to gather the requirements and would it be possible to organise a meeting with him.
He said ‘we can do this right now‘, I was surprised and said ‘this is going to take quite a bit of time and we will probably need over a dozen sessions, not only with you, but also your staff’.
The manager then went on to tell me, ‘no it won’t, my expectations of the system are very simple, I just have 3′
The sooner customers pay their invoices the more profits we will make.
This seemed so simple and obvious. I went back and checked the requirements for phase one, and nowhere were these requirements/expectations stated so clearly, or even hinted at. For sure the requirements talked about invoices, but they were much more focused on the content rather than promptness.
Looking at the design of the system we had built, we had not built it taking these things into account. To be fair these should have been obvious, but given that they were never clearly articulated they had been missed.
As we started phase 2, we put posters up in the office to remind everyone what the customer expectation were.
As we executed the project, for every task we asked ourselves does this lead to prompt accurate meter readings and invoices, and if it didn’t we challenged it.
This led to many changes in design, all of which were readily accepted by the customer, as we could show how they would help meet their expectations.
When the system was finally delivered, although it wasn’t perfect, it had met the expectations and customer satisfaction was much higher.
We had managed to close the Expectations Gap.
If you want to close this gap, then you need to ask what the expectations are, you need to embed this into your development processes.
Gordon Tredgold
GET THE COMPLIMENTARY E-BOOK
