Requirements vs Expectations

I am very familiar with the Expectation Gap as I’ve worked in IT for most of my career.

All too often, we create systems that fit the specifications; we are confident in our work; however, when we present it to the user, we see their disappointment as the reality of what we have created doesn’t live up to their 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 letdown.

Why is this? It’s because it didn’t meet your expectations. None of which are expressed in the requirements of a great cast, special effects 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 expectations are obvious, and therefore 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 our way to ask what people are expecting, as well as what their requirements are, and we may find that their 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 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 with 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′

  1. Prompt accurate meter readings
  2. Prompt accurate customer invoices
  3. Prompt payment by the customer

The sooner customers pay their invoices the more profit 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 was.

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.

If you want to learn more about creating highly engaged teams or being a better leader click the link to make an appointment to talk about how I can help.