Managing Expectations in Technology Projects: You're Graded on the Gap, Not the Delivery
A technology programme is judged the way a listed company is judged at results season: on the gap between outcome and expectation, not on the outcome itself. Most business cases lose that exam before the work begins.
Every results season somebody asks why a company's shares fell after good results, and every delivery review stages the same scene: the project shipped, the demo worked, the dashboard is green, and the room is cold. Neither audience is being irrational. Both are marking a different exam. The verdict is never on the result; it is on the gap between the result and the expectation somebody issued earlier. Managing expectations in technology projects isn't a soft skill bolted onto delivery. It is the denominator every delivery gets divided by, and most programmes let it be set by the most optimistic document they will ever produce: the funding pitch.
Markets make the mechanism easy to see because they price it daily. A share price is a forecast, and by results day that forecast already contains a detailed guess at the announcement, which is why results are judged against consensus and forward guidance rather than in isolation: companies with shrinking profits rise after clearing a gloomy bar, and companies with growing profits fall after missing an optimistic one. Every reporting season pairs a profitable business sold off with a loss-maker bought, and every season commentators call it sentiment. It's arithmetic. The reported number is the numerator. The denominator was set months earlier, by someone else, and the price move is the division.
Your programme has a share price too. It is just illiquid, and it trades in meetings. The consensus estimate is whatever the steering group remembers from the business case. The guidance is your roadmap. Credibility is the multiple: how much of your next forecast anyone is still prepared to believe.
Why do successful IT projects still read as failures?
Because the expectation was issued at the moment of maximum ignorance and maximum salesmanship. A business case is written before the work starts, by people who need it approved, in competition with other cases that are also being oversold. The winning number is selected for persuasiveness, not accuracy, and then it hardens into the consensus the delivery will be marked against. Eighteen months later a team ships a platform migration that works, on a timeline that was defensible, and discovers it is being graded against the version of the project that only ever existed in the approval deck. Delivery of 3 per cent improvement against a promise of 5 is a miss, whatever the retrospective says.
Notice what this predicts: the delivery organisation with the best marks is not the one that delivers the most. It is the one whose priors were most honest. That is uncomfortable, because most funding processes actively punish honest priors. If your governance only funds projects that promise spectacular returns, you have not raised the bar. You have guaranteed that every project either lies at the start or fails at the end.
When should you kill a failing technology programme?
Earlier than you will want to, and more completely. Boards fear the writedown moment: the formal admission that the two-year replatforming will not earn what the roadmap claimed. But the market evidence on corporate writedowns points the other way. Research on goodwill impairment announcements finds positive abnormal returns over the six and twelve months that follow a write-off, with larger impairments followed by larger subsequent returns. The reading I take from that evidence: a loss the audience already suspects is cheap to admit, because the admission doesn't create the loss. It releases the ambiguity that was being priced against you while you denied it.
The organisational version is exact. By the time leadership debates killing a failing programme, the organisation has usually impaired it already: engineers route around it, sponsors stop attending, dependent teams quietly decouple their plans. The formal kill confirms a valuation the corridor reached months ago. What actually costs is the drip: quarter after quarter of 'amber, recovering' that keeps everyone pricing the uncertainty. If I'm wrong about this, it would show up as organisations that favour the slow bleed keeping more trust and better people than organisations that admit cleanly. I have never seen that case.
Is mandated adoption real adoption?
The quieter trap sits inside apparently good numbers. Revenue can grow because customers want more of the product, or because they are being charged more for the same thing: McKinsey's work on revenue growth management describes inflation-era businesses holding net sales up through steep price rises even as volumes flattened or fell. The two look identical on the top line and mean opposite things about the future.
Technology programmes produce the same illusion with usage. An AI assistant rolled out by mandate will show adoption curves any product manager would envy, because the alternative was switched off. Usage by decree is price-led growth's cousin: the metric rises while the demand truth stays hidden, and the truth arrives at renewal time, together with the expectations reset. If you want to know whether your AI programme is compounding or coasting, don't ask how many people used it. Ask what they did when they had a choice.
How do you manage expectations in a technology project?
Like a listed company that intends to stay listed. Write the prior down before the work starts: the specific, dated, falsifiable version of what the investment should return, separated cleanly from the stretch target you use to motivate the team. That is most of what assessing AI readiness before you build actually amounts to, establishing the consensus estimate while you can still afford for it to be honest. Then treat the roadmap as guidance, because your stakeholders already do: re-guide the moment your forecast moves, not at the review where the miss becomes undeniable. And grade the gap afterwards, in public. That habit of written priors and graded gaps is the discipline our technology strategy work tries hardest to leave behind in a client, because a result without a prior is just a number, and nobody learns anything from a number on its own.
Which leaves the asymmetry nobody prices. A beat buys you one good steering meeting. A miss costs you the meeting and something slower to rebuild: the willingness of anyone in the room to take your next forecast at face value. Expectations are the one asset over which a delivery leader has total issuance control, and the one most reliably over-issued. Guide low, report true, and let the gap do the work.
Questions people ask
Why do shares fall after good results?
Because markets judge results against the consensus forecast and forward guidance already embedded in the price, not in isolation. Profit growth that lands below the expected level trades as a miss, and lowered guidance can wipe out a historic beat. The same mechanism operates in delivery reviews: the business case sets the consensus a project is marked against.
What is an expectations gap in project delivery?
The difference between what a technology programme delivers and what its approved business case, plans and status reports led stakeholders to expect. Verdicts track this gap rather than absolute output, which is why an oversold project that delivers competently can still be judged a failure.
Should an AI business case be conservative or ambitious?
Separate the two jobs. Fund against a conservative, falsifiable forecast you would be content to be graded on, and motivate the team with a stretch target that is explicitly not the funding number. Merging them means every future review is marked against your most optimistic day.
Related
- Your Cloud Provider Is Financing Its Own AI Revenue. Do the Financial Due Diligence
- The Announcement Is Not the Deal: AI Infrastructure's Announced vs Contracted Gap
- The Target-Less Number: Glucose Sensors Are Turning Fitness Trackers into Health Anxiety Machines
- Data & Strategy
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.