Wednesday, October 19, 2011

Unrealistic Expectations

You’re just getting started on the development of an exciting new product or program. The product/program definition isn’t really flushed out yet and the real magnitude of it is not understood, but everyone, including you, is energized about the prospects of what this new product/program can bring to the company. They have visions of money growing on trees! The management team says they really have to have this by a certain date in order to have the impact they would like. They ask you, as a project/program manager if this can be achieved. Optimist that you are, not knowing the product details, and making some assumptions, you indicate that you think it may be possible (see Take the Time to Think!). Congratulations! You have just set unrealistic expectations that you can be quite certain will not be met.

No one intends to set unrealistic expectations, but it happens all the time. Everyone wants new systems, products, or programs delivered yesterday, with outstanding quality, even if they don’t have a clue about the amount of work involved in delivering a quality product/program that is aligned with critical business objectives. People are pressured to estimate what it will take to develop something that is not fully (or even mostly) defined.  When that estimate is viewed as too long (which is almost always the case), they are asked to pull time out of the schedule (see The Schedule Estimate Extortion Game). Then, as the product/program definition starts to come together, additional features and functions are identified and are determined to be mandatory. It is often realized that the needed resources needed are not currently available. However, the end date (that was very broadly estimated in the first place, and then shortened by pressure applied early and continuously) is not allowed to be modified, unless it can be pulled in. Assumptions and caveats are forgotten. [What happens when you 'ass/u/me'?  You make an 'ass' of 'u' and 'me'!]. When anyone then  tries to adjust the date, they will then hear, “I didn’t set the date, you did!”, or "Don't confuse me with the facts!" (see Don't Confuse Me With the Facts!). Many other departments become dependent on that date, and when you don’t or can’t deliver, it is entirely your fault. Then it turns into 'floggings' (see Floggings Will Continue Until Morale Improves!).  

How can unrealistic expectations be avoided or at least reduced?  

First, don’t commit to an end date until you understand what the product/program really is and what will be involved in developing it. Without such an understanding you’re laying a foundation on quicksand and the probability of your estimates being worth anything are about zero. People will want firm dates (actually they’ll demand them), but let them know you can’t provide estimates until you know what it is you’re estimating. If they want it bad, they’ll get it … bad! [see If You Want It Bad, You'll Get It ... Bad!] This is often one of the most difficult tasks, because extreme pressure is often applied to give a date that others desire, but which may not be achievable.

People also need to realize that project plans are really just an attempt to define how you would like a project to proceed. In reality it is a hope of how the project should proceed, but it will change and must be managed to adapt to and accommodate change.

Once you’ve got a good product/program and project definition and plan, be certain that all of the stakeholders agree that this is what is to be delivered (see Does Everyone Really Understand?). Different stakeholders often have different expectations. Sales is thinking of how they’ll sell it; Marketing is thinking of how they’ll market it; Finance is thinking of how it will impact revenue and margins; Engineering is thinking about its features and functions, etc. Determine who will be the most pivotal person among the stakeholders, for it will be this person’s expectations that matter the most. If there are differences among the stakeholders’ expectations, then this person will be the one to settle those differences. Every stakeholder must be satisfied that what has been defined matches their expectations. If your definition doesn’t match the stakeholders’ expectations, you’ve already failed.

Now you need to manage those expectations effectively.

One key to this is knowing your capabilities; that is, understanding what you and your team can really deliver (see What Do Your Customers Really Want?). This must be part and parcel of the project plan, reflecting realities and contingencies in that plan (see Plan Based On What You Do Know, and On What You Don't!).

Another key is setting clearly defined expectations. These go beyond the product/program definition/requirements and the project plan itself. They also include defining how and how often status will be reported, how progress will be measured, what happens when priorities shift, and how issues that arise will be handled. As with goal setting, these expectations should be S.M.A.R.T. – that is Specific, Measurable, Attainable, Realistic, and Time-bound.

You must educate the stakeholders so that they can truly understand what is involved in developing the product/program. Too often, they are of the mindset that “I don’t want to understand what you have to do – just do it and don’t bore me with the details.” With a little education, they may get a better understanding of the impact of what they are asking. At the same time, you need to listen to and empathize with them. They’ve got their own concerns and business drivers that your project impacts directly. Just as you want them to understand what’s involved for you, you need to understand what’s involved for them. If both parties understand each other, it is easier to communicate effectively and work more closely together and commit to joint success.

You need to be realistic. Over the course of any project timeline there will be shifting priorities, unforeseen circumstances, and other challenges. Try to build a little sanity into your timelines and expectations you set with others. Try to under-promise and over-deliver; this works for all involved and can result in win-win outcomes.

Continuously monitor the progress of the project and manage expectations on an ongoing basis. Nothing is more damaging to reputations and business relationships than big surprises. No one wants to be blindsided, to find out at the last minute that key targets will not be met. Clearly set the status, communication, and issue reporting expectations early on, and you will have a built-in system that supports you in managing expectations.

Finally, communicate, communicate, communicate! This is key to it all. Communicate early and often, and if in doubt, communicate some more. Use a good communicator to interface with all of the stakeholders. Ideally, use a single point of contact for all project status discussions to minimize the potential for miscommunications and confusion (see What We've Got Here Is A Failure To Communicate!).

It is very difficult to build a reputation as an organization that 'can do' and that delivers on its commitments with the features that customers want and with exceptional quality. It is very easy to undermine such a reputation by failing to deliver in any of these areas. Unrealistic expectations work like a cancer, undermining the health of the organization, eroding trust, and sowing doubt (see Trust Me, I'm Not Like the Others!). Avoiding unrealistic expectations and effectively managing expectations are keys to success in any company.

Copyright 2011 Workplace Insanity, All Rights Reserved


  1. can you make a list? this is bad for skimming through

    1. To Anonymous,
      Each paragraph, after the third, is basically a new list item (with a few exceptions). Treat it that way, and I believe it will provide you with your list.

      Best Regards - Tom Dennis


Comments are welcome and encouraged!