McKinsey and the University of Oxford studied more than 5,400 large IT projects. On average they ran 45% over budget and delivered 56% less value than predicted
PMI reports that 47% of unsuccessful projects miss their goals because of inaccurate requirements management. Put simply, the team and the stakeholder did not share the same picture of what was wanted.
While this research may be dated and the figures may have improved, the underlying point remains indisputable.
There is significant headroom for improvement in project management.
Most of us find that gap when it arrives as a complaint. A project leader I spoke with recently finds it early.
A conversation worth writing down
Talking with leaders across Asia Pacific is one of the best parts of my job. Every so often someone describes a way of working that I keep thinking about for days. This was one of those conversations.
She runs project management for a large organization inside a sizable enterprise. Her team spans several geographies, so time zones, languages and shared context are all hard to keep in one place. She has automated a good part of her operations and the analysis that goes with it. I have heard versions of that story often enough that the AI part no longer registers with me. What did register was how pragmatic it is.
I have seen plenty of AI use cases that make one person look sharper. This one makes the whole organization more efficient. It runs on the organization’s own meeting records, and anyone on the team can use what comes out of it.
Start with a record that does not drift
Almost all of her meeting transcripts are available. That is easy to underrate. In most organizations a meeting ends and what remains is memory, a few notes and an action list. Memory is selective, and each person leaves the room with a slightly different version of what was agreed. A transcript is the one version that does not change. Everything else stands on it.
Asks, expectations and working styles
On top of that record, she has looked closely at her stakeholders. What they ask for, what they expect and how they like to work are all written down and sorted.
The difference between the first two is useful. An ask is what someone says out loud. An expectation is what they assume will happen without saying it. Trouble usually starts in the space between the two. Working styles are the human part: the sponsor who wants detail a day before the meeting, the one who decides in the room, the one who agrees politely and objects a week later.
Experienced project managers carry this knowledge in their heads. She has it on paper, which means it survives a reassignment and can be checked against what actually happened.
Naming the paths to a mismatch
She has also described the typical paths along which what a stakeholder expected and what the team delivered slowly separate. I thought this was superbly done. Once you can name a path, you can recognize its early steps. Most of us only see a mismatch when it has become a complaint.
The team gets the same attention
Feedback from reviews, ceremonies and retrospectives is recorded and looked at together. Each person on the project and their lead are considered individually, and alignment across everyone is reviewed on a regular rhythm. Most retrospectives I have seen end with sticky notes and a promise to do better. Here they feed a current picture of how people are working together and where that is slipping.
The part I found most inspiring
She runs a blind-spot analysis. Based on how stakeholders have actually engaged, it points to what the team may be missing, where features and scope are starting to part ways, and which conversations should happen next.
To make that concrete, picture a sponsor who has raised data quality in four meetings in a row while the project plan mentions it once. That example is mine, not hers. It shows the kind of pattern a system reading every transcript can surface and a busy human often cannot.
What stayed with me was how well she handles what it finds. She walks into steering committees with early warnings and forward-looking conversations instead of a recap. A status report describes where the project has been. What she brings is closer to a forecast, and I would guess that changes the tone of the room.
Why I call it repeatable?
There is no special model here and no secret. It needs meeting transcripts, a consistent way of describing stakeholders, and a habit of asking what the team might be missing. A team of any size can start with one stakeholder and one meeting series.
A 10-step framework you can borrow
After that conversation I tried to write her approach down as a sequence. This is my reading of what she does, not her own framework. Adjust it to your context.
Capture every meeting.
Record and transcribe as many stakeholder calls, reviews, ceremonies and retrospectives as your policies allow. Everything after this depends on having a record that does not drift.
Decide what you will classify.
Agree the categories you care about before any analysis: asks, expectations, concerns, decisions and open questions. A short, stable list beats a long one nobody applies consistently.
Understand each stakeholder
For every person with real influence, write down what they ask for, what they expect and how they like to work, such as when they prefer to see detail and how they react to bad news.
Separate asks from expectations
Put what each person says next to what they appear to assume. The gaps you find are the raw material for most of what follows.
Map your mismatch paths.
Look back over past projects and note the usual ways expectations and delivery drift apart. Name each path so your team can recognize its early steps.
Add the team signal.
Feed reviews, ceremonies and retrospectives into the same picture. Look for repeated friction, unresolved themes and work that keeps changing hands.
Check how people and leads work together.
Build a picture of how each team member works with their lead and the stakeholders they serve. Keep it in service of alignment.
Recalibrate on a schedule.
Alignment drifts as soon as people, scope or priorities change. Review it every sprint or every steering cycle so it stays current.
Run the blind-spot analysis.
Compare how stakeholders have engaged against what the team has covered. Flag topics raised repeatedly but barely addressed, features that no longer match scope, and people who have gone quiet.
Act on it.
Turn each blind spot into a specific conversation or early warning, and take it into your steering committee communications. Afterwards, record what happened, so the next round starts from better data.
The loop matters more than any single step. Step 10 produces new meetings, and new meetings feed step 1.
Ground rules I would consider
Data about people deserves a high standard of care. If you borrow this idea, I would hold to four rules:
Record openly, so everyone knows meetings are captured.
Keep to work-related information.
Let people see and correct what is written about them.
Use it for alignment and never to rank anyone.
Three things that stay with me
The first is how unglamorous the foundation is:
i.e., Transcripts, classification and a consistent way of describing people. Nobody gets excited about that, but a model sitting on top of it can say something useful, while a model sitting on top of nothing can only summarize.
The second is that stakeholder management turns out to be partly a data problem. A lot of what we call intuition can be written down, tested and improved.
The third is that looking forward is a habit you can build into the process. It does not have to depend on one person’s instinct.
Try a small version first
Pick one stakeholder you deal with every week and do steps 3, 4 and 9 for that person alone. Write down what they ask for, what they seem to expect and how they react when plans change. Then read your current plan and ask what would surprise them. It takes about twenty minutes, and I would be surprised if it did not show you a gap.
I found a great deal to learn from this conversation. If your team keeps records like these, I would like to hear what you do with them. Reply to this email or leave a comment.
Subscribe to Technoclast Insights to get the next edition. The 12-slide carousel for this post is on my LinkedIn, you can find it here
Sources:
McKinsey and the University of Oxford, “Delivering large-scale IT projects on time, on budget, and on value.” PMI, “Requirements Management: Core Competency for Project and Program Success.”