The Cost of Unclear Expectations

August 1, 2012

I’ve said for years that unclear expectations make folks work three times harder than if they had clear expectations.

Here’s why:

The original job has to be done. Regardless of the expectations, the initial task has to be completed.

Consensus on the intention has to be reached. In other words, the folks doing the work have to figure out for themselves what they think the expectations are. Depending on the size or scope of the project, this could take anywhere from several minutes to days, weeks, or even months. And when a whole team is involved, the level of effort, time, and cost adds up quick!

Constant troubleshooting has to be performed every step of the way. This is where the cost really multiplies. Whenever new information comes in, the team has to stop what they were doing, perform re-work, and then redirect.

And we haven’t even factored in the cost of morale lost in the process!

Wouldn’t it be easier, quicker, cheaper, and more spiritual to take the extra time to establish clear expectations upfront?

Nathan Magnuson is a leadership consultant, coach, trainer and thought leader.  Receive his ebook Trusted Leadership Advisor by subscribing to his website or   follow him on Twitter.



2 responses to The Cost of Unclear Expectations

  1. Nathan,

    Two things come to mind from your post. First, I think of “rock management.” This is where a leader tells the team, ” I am thinking of a rock, I am thinking of a rock, now go get me a rock.” The team goes out and selects a rock and brings it back to the leader. The leader looks at the rock and says, “that is not the rock I was thinking about.” As you mention, this is expensive and can be very deflating to the team that has worked diligently to deliver, only to hear they have delivered the wrong result.

    Second, when I was working in software development, it was always emphasized to spend more time on requirements definition (asking the users what do you want this “rock” to do) than on actually building the product. The reason? Changes are much cheaper to make in the requirements definition phase than after the coding or development phase are in process. The same principle applies to your post concerning project expectations.

    As leaders we need to ensure we are clear. If we don’t know what we want, we need to tell our teams that we need their help with exploration of alternatives first, and then definitively decide on the direction to go. Who knows, the team may take more pride in ownership if they are in on the idea generation phase.

    All the best.


  2. Thanks John – my favorite phase in consulting is the analyze phase where you gather all the requirements. Kind of funny how it works that as a consultant you are responsible for getting the expectations yourself instead of relying on leadership to feed them to you. Maybe there’s another lesson in that somewhere!