SN L3a — Customer Expectations

A revision summary of the first Needs lecture. Its one claim is that two teams can ship identical software and collect opposite verdicts, because a customer does not judge what you delivered — they judge it against what they were expecting. Everything below is a way of finding out what they expect, or of moving it while that is still cheap. Each section links to the handbook page carrying the detail and the sources.

1. A verdict is a comparison, not a measurement

The relationship that organises the whole lecture is a ratio [1]:

Customer perception = Project performance ÷ Expectations

A customer expecting a four-second response calls three seconds a win. A customer expecting one second calls the same three seconds a failure. So the first question about a “slow” system is never how slow — it is what did we tell them it would be. The numerator is the half you were already managing; the denominator is the half this lecture is about.

The denominator has structure. Customers hold three standards at once [2]: the desired level they hope for, the adequate level they will accept, and the predicted level they think they will actually get. The gap between desired and adequate is the zone of tolerance — land inside it and nobody complains at all.

Two consequences are worth memorising. The zone moves from the bottom: almost every lever a manager holds acts on the adequate line, not on what the customer wants. And it narrows with history — a second failure after a botched recovery, or a visible alternative supplier, tightens it. The one move that widens it is a cause outside your control that they hear from you, which is why a status page and a postmortem are project management rather than public relations.

→ Expectations · Setting expectations

2. Delivering everything they asked for still scores zero

Requirements do not all move satisfaction the same way, which is why a fully delivered backlog can land flat. Kano sorts them into three classes [3]:

• Must-be — taken for granted, so meeting them buys nothing and missing one is punished hard. The login works, no data is lost, the page loads.
• One-dimensional — satisfaction is proportional to fulfilment. Speed, quota, rate limit. This is usually what was actually asked for, and the only class where “we improved it 20%” is a sentence worth saying.
• Attractive — never asked for, so their absence costs nothing and their presence delights.

The tie-break is must-be beats one-dimensional beats attractive: no amount of delight compensates for a failed must-be, which is what “delivering everything gets you to zero” means. Two boundary conditions carry as much weight as the model itself. The class belongs to the customer segment, not the feature — single sign-on is a must-be for enterprise accounts and an irrelevance to a free tier. And an attractive requirement decays into a must-be, so a classification has a half-life.

→ Kano classes

3. Somebody defines success — make sure it is not after delivery

Success is a definition before it is a number. The CHAOS reports publish two side by side, and for the same FY2015 database they give 36% successful under the traditional definition and 29% under the modern one [4]. Nothing about the projects changed. When you are quoted a failure rate, the first question is which definition produced it.

For magnitudes, use better-sourced work: a McKinsey study with Oxford of 5,400 projects over $15 million found an average 45% cost overrun and 56% less value than predicted — and that software alone was worse, at 66% and 33% [5].

The project-level answer is to write success down before the work starts. Wysocki’s Conditions of Satisfaction is a loop — request, clarification, response, agreement — repeated until neither side corrects the other [6]. The restatement is the test: a correction means you had it wrong and did not know. Its deliverable is a one-page Project Overview Statement, and it carries no completion date, which is negotiated after scope is agreed rather than before.

The threshold of success is built backwards, because goal statements resist precision and failure statements do not [7]: write what failure looks like, invert each statement into a criterion, and check each is SMART — where the A is assignable, naming who is responsible. The payoff arrives in L3c: a risk is exactly a concern that would breach the threshold, and everything else is an event that might happen and would not matter.

→ Defining success · Threshold of success

4. Whose expectations are they?

You cannot manage the expectations of people you have not found. Alexander and Robertson model stakeholders as four rings, and the useful mechanism is the slot — a generalised role, drawn solid when filled and greyed out when not [8]. An empty slot is a finding; a missing person is just invisible.

Finding them turns out to be the easy part. Asked to name the single stakeholder concern causing the biggest problem in their own work, 541 practitioners put skill first at 38% and commitment second at 34%; discovery came fourth, at 13%. The hard problem is getting the people you already located to engage usefully.

Their satisfaction is also not linear. At Xerox, completely satisfied customers were six times more likely to repurchase than merely satisfied ones [9]. So a team reading 82% in the top two boxes as a pass has misread it: the correct reading is “48% are completely satisfied and 52% are up for grabs.” Stated intent flatters further — 60–80% of car buyers say they will rebuy the brand, and 35–40% do.

→ Stakeholders · Customer types

5. Educating the customer is cheaper than negotiating with them

Each side can only trade what it controls. The customer holds scope, time, quality and cost; the developer holds people, process and technology [7]. An expectation is a point in the customer’s space, and the manager’s job is the function that reaches it from a space with different axes. A developer-side decision only becomes negotiable once restated in the customer’s four terms.

The reason the two sides cannot negotiate unaided is what Boehm calls the Two Cultures: neither has a feel for what is cheap on the other’s side [1]. A customer who cannot see relative cost prioritises on desire, because desire is the only information they have.

The fix is information, not persuasion. For example, a Windows beta customer brought two changes, both labelled must have [10]: a toolbar button at half a day, and hot-linked drag-and-drop needing full OLE support at six to nine staff months. Told the two costs, the customer withdrew the expensive one themselves — “No way! It’s not that important.” Nobody negotiated and nobody refused. In the same spirit, one architecture estimated at $100M came back at $30M after a single prototype.

