Setting Expectations

When providing services, the golden rules of success are:

1. Understand your consumer’s expectations
2. Meet or exceed your consumer’s expectations

There are a few questions to ask yourself while defining expectations:

• What are you doing?
• When will it be done?
• How much will it cost?

A gap between your understanding and your consumer’s understanding in any one of those facets will result in failure. Also, expectation is a shared asset… you need to work with your consumer to come to a common understanding. We refer to the art of negotiating to this common understanding as “setting expectations”.

You may (should?) be wondering why you are “setting” the expectations for someone else. They should tell you what they expect, right? Don’t trust that they will. If the expectations are not clear, you are the one at enormous risk of failing; ergo, we believe you should grab that task! We drill into our team members’ heads that every second they are engaged on a project where they have not established expectations with their consumer, both they and Systems Flow are at risk of failure.

A common response from someone new to formal expectation setting is “I just got started on this project, I don’t know yet what expectation to set.” Not true, Padawan! Set an expectation for the expectation. This can take the form of a quick email identifying the cost and target date to review the project and identify your first deliverable – a proposed plan of attack.

We have some guidelines for our team:

1. Set expectations immediately upon engagement (if not sooner!).
2. Expectations should be based on formal artifacts (“deliverables”).
3. You own your destiny. You do not have to allow a consumer to force unrealistic expectations upon you.
4. If something comes up unexpectedly during an engagement that will impact a deliverable of yours, you must alert your consumer immediately. Do not wait until the deliverable is missed.
5. Provide samples of deliverables to the consumer. Otherwise the expectation is still a bit vague…
6. You are responsible for meeting (or exceeding) the expectations you set.

#4 is critical. There are many valid reasons why a deliverable date might be at risk – shift in project scope, unanticipated time supporting other projects. scope creep in the work you are performing for the project. All of them sound like excuses when communicated after the deliverable date has been missed!

Comments