About Execute
Anyone who has run more than a couple of projects will have noticed that two people given the same plan and the same resources tend to produce quite different outcomes. One of them ends up with something that has shipped. The other ends up with a longer story about why they almost did. This project is an attempt to understand why that happens.
Why this matters
In most organisations, strategy gets the attention and execution gets the blame when things go wrong. Anyone who has watched an ambitious plan turn into a long list of "almost finished" tasks knows the real bottleneck is rarely the plan itself. It tends to be everything that happens after the plan is written, in the daily work of producing the actual deliverable.
There is a real body of research on this. Peter Gollwitzer's work on implementation intentions stands out: people who specify in advance when and where they will act follow through far more often than people who only intend to. Locke and Latham, writing about goal-setting for almost fifty years, have shown that specific and difficult goals produce noticeably better outcomes than vague ones. Bossidy and Charan, in Execution, and McChesney and his co-authors, in The 4 Disciplines of Execution, describe what consistently delivering organisations actually do at the operational level. Most of this material sits in books and journals that the people doing the work do not tend to read.
Who this is for
The audience I have in mind is people who have noticed the gap between what they meant to do and what they actually got done, and who want to take it seriously instead of writing it off. That includes people running their own projects, people leading teams, and people who keep starting things they do not finish.
What this project will explore
- The concept of deliverable. What it actually means for a piece of work to be "done", and how to get clear about that early enough for it to matter.
- Finishing. Why the closing stretch of a project is so disproportionately hard, and how people who keep finishing things go about it.
- Working on the wrong thing. A large share of execution effort goes into work that should not have been started, or should have been stopped earlier. How to notice when you are in that situation.
- Avoiding mistakes. Which kinds of errors keep recurring in real delivery work, and what people who manage to avoid them seem to do differently.
Who maintains this
This project is maintained by KDA, mapper, builder, and writer. It draws on a decade of strategy work, on a long list of personal projects (some of which shipped, some of which did not), and on a continuing interest in why some people get things across the line so much more reliably than others.