→ Expectation space and solution space

6. Involving them: a lever with a setting, not a virtue

The largest synthesis available — 87 studies over 32 years — splits 52 positive, 12 negative, 23 uncertain [11]. Involvement usually helps and sometimes makes things worse, which turns an exhortation into four design decisions: which users, at what degree (informative → consultative → participative), for which goal (a sense of control, or moving domain knowledge), and in which phase. Note also that involvement is not participation — attendance is a behaviour, involvement is a psychological state, so “we involved the users” is not a checkable claim.

When the customer will not give you the time, a three-year study of 30 practitioners mapped what teams do instead, as a continuum ordered by directness: on-site customer → story owner → just demos → e-collaboration → customer proxy → extreme undercover [12]. Knowing which rung you are on is more useful than any advice about collaboration. Two repairs are concrete enough to copy — a Definition of Ready, and a buffer sized from recorded velocity.

The practical rule underneath all of it: show the software, do not report on it. One team ran the customer hour as 15 minutes showing and 45 discussing. A prototype that read fine in every status report turned out to be 40% correct, and the fix was walking users through the build every two weeks. As one agile coach put it, a customer can say “I want to have Taj Mahal” — but of granite or marble? “They don’t even have time to talk about that.” Reacting is cheap; specifying is not.

→ Customer involvement

7. When it goes wrong

Petter studied 12 project managers across 24 cases and found three strategies and 24 tactics, of which only three risks are genuinely under your control [13]. The one to remember: they should hear it from you, and early. Bad news you deliver first buys tolerance; bad news they discover spends it.

Two quieter points close the lecture. You set expectations with your price list, not just your roadmap — a premium price is a promise [2]. And a change request is how a customer learns what things cost, so every accepted change gets an impact statement in three lines before anyone starts, which returns the conversation to §5.

Where this goes next

L3b turns expectations into requirements a tester can hold you to; the PBJ exercise straight after it shows how badly that goes when assumptions stay unwritten. L3c takes the concerns that would breach your threshold and manages them as risks. All three are examined together in Q3.

---

Acknowledgments

This content is heavily inspired by and adapted from lectures by Eduardo Miranda and David Root [14] on software project management. The structure, examples, and pedagogical approach reflect their teaching materials and frameworks.

References

1. B. Boehm, M. Abi-Antoun, D. Port, J. Kwan, and A. Lynch,
   “Requirements engineering, expectations management, and the Two Cultures,” in Proceedings IEEE International Symposium on Requirements Engineering (Cat. No.PR00188), June 1999, pp. 14–22. doi: 10.1109/ISRE.1999.777981.
2. V. A. Zeithaml, L. L. Berry, and A. Parasuraman,
   “The Nature and Determinants of Customer Expectations of Service,” Journal of the Academy of Marketing Science, vol. 21, no. 1, pp. 1–12, 1993, doi: 10.1177/0092070393211001.
3. E. Sauerwein, F. Bailom, K. Matzler, and H. H. Hinterhuber,
   “The Kano Model: How to Delight Your Customers,” in Preprints Volume I of the IX International Working Seminar on Production Economics, Feb. 1996, pp. 313–327.
4. The Standish Group International,
   “CHAOS Report 2015,” The Standish Group International, Inc., 2015.
5. M. Bloch, S. Blumberg, and J. Laartz,
   “Delivering Large-Scale IT Projects On Time, On Budget, and On Value,” McKinsey & Company, McKinsey on Business Technology, Oct. 2012.
6. R. K. Wysocki and R. McGary,
   Effective Project Management: Traditional, Adaptive, Extreme, 3rd ed. Wiley Publishing, 2003.
7. C. L. Hoover, M. Rosso-Llopart, and G. Taran,
   Evaluating Project Decisions: Case Studies in Software Engineering. Addison-Wesley Professional, 2010. [Online]. Available: https://www.oreilly.com/library/view/evaluating-project-decisions/9780321685629/
8. I. Alexander and S. Robertson,
   “Understanding Project Sociology by Modeling Stakeholders,” IEEE Software, vol. 21, no. 1, pp. 23–27, Jan. 2004, doi: 10.1109/MS.2004.1259199.
9. T. O. Jones and W. E. Sasser,
   “Why Satisfied Customers Defect,” Harvard Business Review, vol. 73, no. 6, pp. 88–99, Nov. 1995, [Online]. Available: https://hbr.org/1995/11/why-satisfied-customers-defect
10. S. McConnell,
    Rapid development: taming wild software schedules. Pearson Education, 1996.
11. M. Bano and D. Zowghi,
    “A Systematic Review on the Relationship Between User Involvement and System Success,” Information and Software Technology, vol. 58, pp. 148–169, Feb. 2015, doi: 10.1016/j.infsof.2014.06.011.
12. R. Hoda, J. Noble, and S. Marshall,
    “The Impact of Inadequate Customer Collaboration on Self-Organizing Agile Teams,” Information and Software Technology, vol. 53, no. 5, pp. 521–534, May 2011, doi: 10.1016/j.infsof.2010.10.009.
13. S. Petter,
    “Managing User Expectations on Software Projects: Lessons from the Trenches,” International Journal of Project Management, vol. 26, no. 7, pp. 700–712, Oct. 2008, doi: 10.1016/j.ijproman.2008.05.014.
14. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

---

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.