Skip to content

Setting the Right Expectations for Projects

April 26, 2008

Expectations: A Definition and Illustration

Expectations represent a vision of some future state. They are what customers and sponsors see when they “close their eyes and imagine” a changed stated. Often, the business customer will think of this state in terms familiar to them (e.g. revenues up 15%, introduction of three new product lines in the upcoming year, or relocation of back office staff to a lower-cost suburb). IT tends to think of expectations in its own terms (e.g. a new software product, automated business process, or a new network architecture). But while these tangible, easily measurable requirements form a key part of this vision, so do the intangible effects on the customer personally, in their business role, and on their department. To illustrate this, here are some expectations that are rarely found in a business requirements document:

  • “I just need this project to come in quick and dirty so that I can say that we did it” (Project Executive Sponsor).

  • “If I bring this system in this year, I can cut the IT workforce by 40%” (Project Sponsor A).

  • “I need to be very involved in this project, and need regular briefings from the project manager” (Project Sponsor B).

  • “I don’t want to be too involved, and actually want to distance myself from some unpopular project decisions” (Project Sponsor C).

  • “If I bring in this new system to help us roll out new banking products, I’ll finally get that promotion to Vice President” (IT Manager).

  • “If we agree to participate in the data quality project team, we can influence the quality measurements the company agrees upon so that our department will get better quality audit ratings” (Business Operations Vice President).

  • “Helping our product development group roll out this new product will enhance the image of our department, and may help me transfer to a front line business unit position in a year” (Accounting Supervisor).

  • “Cooperating in this outsourcing study might save my job” (CIO).

  • “Working on this new systems project will let me acquire new IT skills” (Senior Developer).

  • “Selling off these mature, revenue-generating business lines and key assets will make the company an attractive takeover target – and could help me along to an early retirement!” (CEO).

These less tangible expectations provide the context for the more tangible requirements gathering efforts by identifying which requirements are really important to the customers that count, what degree of quality controls are required, and what deadlines really must be hit. Does understanding and meeting such kinds of expectations appear highly challenging? If so, you are beginning to appreciate the challenge of expectations management.

Expectations Management

Expectations management is the process of understanding and agreeing on the future state vision, and helping to bring about the changes to make that vision happen. Expectations management encompasses business and project management, people management, process management (which includes managing requirements definition, development, testing, implementation, etc.), risk management, budgeting, and so on. It is a discipline that heavily relies on so-called “soft skills” like communications abilities, negotiating skills, training and education expertise and, most of all, good listening.

In fact, expectations management sounds at first blush very much like customer requirements management. Requirements are also wants or needs envisioned in a future state, and are normally subject to clear, specific, and measurable description and documentation. Like requirements, expectations can be dynamic. But expectations are not always so easily expressed as hard and fast requirements and may not even be rational. Instead of managing product or service requirements, we are managing the customer and their expressed (and unexpressed) expectations. These customers — indeed, people by their very nature — are the ultimate dynamic entities, and their expectations of a project deliverable may change with such factors as shifting organizational politics and corporate structure, individual goals, changing business needs, new regulatory pressures, and many other things that may not always be easily expressed as a requirement.

There is another way to understand this difference. Requirements management often amounts to requirements engineering. Expectations management, on the other hand, takes a softer, people-oriented (rather than engineer’s) approach to succeed. It is possible to satisfy each documented requirement in a project yet fail to fully understand and satisfy expectations. Success in managing expectations may not even involve achieving project results, but may be brought about by how the project process unfolds. Also in contrast to requirements management, we don’t merely ask customers what they want and need, but also educate them as to what is possible given the inevitable tradeoffs between schedule, requirements scope, cost, and quality.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: