Four quadrant expectation management

Copyright IBM, 2005 http://www-106.ibm.com/developerworks/rational/library/may05/vaidya/index.html

Country/region [select] Terms of use

All of dW

Home Products Services & solutions Support & downloads My account

developerWorks > Rational >

Four quadrant expectation management

Level: Introductory Contents:
Project failure: In the eyes of the beholder

Benefits of expectation management

Kirti Vaidya Expectation model: Customer and company

Senior director, Covansys Definitions: Four quadrant expectation management

15 May 2005 Expectation quadrants

Expectation traceability

from The Rational Edge: This article defines a software project management technique called "four quadrant Applying four quadrant expectation management

expectation management" and presents an example of expectation modeling. Included are an explanation of Example: Creating an expectation model with IBM Rational RequisitePro

how to implement the technique using IBM Rational RequisitePro and a brief look at how the technique can Applying expectation management across the organization

extend to sales, contract, and general management. Conclusion

Notes

Many software projects fail. Considering all the About the author

time, money, effort, and lost opportunities Rate this article

associated with these failures, they are a

Subscriptions:
tremendous drain on an organization. Why do dW newsletters
they occur? The reasons are many: inadequate
understanding of scope, inadequate budget dW Subscription
(CDs and downloads)
and / or timeframe; chaotic development
process; inadequate tool support and / or trained The Rational Edge

resources, and so forth. Each of these reasons,

in turn, might have many causes, including failed
expectations. For example, inadequate
understanding of scope typically results when
the scope is poorly defined; this sets incorrect
expectations and invites misinterpretation. Users
expected the scope to be X, whereas the project
team thought it was Y. Sponsors expected
expenses to match X, but the project manager
spent for Y. The project board expected the project to be complete within a reasonable timeframe for X, whereas the project needed the time to complete Y. Would
the team have avoided failure if expectations had been set for Y in the first place? We will explore this question below.

Project failure: In the eyes of the beholder

When do we declare that a project has failed? The determination may be highly subjective, depending on who is in charge. If a manager's charter is to ensure that a
project delivers on all its scope, then a schedule slippage might not qualify as a failure. And it is likely that no one except a QA person would consider a project a
failure if it delivers on all its scope on time and within budget but does not meet all quality criteria.

To a large extent, people declare that a project has either succeeded or failed based on whether it met their expectations. Few projects fail in an absolute sense --
they simply fail to meet individual expectations.

What are expectations? In a software project, requirements are explicitly stated expectations that users place on the project team. Ideally, the team and the users
should interact iteratively to create and solidify requirements, but typically requirements originate as user needs or features that the project team captures in a
requirements gathering process. A budget, for example, is an expectation that sponsors place on the project manager. A timeline is an expectation the project board
places on the project manager. Other expectations are not explicitly stated. For example, developers might expect to use their same old comfortable but ineffective
development process. An IT director who secures a project by underplaying the resource and time requirements might expect the project to make him look good and
gain him a promotion. Such implicit expectations tend to shape the explicitly stated ones (just as our sub-conscious mind shapes our conscious expression). It is
important that the organizational players who might be affected by these implicit expectations try to discover them; they may actually carry more weight than the
stated expectations and must be managed to ensure project success.

Benefits of expectation management

Expectation management can benefit a project by constantly validating its management directives, including the business case, budget, schedule, and scope --
including detailed requirements. Expectation management activities should begin early. For example, in IBM® Rational Unified Process,® or RUP,® the team would
start capturing expectations at the same time it begins capturing stakeholder needs -- early in the Inception phase. The stakeholder needs would then be linked to
expectations concerning project scope, so there would be traceability. The budget and schedule would likewise be linked to corresponding expectations. Then, the
team could review and revise these expectations at regular intervals throughout the project, managing the effects of changes on dependents, such as requirements,
 Four quadrant expectation management

with tools -- in much the same fashion as the team manages requirements. To do this correctly, the project needs a part- / full-time expectation analyst throughout its
lifecycle.

This person would begin by defining formal expectation management (similar to requirements management in RUP), using tools, such as IBM® Rational®
RequisitePro.® He or she would classify explicit expectations as "stated" and implicit expectations as "perceived." These can be further classified as either "internal"
to a domain or belonging to "external" parties.

Figure 1 shows the expectations that a project team needs to fulfill, including requirements and many others. Communication flows from internal to external, and
clarity improves as an expectation goes from perceived to stated. As this figure shows, if you manage requirements alone, you take into account only external-stated
expectations and completely miss out on the other three types: external-perceived, internal-stated, and internal-perceived.

Figure 1: Expectations on a project team

Below is a detailed example that introduces an effective expectation model.

Expectation model: Customer and company

Let us imagine a company that has sold a certain software product to a customer and is interested in selling more product licenses to that same customer.

One day the customer's CEO meets the company's CEO while playing golf.

Customer CEO (to company CEO): The market is changing fast. We wish our suppliers would realign their products with these changes!

The company CEO returns to work and summons the company vice presidents of business and IT, respectively.

Company CEO (to company business VP): Our customer indicated that we need to realign our product with their needs. Why don't you work
with the customer and Jim here, our VP of IT, to make that happen?
 Four quadrant expectation management

Company CEO (to company IT VP): I think you need to revamp our IT strategy. Why don't you start an IT strategy project and work with Susan
here, our VP of business, on the objectives?

Eventually, the above communication results in a project to migrate the product to IBM® WebSphere.® As Figure 2 shows, an expectation analyst creating a model
for this project would treat the company as the domain. Each subject's expectations can be classified into a quadrant: external-stated, external-perceived, internal-
stated, or internal-perceived. For example, the customer CEO's "realign product" message is an external-perceived expectation. It comes from someone outside the
company, and it is perceived by the company CEO as an expectation. The measure of confidence, or sureness factor, for this expectation is 75 percent. By
implication, 25 percent of the expectation is open to interpretation. This percentage is a subjective call, based on how confident the expectation analyst feels that he
or she understands the expectation.

The results of expectations in the model shown in Figure 2 become elements of project planning, scoping, and management (e.g., budget and schedule in the
software development plan or features in the software requirements specification.) These elements also have associated sureness factors. For example, although
the project manager has an internal-perceived expectation that the budget will be $1.2 million, based on conversations with the VP of IT, s/he tells the expectation
analyst to stay within the internal-stated budget of $1 million that the VP puts in writing.

The system analyst advises the expectation analyst to assign the "share data" feature a sureness factor of 50 percent, based on an internal-perceived expectation
held by the customer marketing analyst. The system analyst is 75 percent sure that the marketing analyst actually wants to join the customer company, and therefore
might be promoting this feature for her future benefit. In such instances, the system analyst might decide to validate only those features whose sureness factor is at
or above a specific limit -- say 80 percent -- as firm requirements.

This example shows how important it is for the expectation analyst to consult with other team members in order to discover "hidden" expectations and accurately
estimate the sureness factors.

Figure 2: Expectation model for customer and company

Definitions: Four quadrant expectation management

 Four quadrant expectation management

Now that we have explained the basic benefits of expectation management and the elements of an expectation model, let's look more closely at the four quadrant
expectation management technique. We'll begin with a few definitions.

Expectation

Eager anticipation (ref. www.dictionary.com).

Expectation management

A formal process to continuously capture, document, and maintain the content, dependencies, and sureness of the expectations for persons participating in an
interaction, and to apply the information to make the interaction successful.

Expectation objective

The objective for an interaction that is under expectation management. For example, the interaction might be an important meeting whose objective is to convince a
CEO to release a project budget. The meeting objective is also the expectation objective, which can be used to capture corresponding expectations.

Expectation domain

A set of participants sharing a common expectation objective for the interaction under expectation management.

Expectation model

A complete description of expectations for a system that are held by interacting persons at a given time.

Expectation manager

A role that performs expectation management.

Expectation subject

A person whose expectations are under management.

Expectation object

A person or non-living object that is the focus of a subject's expectations.

Expectation result

An element in another model that traces to an expectation in the expectation model.

Sureness factor (SF)

A real number (>=0, <=1) denoting the level of sureness in an expectation or expectation result, 1 being the maximum.1

The following four definitions relate to the scope and clarity of expectations:

External expectation

An expectation that relates to an object outside the expectation domain.

Internal expectation

An expectation that relates to an object inside the expectation domain.

 Four quadrant expectation management

Stated expectation

An expectation a subject has expressed regarding an object.

