Originally posted on allPM.com
Purpose The key to managing expectations is to first acknowledge that people always expect something and then to consciously and explicitly find out what they expect. The most effective agreements include provisions for change. The wise person recognizes and prepares for the inevitability of change. Take note: quality is very hard to define and that even when all the specifications have been met to the letter expectations may not have been met. Conversely, expectations can be met even though specifications have not been fully delivered. Quality is ultimately subjective. Unrealistic expectations are a root cause of project failure.
Projects are performed for results. Of the three major project objectives – results, time and cost -- results is far and away the most critical. It is the results that the sponsor or client want within some time frame and for some cost. Success requires that the results satisfy the people who are putting up the money and resources for the project. Quality results that satisfy expectations are made possible by agreeing mutually understood relatively stable objectives, requirements and specifications.
In this article we address the need to make “quality"? objectively measurable without forgetting the need for subjective assessment. We work with the recognition of degrees of “goodness"? and the balance among results, cost and time. We discuss the critical need for quality control to make sure, before we deliver it, that what is delivered meets requirements. The purpose is to achieve success by managing expectations. Managed expectations rely on a mutually understood definition of quality, among all parties to the project followed by a process to ensure that expectations are met.
The Zen Perspective
The Zen perspective seeks balance among seemingly contradictory factors, like subjectivity and objectivity.
In the realm of quality and the management of expectations it is essential to create right balance. Life would be easy for project managers and performers if measurable, objective quality criteria were fully articulated, from the very beginning of a project. However, it appears to be that the harder we try to “manage by the numbers"? the more we are faced with the reality that complex projects and human nature get in the way.
The Zen approach councils us to enter the process with eyes wide open, test all assumptions and rely on open communications, committed to writing to establish realistic understandings among project clients, sponsors and the people who serve their needs.
Add to balance and realism precision. Precisely define what can be defined and clearly and precisely identify what cannot be defined in objective terms to set up the conditions that will lead to an optimum outcome for the project.
Remember, quality results require a quality process founded on the principles of clarity, realism, right balance and acceptance that uncertainty is the only certainty.
Terminology and the Nature of Quality
There are many terms used when referring to the complex of product, results, and quality. We will use the term results to mean the complete impact of the project. Results are the product (or event, changed process, etc.) plus the benefits and/or negative impacts the product and its use have on the world.
The product is the direct output from the project – the house, the computer system, the event, etc.
Quality is far more difficult to define. The dictionary definitions include 1) an essential property, 2) character or nature, 3) grade, degree of excellence. In the project management and quality management realms quality is commonly defined as the degree to which a result satisfies expectations and is fit for use. That is how we will use it in this article.
The trickiest part of quality is the part about satisfying expectations. Expectations are the thoughts people have about the outcome -- they are visions. In order to minimize confusion and the risk of leaving people dissatisfied, effective project managers take the time and effort to make sure that expectations are clearly known and able to be used as a base for performing the project and a means to determine if expectations are met and the project ends successfully.
Requirements and specifications are the description of the product and its characteristics. The product scope is the sum of all the features and functions of the product. It is through the clear and “formal"? description of the product in the form of requirements or specifications that we manage expectations.
Quality control is the process to make sure that project results are correct reflections of requirements. It consists of testing and reviewing.
Quality assurance is the process to make sure that the process used to deliver the results is as effective as it can be. Quality control is present focused – does the delivered product meet expectations? Quality assurance is future focused – will we deliver products to meet expectations in the most effective way?
Expectations
Unrealistic expectations are the root of all suffering. Unrealistic means having little probability of occurrence. In projects there are two classes of unrealistic expectations: one, where results are expected within time and cost constraints that are not in keeping with the nature of the results, resources and other factors. This class is addressed in the chapter on estimating.
The other class of unrealistic expectation is where some people expect that others will know what they expect without being explicitly told.There is a related issue, people who think they know what others expect without being told. A subset of these is the expectation that people will do what others expect of them.
How likely is it that a group of people performing a project will deliver what the sponsor and client want without being told? How likely is it that a client, without being informed, will expect to spend a lot of time with project performers, informing them of his expectations and validating that they understand them as he does? The answer is pretty obvious -- the likelihood is small and if it does occur, it is either by luck or the skill, knowledge and patience of the performers.
Sometimes the client thinks (expects) that the project performers know what she wants. Sometimes the performers do know. Sometimes the performers think they know but really don’t. Sometimes they don’t know and know it. In any case, clever performers will get the client to say what she expects, write it down and then validate to make sure that there is mutual understanding.
Clever clients, sponsors or managers will expect and insist upon a reasonable degree of time and effort to be spent managing expectations.
In some cases finding out what the expectations are means simply asking, listening, expressing and validating them. In other cases it means intuiting the expectations, expressing them to the client and others and then asking, listening, refining and validating.
In either case, the expectations are expressed in concrete terms, in narratives, drawings, prototypes or models. While it is better to express expectations orally than not at all, expressing them more formally is strongly recommended. Formality avoids unnecessary changes and conflicts caused by misinterpretation and memory lapses.
Defining Objectives
In projects, the foundation for satisfying expectations is defining objectives and requirements.
Objectives are high level expectations – for example the objective of a project may be to implement, within six months, a computer supported system to streamline the way orders are processed in a company so that 99% of the orders are delivered within one day for a processing cost of less than $10. The objective for the implementation is to reduce operating costs by 50% within two years and to measurably improve customer satisfaction by 80%.
Note the difference between the project objectives (deliver or implement something within time and cost constraints) and the higher order objectives that represent the reasons that drive the project objectives. These higher order objectives are often called business objectives or expected benefits. In most cases, they are expected to be realized after the project is completed.
The old paradigm of SMART objectives still works. Define objectives so that they are simple (i.e., easily understood and broken out into a set of discrete items), measurable, achievable, relevant (i.e., aligned with needs and strategies), and time bound. The smarter the objectives are, the more likely it is that there will be clarity and ease during the project and, particularly, afterward when it is time to see if the project achieved what it set out to achieve.
Defining Requirements and Specifications – Features, Functions and Behaviors
Requirements are the statements that describe the expected features, functions and behaviors of the project outcome. Specifications are generally more detailed statements of requirements. For example, a requirement might say that a sliding door with etched glass panes is required, and a specification would provide the exact measurements and perhaps other qualifications. Specifications generally result from design activities and are more detailed and precise than statements of requirements.
Levels of Detail and “Progressive Elaboration"?
The distinctions among objectives, requirements and specifications are by no means etched in stone. In some projects requirements and specifications are combined, while in other projects they are distinctly separate. Sometimes objectives are more detailed and overlap with requirements. The key point is that as the complexity of the product increases, it is increasingly necessary to describe it in levels of detail so that all parties can fully comprehend and agree that the statement is accurate and a true reflection of client expectations. The process of expressing expectations in levels of detail is progressive elaboration. Since the term progressive elaboration has a fairly high Fog Index we will not be using it much, even though it represents one of the most useful and elegant concepts in project management, knowledge management and requirements definition.
The basic idea is to start at a fairly high level of detail and get agreement regarding the understanding of what is expected at that level. Then based on the agreed upon high-level description, the product is described in greater detail, agreed upon, taken to a next level of detail, etc.
The idea is that, given the limitation of the human mind and the capacity of many people to concentrate for long on detailed information, it is very useful to present information in levels of detail so that the highest level describes the big picture and lower levels progressively describe complete “big pictures"? of each of the parts of the total big picture. This of course is done with the recognition that the details must fully describe and not contradict the big picture and that the big picture is subject to change as the details are being defined. Figure 1 is a graphic example of how a complex end result might be divided up into bite sized chunks to enable better understanding of the whole.
Figure 1. Levels of Detail
An Example
Here is an example: a client wants to divide a large loft into three distinct rooms while allowing light and air to flow throughout the space and permitting the dividers to be hidden from time to time to make the space look like it is undivided. That is the objective.
The contractor writes it down, and goes over it with the client, who says, “Yes, that’s what I want"?. That takes no more than a few minutes for each of them. It can be done in person or via email.
Next the contractor asks the client, “What did you have in mind for the dividers?"? The client says, “etched glass sliding doors"? and produces a drawing of two large panels of glass with a lovely abstract on them. They extend from floor to ceiling and wall to wall. That is the next level of detail.
The contractor takes a look at the drawing and says how beautiful it is, but quickly gets down to making sure this level of detail is in keeping with the big picture (the objectives). He asks questions and informs the client about the realities associated with the space required for “hiding"? the doors from time to time. They explore sliding door and swinging door options. The client likes the sliding option and but must now settle for the loss of the space on either side for storing the doors when they are open. Since glass isn’t particularly bendable or roll-able, the storage space issue leads to exploring dividing each side of the door to enable folding, using some other materials, etc. Finally they settle on folding doors in four panels and “attractive"? storage closets on each wall to store the open doors.
Then they turn to the client’s floor to ceiling desire and the issue of air flow. Clearly there is need for some transom or other means for ventilation. They think and discuss and come up with an acceptable idea which combines elegance, beauty and practicality. It is possible that the client could have changed the original objectives and settled for a design that did not permit airflow between the spaces, but instead ventilated each space using a duct system hidden above the ceiling. If this had happened, it would have been necessary to revise the original understanding
Before they are finished with this second level of detail, they must address framing the glass, weight and breakability issues, and the ability to get the panels into the space (elevator height limitations). Because the contractor has done this kind of project before, he knows what questions to ask.
The contractor goes off and creates some drawings with related text to describe the resulting requirements. He reviews them with the client and they agree. The results of the second level of detail have changed the client’s expectations. It has taken several hours across several days.
Next (sorry, we are still not finished) the contractor’s people take precise measurements and create a detailed specification of the exact dimensions of the doors, complete with the location of hinges between panels, hand holds for closing and opening, the storage closets and the implications of the dimensions on the utilization of the space on either side of the doors. They discover that the requirements, as they have been stated, are not realistic because the size of the glass panels make them very difficult, if not impossible, to transport. After some negotiating and redesigning they resolve that issue and revise the requirements.
Fortunately, the client was very wealthy and patient so price and time to complete were not issues (this is a made up example, don’t expect this to happen on any of your projects any time soon). Had time and price been issues, there might have been another round or two of changes to align the requirements with cost and time constraints.
What Could Have Happened?
In this example, the contractor and client cooperated effectively. They took the time to explore and negotiate. The client changed his expectations and spent the necessary time to get the definition. The contractor was patient.
Imagine what might have happened if the contractor took the original objectives and unilaterally created a workable solution. The client might have just accepted the design and just loved it, congratulating the contractor and giving him a bonus for being so clever and effective. On the other hand, the client might have reacted badly, rejecting the results because they did not satisfy his original expectations. How might your client respond or react if you took it upon yourself to deliver a workable solution that does not fully satisfy expectations? How would you, if you were the client?
“Why would the contractor do that?"? you might ask. Among the possible reasons might be that the client was unavailable to take part in a dialogue and the contractor wanted to get the job done. Another possibility is that the contractor thought that the client would understand the need for a practical solution and accept the contractor’s clever way to deliver.
Quality Characteristics
If quality is the degree to which a result satisfies expectations and is fit for use, then we can see that our example addresses only half the story. The definition of requirements sets and documents the expectations. The delivery of the results and evaluation by the client, using the documented requirements as criteria, determine if quality has been achieved.
In order to enable the evaluation of the product, requirements and specifications must include every aspect of the product that will be used in the evaluation. The requirements must address all of the quality characteristics. Quality characteristics are the aspects (behaviors, features and functions) of the product that are criteria upon which the product’s degree of quality is based.
In our example, quality characteristics would include ease of opening and closing the doors, the degree of difficulty in getting the doors into the building, the exactness of replication of the etched design, the beauty of the storage closets and the way they matched other design elements, the color of the glass, etc.
If we have a process as in the exercise, it is likely that these elements will be addressed, but to make sure, it is best to go into the requirements definition with a checklist of relevant elements rather than relying on the expertise and memory of the project performers, contractors, etc.
Subjectivity – Managing Individual Taste
The area of quality is never particularly straightforward. Subjectivity is unavoidable when there are issues like beauty, ease of use, the way different design elements match one another, look and feel, etc. are involved as criteria for accepting the product.
Subjectivity is the opposite of objectivity. A subjective view is based on individual taste and attitude. Subjective views are subject to change depending on the conditions affecting the individual. For example, the individual’s mood or her exposure to a new model that triggers ideas about the esthetic goodness of a design or product feature, can affect the degree to which a previously acceptable outcome may no longer be acceptable.
The changeability of subjective views is a problem in project work. It leads to changes in the middle of projects (e.g., change the color, make this bigger, etc.) and, worse, causes disputes at the project’s completion because expectations have changed and acceptance of the project result is not easily obtained. In the end, satisfying the client (a principle success criterion) depends upon the client’s subjective view of the outcome.
Managing subjectivity requires first acknowledging it. Once acknowledged, the subjective criteria should be stated as requirements. Time must be spent exploring the means for testing to see if the criteria are met by the results. The client must acknowledge that change to these requirements, as with all requirements, may create delays and costs for the project. The project team might design the product so as to easily adapt to changing tastes, if possible.
Do not think that just because there is a quantified set of specific acceptance criteria – size, weight, speed, etc. – that the client will be satisfied just because they have been achieved.
For example, in a project to implement a customer service call center, success criteria included response time, number of return calls on the same issue, number of minutes on hold waiting for service as well as customer satisfaction. The project result was measured over the first six months of operation and all metrics were found to be well within acceptance parameters. Yet, customer satisfaction was lower than desired. Upon exploring the cause of the customer satisfaction shortfall, it was discovered that customers disliked the tone of voice and demeanor of the greeting and directions announcement that preceded contact with a live representative. Some complained about the insipid music played during wait periods (others thought the music was fine).
In retrospect the project team that created the call center realized that they did not consider the esthetics of the voice and music components. Had they considered these, they would have established a requirement and acceptance criterion that these features be attractive to a large proportion of callers. They would have tested to make sure that those criteria had been achieved.
Beyond Words: Drawings, Prototypes and Models
“I’ll know what I want when I see it."?
How often has that been a cause of frustration for project managers? Well, it need not be. When it comes to setting requirements, particularly when the product is a complex one and there are esthetic and behavioral issues, it is often impossible to describe the product in language. That is why the client in our doors example started with a picture and the contractor communicated through drawings. Graphical representations – drawings, blueprints, and three dimensional computer generated graphics – are wonderful means for describing complex, hard to describe things. Prototypes and models are other means.
Prototypes are generally models that represent an envisioned product. They exhibit product behaviors, look and feel and other characteristics in a way that can never be done in words. They take pictures and not only put them in motion, they enable the client to interact to get a sense of how the product will behave when it is finished. In our example, the contractor could have built a scale model of the space, with the doors in place and moveable to show how they open and close and what they will look like. In developing computer systems like websites and applications of many kinds, it is quite common for the developers to create prototypes based on relatively informal discussions with clients and then refine them as they discuss them with the clients. The cost of doing this is low compared with the cost of writing down the specifications, verifying them with the client, developing the product and then dealing with the inevitable responses like “I didn’t know it would look like that. Change it."?
Recognize the limitations of linear, analytical thinking. Language is linear and analytical and of course very powerful as a means to communicate. But, words are only one means, and in terms of communication, they convey a very small proportion of the full meaning. Use non-analytical methods – pictures, working models prototypes. If you question the premise that language is very limited as a means to determine requirements, try to describe in words the sound of a way a voice or piece of music will sound over a telephone or via computer. If you had an important client who was choosing the sounds that would great his or her customers or employees, would you rely on words or would you sample the sounds and play them, perhaps modifying them or offering several selections to choose one that is pleasing?
Also, remember to use your eyes and intuition along with your ears and intellect when working to come to agreement with others. Body language, the look on someone’s face, their tone of voice and other, less definable inputs often tell the discerning “listener"? what others are really thinking. Be ready to reconcile contradictory inputs. You might say something like “I have a sense that you are not really happy with that idea; maybe we should look at some other options before deciding."? The project manager is often driven by desire to get it done. So suggesting that a client think about other options when he is ready (based on his words) to accept something is counter intuitive. Do it anyway. In the end, it will save you time and trouble.
Remember, changes late in the project cost lots more than changes during the time when requirements are being discussed and defined and designs are being developed.
Priorities and Tradeoffs
As everyone should know, getting everything you want is rare. In projects the norm is to have to make tradeoffs in order to create a realistic balance among results, cost and time constraints. Given the availability of resources and money and the inability to magically manifest desired outcomes, it is usually necessary to cut back on some features or functions and/or to settle for less than what is really wanted.
If tradeoffs are agreed upon in a rational and mutually acceptable way, expectations are managed and the key stakeholders will not be disappointed when the product is delivered. Remember it is unrealistic expectations that cause suffering. By definition, if expectations are managed they will be realistic.
To best prepare for the negotiations that lead to tradeoff agreements, prioritize requirements. What are the must-haves? Among the nice-to-haves (everything other than the must-haves), which are most nice to have, least nice to have, and which are in- between? There are many possible prioritization scales with three, five or a hundred gradations in nice-to-have-ness. Pick one that makes sense for your project. And use it to get the client and relevant others (sponsor, product owners and custodians, etc.) to rank requirements’ priorities. For example, is having airflow through the doors a must have, or where does it fall on a scale of 1 (not really that important) to 5 (very, very important). It will be easier to make the decision as to whether to have a transom within the doors vs. duct work to ventilate the closed off areas, when the time comes.
Note that because many requirements are subjective (e.g., the esthetically based desire to have a complete pane rather than one encumbered by a transom or some other mechanism to allow airflow), it is likely that the priorities will change when the decision needs to be made. In our example, at the very start the complete pane requirement may have been quite high in priority. When faced with the cost and complexity of alternatives, the priority may change, particularly if there is a reasonably attractive alternative.
Binding Decisions
Negotiation, tradeoffs, multiple stakeholders to satisfy; these all add up to the need to make decisions. Relatively binding decisions regarding requirements need to be made fairly early in projects. Otherwise there will be conflict and costly changes later.
Note the difference between a “meeting of the minds"? and a binding decision. In a binding decision there is a sincere intention to hold to the decision into the future, in the face of changing conditions. Legal contracts are binding in that they hold the parties liable for damages caused by non-compliance. Any agreement to project objectives, requirements and specifications are part of the project contract (whether legally binding or not).
Here, in the difference between binding and non-binding, is another example of dynamic balance. If the binding is too rigid, then there will be difficulty when conditions change. If there is no binding then there is likely to be random change by any of the parties, causing avoidable conflict and excessive costs and delays.
Controlled Changed
Since everything is subject to change, there needs to be a change control provision that enables change while it keeps it to a minimum. Changes, up to a point, are part of the negotiation of project requirements, costs and schedules. Once there is agreement, a baseline is set. The baseline is the agreed upon scope, time and cost. As the desire or need for change arises, it is addressed in a consciously designed process that evaluates the change from a cost-risk-reward perspective. Appropriate decision makers decide whether and when the change should be made. Schedules and budgets are adjusted to compensate for the time and effort required to make the change.
Generally, the more effectively objectives and requirements are defined and designs are created, the less the likelihood of change.
Patience in the early stages of the project pays off later.
Consensus
Consensus decisions are those in which all parties truly agree to the conclusion and are satisfied that it meets their needs (if not their initial wants). Consensus is usually best among the alternatives, although the cost and time it takes to reach consensus is often excessive.
The alternatives range from authority based directives by individuals or small groups (which may or may not be wisely made) to democratic decisions in which a majority decides (invariably dissatisfying the minority, to at least some degree).
To effectively manage expectations, it is best to agree about the way decisions will be made and to agree to the degree to which the decisions are to be binding on all parties.
Quality Control – Making Sure the Outcome Meets Expectations
Quality control (QC) is the process in which the results are evaluated against expectations to determine if they comply. Testing, inspections, reviews and actual use are the means for QC. QC feeds information back into the planning and requirements definition process so that expectations can be kept realistic.
Some people may argue with the statement that QC is always present in every project. They may remember projects in which the product was just created and rolled out into normal use without testing. But even in these projects, someone is evaluating the results against expectations. When this is done during the operational use of the product, it is either a sign of poor project management or a calculated risk – we can save the time, effort and expense of testing and trade that off against the possibility of dissatisfied clients and sponsors.
In the end, the client and sponsor will evaluate the results against their expectations. Effective QC is one part of managing these expectations and keeping the project on track to deliver an outcome that meets the needs and expectations of the clients and sponsors. Effective QC identifies defects and shortfalls so that they can be addressed with minimum cost and schedule impacts. The principle here is that the earlier a defect is detected, the easier it is to correct.
It is good to remember that defects and shortfalls in project results remain in the memories of clients and sponsors. It affects their confidence in the project manager and the degree to which they want to pay the bills for the current project as well as for future projects.
Defects and shortfalls need not be corrected to satisfy expectations. Expectations are changeable. If a client is told to expect defects that have been consciously left in a product for good reason, they are likely to be accepting of them, even when they are disruptive. If there are shortfalls like undelivered features or late delivery, if they are communicated upfront, they can be negotiated as changed expectations.
Delivering and Accepting the Results
Results get delivered when projects are performed by skilled people using effective tools and methods. Project managers manage the work, which is usually performed by others.
When objectives, requirements and specifications are mutually understood, clear and well defined and there are agreed upon quality control and change control processes, the delivery will be relatively smooth. The outcome is likely to be acceptable (that is, within expectations).
When the product is delivered, it is a best practice to get concrete, formal and definitive acknowledgement of acceptance from clients and sponsors. Don’t assume that just because you (the project manager) think you are done that the client agrees. If there is any dissatisfaction, it needs to be addressed.
Even when there are legally binding contracts with very explicit specifications and objective measures, there are disputes about acceptance.
Managed expectations lead directly to ease in getting acceptance and closing the project. Acceptance and closure are not just for the end of the project.
Important steps are performed in the life of every project – there is a design, there are parts of the product that can be evaluated, there may be prototypes, etc. The outcomes of each of these steps3 should be evaluated and accepted. This enables communication and reaffirmation of expectations or identification of the need for change – managing expectations.
When expectations change, a conscious decision to continue the project should be made.
Conclusion
No one (except project managers want projects. Results is what people want. Often, the real results are delivered well after a project is complete. The project delivers a product that is then used or sold to achieve some higher order objective – for example, making more money, or enjoying productive and pleasant occupancy of a new facility, home or office.
The Zen perspective includes the understanding that both subjective and objective criteria must be considered in any exchange. If client satisfaction is a principle success factor, then the subjective satisfaction of the client must be considered and managed. Unrealized expectations are at the root of dissatisfaction. We suffer when we don’t get what we expect to get. Often, we suffer when other people don’t get what they expect.
Key expectations in projects are about what the end result(s) will be in some specified time frame for some cost under the conditions of available resources, roles and responsibilities, among others. It is all too common to have projects either driven by unrealistic expectations or to have a lack of clarity about the expectations of key people.
Managing expectations is the foundation for delivering quality results. Quality means satisfying requirements and expectations to deliver an outcome that is fit for use. To deliver quality, the best practice approach makes sure there are sufficient resources, method, time and effort to get a mutual understanding of the expected results, delving into the subtle details that may seem unimportant at the beginning of the project but become difficult issues at the end. The mutual understanding of expectations includes the hard-to-define subjective elements, roles to be played and the concrete objectives associated with well defined requirements.
In the end, communication towards a mutual understanding of the expectations of all parties to the project, coupled with a process to insure that the expectations are realistic, provides the key to project success. The project manager as well as clients and sponsors are most likely to succeed if they set realistic expectations. This means combining written statements of requirements and acceptance criteria, drawings, prototypes and models to get a meeting of the minds about what results are expected. It also means that roles and responsibilities are well defined and that there is realistic expectation regarding change – the only certainty is uncertainty. The paradox is that by accepting uncertainty as a certainty we have more realistic expectations and a greater opportunity to achieve the right results for the situation.
1 Clarity and ease are two characteristics of an effective work environment. Clarity implies an analytical and systems oriented view. Ease is the ability to maximize results with minimum wasted energy. It covers intrapersonal and interpersonal aspects of relationships and emotions as well as the more concrete aspects of concepts, tools and methods
2The Fog Index is a measure of the ease of understanding of text. It is based principally on the number of syllables in each word.
3These are interim deliverables or artifacts. Evaluating the major artifacts in a project is called gating or “checkpoint-ing"?. It is part of both quality control and financial control used to ensure that the project is on the right track and that expectations are realistic. When conditions change, these points enable decision- making regarding the continuation of the project.
