Chapter 10.1 ← 10.0 Conclusion and Next Steps
Getting Better at This on Purpose
Project management is one of those skills where time served and ability come apart. Some people are genuinely better after three years than others are after fifteen, and the difference is almost never talent. It is whether their experience was ever allowed to correct them.
In short
- Project feedback arrives months late and tangled with other causes, so it does not correct you by default.
- The fix is to record what you expect before the outcome is known, and read it afterwards.
- Once you know how something turned out, you cannot reconstruct what you actually thought beforehand. This is not a memory problem you can try harder at.
- Improve one thing per project, not five. Five means none.
- Reading, courses and conferences are worth having, but they change how you talk before they change how you work.
Why the lesson does not arrive on its own
Consider a small, entirely ordinary decision. In January, someone asks how long the integration will take. You say two weeks, because two weeks feels right and the person asking would like it to be two weeks. In July, the launch slips by a month.
Is the January estimate the reason? Possibly. But by July there are four other perfectly true explanations available, all of which have the advantage of not being about your judgement. The vendor was late. Two people left. Scope was added in March. Testing found more than expected. Every one of those stories is defensible, and the one that gets told is usually the one that costs the least to tell.
You cannot remember what you used to think
The instinctive objection is that you would remember. You would know whether the January estimate was optimistic, because it was your estimate.
This turns out not to be how minds work. Once an outcome is known, memory quietly revises the earlier belief to fit it — a well-documented effect called hindsight bias. People asked to recall their own predictions after learning the result consistently misremember them as closer to what happened. This is not carelessness and it does not respond to effort. It is why courtroom witnesses, doctors and forecasters all had to invent written records instead of relying on recollection, and it is why “I'll remember the lesson” is the least reliable sentence in project management.
The consequence is specific and slightly unsettling: without a written record, you will consistently conclude that you saw it coming. And someone who always saw it coming has nothing to learn.
The prediction note: the whole method in ten minutes
Everything useful here fits in one habit. At the start of a project — or at any point where you commit to something significant — write down, privately:
- What you expect to happen. The date you actually believe, not the one you agreed to. They are frequently different, and the difference is the interesting part.
- The three things most likely to go wrong, and roughly when each would show up.
- How confident you are, in plain words. “Fairly sure”, “this only works if the data is clean”, “honestly guessing”.
- What you are choosing not to do, and why. Omissions are decisions, and they are the ones nobody records.
Then set a reminder to read it. Not at the end — at the end you will be busy and defensive. Read it at the midpoint, when there is still time to act on what you notice, and again after closure.
What you learn from it
Almost nobody's first surprise is “my estimates are too low”. It is usually more specific and more useful than that: I am fine on the work I can see and blind to hand-offs between teams. I consistently assume people are available who are not. I catch technical risk and miss political risk entirely. Those are patterns you can actually do something about, and you cannot find them any other way, because each individual instance looks like bad luck.
Change one thing per project
The failure mode of people who take improvement seriously is trying to fix everything at once. They finish a difficult project, list eleven things they would do differently, and change none of them, because eleven simultaneous new habits is not a plan — it is a mood.
Pick one. Make it small enough to be unambiguous and specific enough that you would notice failing to do it. “Communicate better” is not it. “Send the weekly note on Friday morning, before anyone asks” is. “Manage risk properly” is not it. “Ask every estimate-giver what would make it take twice as long” is.
Run the next project with that one change and see whether it helped. A single change is testable; eleven are not, because if things go better you will have no idea which one mattered. Roughly four to six deliberate changes a year, each one actually adopted, is a rate of improvement that outruns almost everybody.
Learn from projects that are not yours
Your own projects arrive at a rate of two or three a year, which is a slow data set. Other people's are free and there are many more of them.
The useful move is to be curious in a specific way. When you hear that another team's delivery went badly, the interesting question is not what went wrong — you will be told a cause, and it will be the tidy one. The interesting question is when did you first suspect? The gap between the first suspicion and the first admission is where nearly all project failure actually lives, and people will tell you about it honestly if you ask about it that way, because it does not sound like an accusation.
Do the same with successes, which are less examined and often more instructive. A project that landed on time usually did something structural to make that possible — a scope decision in month one, a person who was protected from other work, a dependency someone removed early. Ask what that was. “Good team” is never the whole answer.
Where courses and reading actually fit
Books, conferences and training are worth having, with one caveat worth stating plainly: they change your vocabulary considerably faster than they change your behaviour. It is entirely possible to be fluent in a framework you have never successfully applied, and the fluency can hide the gap for years.
They are most useful in two situations. The first is when you are stuck on something specific — you keep failing at stakeholder alignment, so you go and read three serious things about it. Targeted at a real problem, input lands, because you have somewhere to put it. The second is broadening: seeing how construction or manufacturing or clinical trials handle a problem you thought was inherent to your industry. That kind of reading is where genuinely new options come from.
What is much less useful is reading as a substitute for the uncomfortable part. If you have read four books this year and never written down a prediction you might turn out to be wrong about, the reading is not doing the work.
Get one person who will tell you the truth
A project manager is in an awkward position for feedback. The team is not going to tell you your meetings are a waste of their time. Your sponsor sees the reports rather than the running. Peers are often quietly competing with you. The result is that you can go a very long time without anyone saying anything specific about how you work.
So arrange it deliberately. One person, more experienced or simply more direct, whom you can ask concrete questions of — not “how am I doing?” but “I handled that escalation like this; what would you have done?” Specific questions get specific answers, and specific answers are the only kind you can act on. This is worth more than most training budgets and costs a coffee.
How this looks in AB
The mechanics of this are easier when the record already exists. In AB Projects, a prediction note lives naturally as a wiki article in the project itself — written at kickoff, sitting alongside the plan, and still there when the project closes rather than lost in a personal notebook between jobs. A task with a due date set for the midpoint makes the review happen instead of being intended.
Because closed projects stay searchable, the archive gradually becomes something more valuable than any single document: a record of what you predicted against what actually happened, project after project. When a new piece of work starts and something about it feels familiar, you can go and read what you thought last time — which is the one form of experience that does not fade.
Terms used on this page
- Hindsight bias
- The tendency, once an outcome is known, to remember having expected it. It is why written predictions are necessary rather than merely tidy — recollection is quietly rewritten by the result. More →
- Deliberate practice
- Practice structured to produce feedback you act on — specific, reviewed, slightly beyond current ability — rather than mere repetition of an activity. More →
- Lessons learned
- The record of what a project would do differently next time. Useful only if written specifically enough to act on and stored where the next project will actually find it. More →
- Retrospective
- A structured team review of how a piece of work went and what to change, focused on the process rather than on individuals. The collective counterpart to a personal prediction note. More →
- Estimate
- A considered guess at how long something will take or cost, expressed with its uncertainty. An estimate stated without uncertainty has been converted into a promise by accident. More →
- Escalation
- Passing a decision or problem to someone with the authority to resolve it, because it sits outside what the project manager can settle alone. More →
Related reading
7.2 Retrospectives
The team version of this page: how to run a review that produces a change rather than a list.
8.2 Lessons From Failed Projects
What failure actually looks like from inside, and why it is so rarely visible in time.
10.2 Certifications
What the main project management credentials cover, and who each one is actually for.