Perceived expectation

An expectation perceived to be held by a subject.

Expectation quadrants
Figure 3 shows how the expectation quadrants work. The horizontal (x) axis demarcates for clarity: Expectations above the x-axis are stated; those below it are
perceived. The vertical (y) axis demarcates for scope: Expectations to the right of the y-axis are external; those to its left are internal.

Figure 3: Expectation quadrants

In an expectation model, we can represent these quadrants as shown in Figure 4.

 Four quadrant expectation management

Figure 4: A subject with expectation quadrants

Expectation traceability
In addition to classifying expectations according to the quadrants defined above, it is desirable to establish traceability for expectations. Expectations generate other
expectations, including project budgets, timelines, and requirements, as we have seen. They also generate meeting objectives, management objectives, risks, and
other results that shape much of our work and its outcomes. This "expectation chain" gives rise to the concept of expectation traceability, essentially a broader
application of requirements traceability as defined in RUP that applies beyond requirements and includes sureness factors. The clarity level for an expectation
(stated versus perceived) results in a sureness factor between 0 and 1, depending upon heuristics as well as preceding expectations -- their own sureness factors
and how they occur, whether in a sequence (AND) or all together (OR). In addition, we can assign a sureness factor to expectation results based on the sureness
factors for preceding expectations.

Decisions about sureness factor values are influenced by traceability type. We will look at two types below: AND traceability and OR traceability.

AND traceability
AND traceability is possible when an expectation (or expectation result) traces out of one other expectation, which in turn traces out of another expectation, and so
on, as shown in Figure 5.

Guidelines for calculating sureness factors (SF) are as follows:

● Stated expectations = 1.0

● Perceived expectations = >0, <1.0

● Expectation or result tracing out of the AND expectations = less than or equal to the smallest sureness factor from the AND constituents.
 Four quadrant expectation management

Figure 5: AND traceability of expectations

OR traceability
OR traceability is possible when an expectation (or expectation result) traces out of more than one other expectation, as shown in Figure 6.

Guidelines for calculating sureness factors are as follows:

● Stated expectations = 1.0

● Perceived expectations = >0, <1.0

● Expectation or result tracing out of the OR expectations = greater than or equal to the largest sureness factor from the OR constituents.

Figure 6: OR traceability of expectations

Applying four quadrant expectation management

You can practice four quadrant expectation management at various levels of rigor, based on your needs, but IBM Rational RequisitePro provides the easiest way to
practice it with a full set of parameters, including all the quadrant classifications as well as advanced traceability capabilities. The following steps are useful for a
typical software development project.

Define an objective
It is helpful to start with defining an objective for your management strategy, so that you will understand what the domain is and who the subjects are.

For example, your objective for a software project might be "to manage expectations of the customer, CEO, business, and IT teams in relation to scope, budget, and
schedule for project X. Or, if you're holding a meeting to convince a CEO to release budget for a project, the objective might be to capture expectations of the CEO
and his / her direct reports with respect to budget allocations. You might also want to capture their expectations regarding major application projects, including the
project for which you're seeking a budget.

Define domain boundaries

 Four quadrant expectation management

Once you've defined an objective, you can define domain boundaries. Defining the domain will enable you to better understand the project scope -- and whether an
expectation is external or internal. Any people who work outside of the domain boundaries should be considered external.

Next, you need to identify those who will play key roles in satisfying your objective, both within and outside the domain. These are the persons whose expectations
you want to manage.

Set up IBM Rational RequisitePro

IBM Rational RequisitePro gives you a way to maintain expectations as requirements along with their attributes; these can include all the parameters we defined for
the expectation management quadrants. In addition, you can maintain traceability, not only with other expectations, but also with features and project planning
entities.

Below are steps for setting up Rational RequisitePro for expectation management (assumes functional knowledge of the tool).

1. Create expectation as a new requirement type

Create a new requirement type called expectation with the tag EXP, and then create the attributes shown in Table 1. Note that these include the
parameters associated with our expectation management quadrants.

Table 1: Attributes for the expectation requirement type in IBM Rational RequisitePro

Attribute List type List values

Domain Single value Name of the expectation domain and names of elements outside it -- for example, company (domain) and customer (external element).

Subject Single value Names of expectation subjects (people)

Object Single value Names of expectation objects

Scope Single value Internal versus external

Clarity Single value Stated versus perceived

Sureness Factor Single value Real assigned value

2. Create Software Development Plan as a new requirement type

Create a new requirement type called Software Development Plan with the tag SDP. Then create the following attribute (in addition to others you might
need):
❍ Sureness factor: Real value

3. Add the attribute sureness factor to the type expectation and other dependent requirements

Add the attribute sureness factor (with a real assigned value) to other requirement types that could depend on expectations (e.g., stakeholder requests,
features, etc.).

4. Create a package: Expectations

Create a package named Expectations. Within this package, create a package for each subject.

5. Create expectations

Within each subject package, create expectations pertaining to the subject.

6. Create views as necessary

Create the attribute, traceability matrix, and traceability tree views as necessary. When creating traceability trees, be sure to include "traced out of" for all
requirements that depend on expectations or their dependents.

7. Create traceabilities

Create traceabilities between the requirements of type EXP (the Expectations-to-Expectations traceability matrix), and from other requirement types, such
as FEAT, SDP, and so forth, to EXP. Make sure you check "Show Indirect in View->Properties" when displaying the Expectations-to-Expectations
traceability matrix.

Capture expectations
Once you have set up IBM Rational RequisitePro to accommodate expectations, you can begin their capture. Interview each subject, discussing their expectations
around the project objective. Then, classify these expectations by quadrants and enter them into RequisitePro in appropriate packages, as we will see in an example
below. You should continuously monitor and update the expectations, including their descriptions, sureness factors, and traceabilities. You should also update any
plans affected by these changes.

Example: Creating an expectation model with IBM Rational RequisitePro

Let's return to the example we discussed above for Figures 1 and 2 to see how you can capture it on IBM Rational RequisitePro and apply expectation management.
 Four quadrant expectation management

Expectation traceability tree

Use the traceability tree in Rational RequisitePro to show how expectations trace out of other expectations. The right pane in Figure 7 shows attributes for the
expectation "Realign product."

Figure 7: Expectation traceability tree in IBM Rational RequisitePro

Expectations-to-Expectations traceability matrix

The traceability matrix in Figure 8 shows not only how expectations trace out of other expectations, but also many-to-many indirect traceabilities. For example, the
expectation: "Deadline is trade fair," raised by the company VP of business, traces directly to the expectations "Realign product" of the company CEO and "Realign
product for trade fair" of the customer VP of marketing, respectively. It also traces indirectly to the expectations "Realign product" and "Showcase at trade fair" of the
customer CEO. By digging more deeply on Rational RequisitePro, the company VP of business could find information for making important decisions on product
realignment, based on the current sureness factors of direct and indirect causes of expectations.
 Four quadrant expectation management

Figure 8: Expectations-to-Expectations traceability matrix in IBM Rational RequisitePro

Software Development Plan traceability tree

The traceability tree in Figure 9 shows how expectation results within the Software Development Plan trace out of other expectations. The right pane shows
attributes of the expectation "Max budget $1.2M."
 Four quadrant expectation management

Figure 9: Software Development Plan traceability tree in IBM Rational RequisitePro

Feature traceability tree

The traceability tree in Figure 10 shows how expectation results related to feature requirements trace out of other expectations. The right pane shows the attributes
of the expectation "Position at company 2." This expectation affects FEAT 2: Data sharing; managers should review it carefully and determine a sureness factor
before committing to the feature!

Figure 10: Feature traceability tree in IBM Rational RequisitePro

Applying expectation management across the organization

Software development projects can benefit from expectation management in many ways. First, it helps prioritize requirements, because you can trace every feature
to expectations and then tag them with a sureness factor. Then, you can set a sureness factor threshold for retaining requirements; only requirements with factors
greater than a certain value would be retained, because they stem from expectations about which the team was very confident. Requirements with sureness factors
below the threshold may not yet be mature enough or may not fall within the project scope; they should be revalidated before you confirm them.

Expectation management can also improve intra- and inter-team communication by promoting a better understanding of stakeholders' stated and unstated
expectations. It can capture hidden expectations that render useful information about a project's success criteria and risks.

Business interactions unrelated to software project management can also benefit from expectation management, as we shall see below.

Using expectation management for sales strategy

Expectation management can help sales professionals understand the organization, relationships, and motivations of a potential customer. Starting with a known
organization chart, you can generate an expectation model for key subjects to gain insight into their motivations and influence drivers. This would result in a qualified
account / opportunity sales plan.

Imagine that you wanted to sell process improvement services to a company. You could draw the organization chart in Figure 11; the emphasized lines show
reporting relationships among the CEO, vice president of IT, vice president of business, and project manager. Through earlier interactions with company officers, you
already know the following:

● The CEO definitely approved a project budget of $$$ requested by the VP of business.

● You are 80 percent sure that the project manager expects to be nominated as lead project manager by the VP of business.

● You are about 60 percent sure that the project manager is hoping to be appointed VP of IT when an imminent reorganization takes place.

Under the circumstances, if you have been talking to the VP of IT regarding a possible process improvement service offering, your strategy needs to include and
 Four quadrant expectation management

align with those of the project manager and VP of business. As Figure 11 shows, reporting structures do not necessarily mirror expectation structures.

Figure 11: Determining a sales strategy through expectation modeling

Expectation management and contract negotiation

You can also use expectation management to understand the compulsions, constraints, and weaknesses of contract negotiators, which is vital to successful
negotiations. You can use the four quadrant technique to understand each subject's needs with respect to the contract in terms of budget, time, deliverables, legal
issues, and so on.

Expectation management and multi-site projects

Expectation management can also help you meet the challenges of managing multi-site delivery teams. If you are doing offshore software development, even having
able, English-speaking teams on both sides of the globe does not guarantee that your project will run smoothly. You must understand not only stated expectations,
but also the unstated expectations of people with different cultural backgrounds. Use expectation management to understand key subjects on both your onsite and
offshore teams, and also on the customer side -- to mitigate risks related to poor communication.

Expectation management for meetings

During a typical day, most organizations run both small and large meetings, each with associated direct and indirect costs. Direct costs include participants' time and
materials. Indirect costs include those you incur later, because the meeting results did not satisfy objectives. Such costs may be much higher than direct costs.
Determining the drivers and success criteria for crucial meetings is a very important planning step for meetings. You can use four quadrant expectation management
effectively to analyze participants' expectations for the meeting, and then use this information to structure, facilitate, and conclude the meeting.

Note that, for any of the applications we have discussed, you can reduce expectation management to a quick, informal analysis if appropriate. For example, before a
 Four quadrant expectation management

meeting, it may be enough to simply draw a quick expectation model on a whiteboard in order to understand the expectations of those coming to the meeting.

Conclusion
All people have expectations that drive the way they interact, whether they are at a family gathering, attending a meeting, working on a project, managing a business,
or even leading a country. Understanding these expectations and responding to them is an art for managers; expectation management is the corresponding
discipline, and four quadrant expectation management is a technique within that discipline. It is a useful technique that applies not only to software development
projects, but also to sales planning, contract negotiations, project management, meeting management, and any other area in which human beings must collaborate
effectively to achieve a shared result.

Notes
1Based on the concept of Certainty Factors (see discussion on the expert system MYCIN: E. H. Shortliffe. Computer-Based Medical Consultations: MYCIN. Elsevier,
New York, NY, 1976).

About the author

Kirti Vaidya, a senior director at Covansys, is an expert in the implementation of IBM Rational Unified Process, or RUP. In addition to serving as a RUP implementation mentor in various industry segments, he has
created many successful business models for large corporations, using the Unified Modeling Language (UML). An active participant in a year-long RUP implementation workshop led by IBM Rational, he has also
made significant contributions to the brand's Web site. Recently he co-authored a two-part RUP Implementation Guide for publication in The Rational Edge and led sessions at two successive IBM Rational user
conferences. After starting his IT career as an analyst / programmer, Vaidya spent many years working first as a project manager and then a Project Management Office (PMO) member while living in the USA,
India, Germany, Japan, and Australia. He has been active from pre-sales to delivery in development projects ranging from Web-based solutions and enterprise integration solutions to data warehouses, portals,
and application maintenance solutions. He holds a first rank master's degree in electrical engineering and also earned a postgraduate certificate in software technology.

Rate this article

This content was helpful to me:

Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5)

Comments?

Submit feedback
developerWorks > Rational >

About IBM Privacy Contact