Traits of Successful Projects
Projects that go well are unspectacular. There is rarely a moment of brilliance to point at — which is why they get written up so much less often than disasters, and why the things that actually work are easy to underestimate.
In short
- The highest-return practices are the cheapest ones, and they are all set up in week one.
- Four of them account for most of the difference: a deciding sponsor, written exclusions, priced changes, and reading the last retrospective.
- Successful projects are not the ones with fewer problems. They are the ones that found their problems earlier.
- Heroics are a symptom, not a cause. A project rescued by a heroic month was mismanaged three months earlier.
Effort against effect
The four that do most of the work
1. A sponsor who actually decides
Not a name on a slide — a person who, when scope and date collide, says which one gives. Projects with one resolve their first real conflict in days. Projects without one resolve it by whoever is loudest, or by the calendar running out.
The test costs one question at the start: if we have to choose between the deadline and half the features, who makes that call? A vague answer here is the strongest early predictor of trouble. See 2.1 Initiation.
2. Written exclusions
Every project writes down what it will do. The ones that go well also write down what they won’t — specifically the things a reasonable person might assume are included. That list is what converts a month-four argument into a week-one conversation. 3.1 Scope covers writing it.
3. Every change carries a price
Not a change control board — just the habit of saying “that’s about two days; do we move the date or drop something?” It converts a favour into a decision and hands it to the person whose job it is. Projects that do this end up with the same amount of change as everyone else and none of the surprise. See 6.2.
4. Somebody read the last project’s notes
Ten minutes at kickoff, reading the retrospectives of the two most similar past projects. It is the cheapest item on the chart and the one most consistently skipped, because nothing forces it. Teams that do it start with a risk register that already contains the things that actually went wrong last time. See 7.3.
What successful projects don’t have
Just as informative as the list above:
- Fewer problems. Successful projects hit the same supplier failures, sick weeks and misunderstood requirements as everyone else. They found them sooner and the responses were cheaper.
- Perfect requirements. Nobody has these. The good projects had requirements that were wrong in known ways, with a mechanism for finding out which ways.
- Heroic finishes. A rescue month is not a success story; it is evidence that something was invisible for a long time. Teams that regularly rescue projects are teams that regularly detect late.
- Elaborate tooling. The tool matters far less than whether people update it, and updating depends on the four habits above rather than on features. See 5.5.
- Unusually talented teams. This is the uncomfortable one. Capability varies less between projects than coordination does, which is why the same team produces very different outcomes on different projects.
A composite: the project that was boring on purpose
Assembled from patterns rather than describing any single organisation — but every element below recurs often enough to be worth recognising.
The project. Replace a fifteen-year-old internal reporting system. Six people, five months, one external vendor for the data layer. Nothing about it was novel and everyone had seen a similar project go badly.
Week one. The finance director was named as sponsor with a standing fifteen-minute Friday slot. The team read the retrospective from the previous migration, which said in one line: “the vendor security review took five weeks, not two — start it immediately.” They started it in week one.
Week three. The scope document listed nine exclusions. Two of them — mobile access and historic data beyond 24 months — produced immediate objections from two different groups, which were resolved in a forty-minute meeting. On the previous project the same two questions surfaced in month four and cost six weeks.
Week nine. Data quality turned out to be much worse than assumed. This was a genuine surprise and it cost three weeks. Because they had eight days of buffer and a sponsor available, the response was a decision in two days: cut the two lowest-value reports, keep the date.
The ending. Delivered a week later than the original plan, with two reports fewer than originally scoped, both agreed in writing. The operations team had been in the fortnightly demos since week four and accepted the handover without a fight. Total closure effort: a day and a half.
Nothing in that account is impressive. The team hit a serious problem in week nine and were still fine, because everything decided in week one had shortened the distance between a surprise and a decision. That is what “a well-run project” looks like from inside: not the absence of trouble, but trouble that arrives with somewhere to go.
The week-one checklist
Everything above compresses into six things, none of which takes long:
- Name the sponsor, and get their standing slot in the calendar.
- Write the objective as a problem, not a solution.
- List at least four exclusions — and keep going until one surprises somebody.
- Read the two most similar past projects’ retrospectives.
- Book the slow external dependency now, whatever it is.
- Agree what “done” means for the first two deliverables.
Under two hours in total. Compared with anything else available to you in week one, the return is not close.
How this looks in AB
Five of the six checklist items have a natural home in AB Projects, which is mostly a matter of putting them where they’ll be seen rather than in a document:
- The sponsor as a project member with the standing slot noted in the description.
- The objective as the project description — if it names a solution rather than a problem, it’s worth rewriting.
- The exclusions as a pinned Wiki page, which is what you point at when someone asks “didn’t you also handle X?”
- The slow dependency as a real task with a date in week one, not a line in a plan.
- “Done” as acceptance-criteria subtasks on the first deliverables.
The sixth — reading past retrospectives — depends on them existing and being findable, which is why archived projects keep their Wiki and comments. Ten minutes of searching a past project’s name is the highest-return use of a kickoff there is.
Terms used on this page
- Sponsor
- The person who funds the project and decides trade-offs the team cannot. The single strongest predictor of whether conflicts get resolved or absorbed. More →
- Exclusions
- The explicitly stated things a project will not deliver. The half of scope that settles disputes. More →
- Contingency
- Time or budget held in reserve for known uncertainty. What makes a week-nine surprise a decision rather than a crisis. More →
- Acceptance criteria
- The observable conditions a deliverable must meet before it is accepted. Written at the start, they make handover a formality. More →
- Lessons learned
- The reusable conclusions from a previous project. Worth ten minutes at every kickoff and almost never given them. More →
- Change request
- A recorded proposal to alter scope, schedule or cost, with its impact stated. The lightweight version is a sentence with a number in it. More →
Related reading
8.2 Lessons from Failed Projects
The same variables running the other way, and the warning signs that were available months earlier.
2.1 Project Initiation
Where the sponsor gets named and the charter gets written — two of the four decisive practices.
9.2 Practical Advice
More habits at the same scale: small, cheap, and disproportionately useful.