Lesson 6.2: Managing expectations and delivering bad news
Most customer conflict is a gap between expected and actual. Learn to set honest ranges, tell bad news early and plainly, and say no without losing trust.
By the end of this lesson you will be able to set expectations with a customer that you can meet, give an estimate as a range with a stated confidence, deliver bad news early and in a way that keeps the relationship, say no to a request without damaging trust and renegotiate a plan when facts change. You will learn a six-step way to deliver bad news, a simple script for each of the hardest conversations and a method of turning three guesses into a date you can promise. You will see three difficult conversations, one of which goes wrong, and use a simulator to turn an optimistic guess into a defensible commitment. This lesson follows 6.1, where you learned to run a demo. Here you learn what to say when the news is not good, which in real projects it sometimes is. You need no technical background.
Customer relationships rarely break because something went wrong. Things go wrong in every project: a data source is worse than expected, a security review takes longer, a feature turns out harder than it looked. Relationships break because of the gap between what the customer expected and what they got, and, above all, because of when and how they learned about it. A delay announced three weeks ahead, with a plan, is an annoyance. The same delay announced on the day, with no warning, is a betrayal. The facts are identical. The difference is expectation management.
What an expectation is
An expectation is a picture in someone's mind of what will happen and when. It is formed by many things: what you said, what the salesperson said, what a competitor's demo showed, what the sponsor told their own boss, and the person's own hopes. Many of those are beyond your control. What you can control is that the picture is as accurate as you can make it, and that it is corrected whenever it drifts from reality.
Expectations drift in one direction. They are formed in the optimistic mood of the start, when the demo is impressive and the problem looks tractable, and they are rarely revised downwards unless someone says so. Left alone, the picture of the finished result gets rosier while the real project meets friction. A forward deployed engineer is the person closest to the real project, which makes them responsible for telling the customer where it differs from the picture.
A helpful image is a gap that opens between expected and likely. In week one the gap is small. If you are quiet, it widens as friction accumulates. At some point reality arrives, as a missed date or a limit the customer did not know about, and the gap closes all at once, painfully. If you speak early and often, the gap closes in small steps, each easy to accept.
Set expectations from the start
The best time to manage expectations is at the beginning, before the picture hardens. A few habits do most of the work.
Say what you do not know. In the first meetings, be honest about uncertainty: "I will know much more after the data audit next week. Until then, any date I give you is a guess." Customers rarely resent this. They resent confident dates that later prove wrong.
Give ranges, not points. A single date implies certainty you do not have. A range, such as "between eight and eleven weeks", tells the truth and gives the customer something to plan around. It also leaves you room.
State your assumptions. Every estimate rests on assumptions: that the data arrives by a certain date, that the security review takes two weeks, that two people from the customer are available. Write them down, and tell the customer that if any fail, the estimate changes. This is not an excuse. It is a map of where the risk lies.
Say what is out of scope. The list from Lesson 2.3 is an expectation tool. A customer who knows what the pilot does not cover will not be surprised by its absence.
Say what the pilot will and will not prove. A pilot of fifty accounts may show a promising effect but cannot prove a result. Say so in advance, as in Lesson 2.3.
Correct what others have said. Often the sponsor has repeated something optimistic to their own management. If you hear it, clarify it kindly: "I want to be sure we are aligned. When I said the pilot could start in November, I meant if the extract is approved by the fifteenth."
Turn guesses into a range you can defend
How do you give a range you can defend? A simple, widely used method uses three guesses for each piece of work instead of one: an optimistic estimate, if everything goes well; a likely estimate, the most probable outcome; and a pessimistic estimate, if the usual problems occur. From these, a standard approximation, often called three-point estimating, gives an expected value and a measure of the spread.
The expected duration is the optimistic estimate plus four times the likely one plus the pessimistic one, all divided by six.
The spread, a rough standard deviation, is the pessimistic estimate minus the optimistic one, divided by six.
The expected value is a little above the likely one when the pessimistic case is much worse than the optimistic is better, as it usually is in software and in customer work: things can be much later than hoped, and are rarely much earlier. The spread then tells you how far to move toward a date you can promise with reasonable confidence. A common rule of thumb is that adding about one spread to the expected value gives a date you will meet around eight times in ten, and adding about one and a quarter spreads gives a date you will meet about nine times in ten.
This is an approximation, and the three guesses are still guesses. But the method has two real benefits. It forces you to think about the bad case, which people forget when they give one number. And it turns the conversation with the customer from "when will it be ready?" into "how sure do you want to be?", which is the honest question.
Predict first: your optimistic estimate for a data integration is six weeks, your likely estimate is eight, and your pessimistic one is fourteen. A sponsor asks, "So it will be done in eight weeks?" What do you say? Think about the one number you would not give and the one you would, before reading on.
You would not give eight, which is the likely date, since by your own estimate there is a real chance it takes longer, and promising it means you will often miss it. A better answer is a range with a confidence: "It will most likely take about eight to nine weeks. If we want to be about nine times in ten sure, I would plan for ten to eleven." The three-point method gives an expected value of about 8.7 weeks, a spread of 1.3, and a ninety per cent date of about 10.4 weeks. The sponsor can then decide whether to plan around the safer date, and you have told the truth.
The simulator: a date you can promise
The simulator below does the arithmetic. Enter your optimistic, likely and pessimistic estimates in weeks. It shows the expected duration, the spread and the dates to promise at four levels of confidence.
The method is a rough approximation, and it assumes your three guesses are fair. If you are systematically optimistic, as most people are, the pessimistic figure should be a little worse than feels comfortable. The point of the tool is to make the trade-off visible: a date you can be fairly sure of is longer than the likely date, and the gap grows with the uncertainty.
Try three experiments. First, keep the defaults and read the four dates. Second, raise the pessimistic estimate from 14 to 20 weeks and see how much further the confident dates move than the expected one. Third, narrow the three estimates to 7, 8 and 9 weeks, which describes a task you have done many times, and see the dates cluster.
At the defaults, the expected duration is about 8.7 weeks, the spread about 1.3, and the dates to promise at 80, 90 and 95 per cent confidence are about 9.8, 10.4 and 10.9 weeks. The likely date, eight weeks, is the one a sponsor will hear if you are not careful. The difference between eight and ten is the cost of being right more often.
Delivering bad news
At some point, you will have news the customer will not like: a delay, a data problem that undermines the plan, a result below target, a mistake you made. How you deliver it decides whether it damages the relationship or strengthens it. A six-step approach works in almost every case.
1. Tell them early. Bad news does not improve with age. The moment you are reasonably sure, and before you have a complete solution, tell the people affected. Early warning gives the customer time to adapt, and it signals that you will not hide things.
2. Tell them directly, and in the right way. Use the same channel the customer would choose for something that matters. A short call or a meeting is better than an email for serious news, and an email afterwards records what was said. Tell the sponsor before others hear it from someone else.
3. Start with the facts, plainly. Say what has happened in a sentence or two, without cushioning: "The nightly extract will not be ready by the fifteenth. It will be ready by the twenty-ninth." Do not bury the point in background.
4. Explain the impact and the cause briefly. What this means for the customer's goals, in their terms, and what caused it, in a sentence. Do not assign blame, including to yourself or to the customer's colleagues, and do not make excuses. If the fault is yours, say so.
5. Come with options and a recommendation. Bad news with a plan is a problem being managed. Bad news without one is a problem handed over. "We can wait for the full extract, or start the pilot with the partial file I have for the first city. I recommend the second, because it keeps the date for the first results."
6. Agree the next step, and a time for the next update. End with a clear action and a date. Then keep it.
Each step has a common failure.
The late teller hopes the problem will fix itself, and tells the customer only when the date is missed.
The indirect teller sends an email at six in the evening and switches off their phone.
The cushioning teller spends five minutes on context before saying what has happened, and the customer is left guessing.
The blaming teller names a person or a team, and gives the customer a second problem.
The plan-less teller leaves the customer with a worry and no way forward.
The vanishing teller says nothing further, so the customer must chase.
A short test before you deliver any bad news: could the customer repeat, in one sentence, what has happened, what it means and what you will do? If not, rewrite it.
Saying no
A particular kind of bad news is a refusal. The customer asks for something you cannot or should not do: an extra feature in the pilot, a date that is not feasible, access that breaks a security rule, a promise about results. Saying no badly damages trust. Saying no well can build it.
A few principles help.
Say no to the request, not to the person. The customer's aim is usually reasonable even when the request is not.
Explain the reason in their terms. "If we add the second city now, we will not have enough accounts in the control group to prove the result" is more convincing than "that is out of scope".
Offer what you can do. "I cannot add it to this pilot. I can add it to the list for the next phase, and I can show you a rough version next week if you would like to see it."
Show the trade-off. Often the honest answer is "yes, and here is what it costs": "We can add the report, if we move the go-live by two weeks or drop the second language. Which would you prefer?" This turns a refusal into a decision that belongs to the customer.
Be consistent. If you say yes to one person's out-of-scope request and no to another's, you will be accused of favouritism. Use the parking lot for everyone.
Say it early. A no at the start of a request is easy to accept. A no after you have half-built the thing is not.
A request you must never agree to is a promise about results that you cannot back, such as "guarantee a 20 per cent improvement". You can say, "We will measure it against the target, and I will tell you honestly what we find." An unconditional promise is a debt you will not be able to pay.
Renegotiating the plan
Plans change when facts do. When a significant assumption fails, such as a data source that does not exist, a delay that cannot be absorbed or a result that makes the original target unrealistic, the right response is to renegotiate the plan openly, not to keep to it silently and hope.
A useful process is to bring the customer into the problem. Show the facts and what has changed since the plan. Lay out two or three options, each with its cost in time, money, scope or risk. Say which you recommend, and why. Then ask the sponsor to decide, and record the decision, with its reason, on the one-page plan from Lesson 2.4, marked as a new version.
Customers respond well to this, for a reason that is easy to overlook. It treats them as partners with a real choice, not as people to be managed. And it makes the change their decision, which they will defend to their own management, instead of something imposed.
Worked example 1: the delayed extract
A week before the lender's pilot is due to begin, the engineer learns that the system owner cannot deliver the extended nightly extract until two weeks later. The engineer decides to tell the sponsor that day.
On a ten-minute call, the engineer says: "I have some news about the pilot start. The extended extract with payment history will not be ready on the fifteenth. The data team says the twenty-ninth. That moves the start of the first run by two weeks. Here are the options. We can wait and start on the twenty-ninth with the full data. Or we can start on the fifteenth with the partial file, which covers about 70 per cent of accounts, and add the rest when the extract arrives. I recommend the second, because we keep the early results and the control group, and the missing 30 per cent are mostly in the later bands we are not testing yet. Which would you like?"
The head of collections is not pleased, but she says: "Thank you for telling me now. Start on the fifteenth with the partial file." The engineer sends a short confirmation of the decision and the changed scope the same afternoon. Nothing in the project went wrong that day. What could have been a damaged relationship was a managed decision, because the news came early, with a plan.
Worked example 2: the result below target
At the end of the lender's pilot, the pilot group reaches 46 per cent of first-band accounts paying within seven days, against a baseline of 41 and a target of 48. The engineer has to present this to the sponsor.
A weak version would begin with a long description of the method and end with a hopeful interpretation. The engineer begins with the result: "The pilot reached 46 per cent against a target of 48. The control group stayed at 41, so the reminders added about five points. That is a real improvement and it is short of the target." Then the meaning: "With the numbers in this pilot, the margin of error is about five points, so I would call this promising, not proven." Then the options: extend the pilot for four weeks to enlarge the sample, change the message wording, which the callers suggested, or roll out as it is and accept a smaller gain than hoped. The recommendation: extend with the new wording.
The sponsor chooses the extension. The honest report, which did not overclaim and did not hide the shortfall, is the reason she trusts the next number she is shown. A result that misses the target and is told straight is far less damaging than one that is dressed up and later found out.
Worked example 3: the news that was hidden
A different engineer, on another project, finds in week four that the data for a quarter of the customers is missing the field the model needs. He is sure he can work around it, and decides not to worry the customer until he has a fix. The fix takes longer than expected. In week seven the sponsor asks for a progress update, and the engineer says it is "on track".
In week nine the missing data forces a design change, and the engineer must now tell the sponsor three things at once: the data problem, the delay and the fact that he knew about it for five weeks. The sponsor is angrier about the five weeks than about the delay. She says she would have chosen a different scope if she had known in week four, and that she can no longer be sure what else has been left unsaid. The project continues, but she insists on weekly written reports and reviews every figure.
No fact in the story was dishonest in itself, apart from "on track", which was close to a lie. The damage came from the silence. A message in week four, "a quarter of the records lack a field we need; I am looking at ways around it and will update you on Friday", would have cost two minutes and kept the trust. The lesson is the one that opened this lesson: the customer forgives bad news and does not forgive finding out late.
The two stories differ in one number: how long the engineer knew before telling the sponsor. The chart shows it.
Silence has a price beyond trust, because the sponsor cannot choose a different scope while she does not know. Try it with your own numbers: how long you stay quiet, what the team costs and how much of its weekly effort heads in the wrong direction in that time.
At the defaults, five weeks of silence with a team costing ₹4 lakh a week and 30 per cent of its effort heading the wrong way wastes about ₹6 lakh. Telling the sponsor the same day would have limited it to about ₹17,000.
When you made the mistake
Sometimes the problem is your own fault: a bug that sent a wrong message, a wrong figure in a report, a missed commitment. The same six steps apply, with two additions. Say plainly that it was your mistake, without a long apology or a list of reasons. And say what you are changing so that it does not happen again: a new check, a review step, a change in how you work. People forgive errors that are owned and fixed, and they remember errors that are hidden or excused.
Common mistakes
Giving a single date. Give a range with a confidence, and state the assumptions behind it.
Silence in the hope of a fix. Tell them when you are reasonably sure, not when you have solved it.
Delivering serious news by email alone. Call or meet, and follow up in writing.
Burying the point. Say what has happened in the first sentence.
Blaming. Describe causes without naming culprits, and own your own errors.
Bad news without a plan. Offer two or three options and a recommendation.
Saying yes to avoid conflict. Say what a request costs, and offer a decision.
Overpromising results. Promise to measure and report honestly, not to guarantee an outcome.
Keeping a plan that no longer fits. Renegotiate openly, and record the new version.
Key takeaways
Customer relationships break on the gap between expected and likely, and on when and how the customer learns about it, not on problems themselves.
Set expectations early: say what you do not know, give ranges with stated assumptions and say what is out of scope and what the pilot can prove.
Use three guesses, optimistic, likely and pessimistic, to give a range and a date you can promise at a chosen confidence.
Deliver bad news in six steps: early, directly, facts first, impact and cause briefly, options with a recommendation, and a next step with a date.
Say no to the request and not the person, explain in their terms and show the trade-off, and never guarantee a result you cannot back.
When facts change, renegotiate openly with options and record the decision. Own your own mistakes and say what will change.
Check yourself
1. Why is a range better than a single date, and what should accompany it?
A single date implies certainty you do not have. A range tells the truth, and it should come with the assumptions it rests on and how sure you are.
2. Name the six steps of delivering bad news.
Tell them early, tell them directly, start with the facts, explain the impact and cause briefly, offer options with a recommendation, and agree the next step with a time for the next update.
3. With optimistic 4, likely 6 and pessimistic 14 weeks, what is the expected duration?
(4 + 4 × 6 + 14) ÷ 6 = 42 ÷ 6 = 7 weeks.
4. A customer asks you to guarantee a 20 per cent improvement. What do you say?
Do not guarantee it. Say you will measure against the target and report honestly what you find, and explain what the result will and will not show.
5. Why was the engineer's silence in the third example more damaging than the delay itself?
The sponsor lost the chance to choose a different scope in week four and could no longer trust what else had been left unsaid.
Try this
This exercise takes about forty minutes and prepares you for a hard conversation. Use a real situation where you may have to give someone news they will not like, or an imagined one from a project.
1. Write the news in one sentence: what has happened, what it means and when you will know more.
2. Write your three estimates for the piece of work involved, and use the simulator to find the date you can promise at 90 per cent confidence.
3. Write the likely cause in one sentence without blame.
4. Write two or three options, each with its cost in time, money, scope or risk, and your recommendation with a reason.
5. Write what you will say in the first thirty seconds of the conversation, beginning with the facts.
6. Write the next step and the date of the next update.
7. Say it aloud to a friend, and ask them to repeat back in one sentence what has happened, what it means and what you will do. Revise until they can.
8. Write the follow-up message you will send within an hour of the conversation.
A good result is a short script, a defended date, two options with a recommendation and a follow-up message. People who practise bad news before delivering it find that the real conversation is easier and that customers respond more calmly than they feared.
Sources
The three conversations, the project curve and the simulator's figures are the author's illustrations for teaching, not data from real projects. The three-point estimating formula is a standard approximation, and the confidence multipliers assume a roughly bell-shaped spread, which is a simplification. The six-step approach to bad news and the guidance on saying no are practical methods written for this lesson, not industry standards.
Tags: Forward Deployed Engineer Expectations Bad news Customer communication Estimating