The central principles
Think slow. Act fast.
Think slow - before commitment
- Understand the real problem, not just the preferred solution
- Test assumptions before money is committed
- Benchmark against comparable projects, not internal estimates
- Build a detailed route map until the plan is genuinely testable
- Decide what not to do; keep options open during discovery
Act fast - once the plan is credible
- Mobilise quickly once uncertainty has been genuinely reduced
- Avoid long, drifting delivery phases that accumulate risk
- Execute with clear scope, authority, and cadence
- Deliver in controlled, repeatable, modular blocks
- Reduce exposure to inflation, politics, fatigue, and scope drift
The principles
The Fundamentals of Successful Change
A closer look at the principles
What each means, why it works, how to apply it
⌄
#
Principle
Why it works
Practical translation
1
FoundationThink slow, act fast
Most overruns happen once delivery starts. Careful planning moves discovery earlier, where mistakes are cheap.
Do not treat starting as progress. Treat validated readiness as progress.
2
PurposeAsk "why?" before "what?"
Many projects lock onto a preferred answer before defining the real problem.
Before choosing a system, supplier, or method, define the business outcome in plain language.
3
PlanningPlan one level deeper than feels comfortable
Vague plans hide risk. Detailed plans expose dependencies, gaps, and false assumptions.
Build the plan until the delivery team can explain exactly who does what, when, with what dependency, and what happens if it fails.
4
ForecastingUse reference-class forecasting
Comparable historical data is harder to fool than internal optimism and political pressure.
Ask: what did projects like this actually cost, how long did they actually take, and where did they actually fail?
5
GovernanceBeware the commitment trap
Once public commitment exists, people defend the decision rather than improve it.
Keep early stages exploratory. Do not announce hard dates until discovery, design, risk, and delivery capacity are credible.
6
DesignMake it modular where possible
Modular projects benefit from repetition, learning, parallelisation, and easier correction.
Prefer phased rollout, repeatable templates, pilots, controlled migrations, and standardised components.
7
DesignBuild with Lego, not wet concrete
Bespoke, irreversible work increases risk. Modular work lets the team learn and adjust.
In IT terms: configurable platforms, APIs, repeatable workflows, migration factories, standardised operating models.
8
ExecutionKeep the window of exposure short
Long projects accumulate risk from unknowns, market changes, politics, and scope drift.
Do the slow thinking before delivery. Then run delivery with urgency, cadence, and tight governance.
9
PeopleGet the right team early
Big projects are not won by generic optimism. They are won by pattern recognition.
Bring in people who know the traps: technical leads, delivery leads, change specialists, data migration experts, and commercial leads.
10
RiskTreat risk as real, not theoretical
Risk registers that do not affect decisions are theatre. Risk must change the plan.
For each major risk, define the mitigation, owner, trigger point, cost impact, and decision route.
11
ExecutionIterate before you scale
Small failures are useful. Large failures are expensive and political.
Pilot, prototype, dry-run, mock migrate, test integrations, run parallel processes, then scale.
12
MindsetAvoid "unique project" thinking
Calling a project unique is often an excuse to ignore evidence from comparable projects.
Find analogues. Even if the whole project is unusual, parts of it will have precedents.
13
IntegrityBe honest about politics and incentives
Optimism bias and strategic misrepresentation are core causes of bad forecasts.
Separate approval incentives from forecasting. Use external benchmarks. Reward truth early, not heroics late.
14
PlanningDecide late; prepare early
Premature certainty creates rework. But delayed preparation creates chaos.
Keep options open during discovery, but prepare the machinery of delivery in parallel.
15
FoundationDelivery success is designed, not wished
Success is not luck. It is the result of better planning and execution choices.
Governance, planning, data, sequencing, communications, and accountability are not admin overhead. They are the project.
Applied to Clarke Willmott IT
How these principles translate into a law firm technology programme
⌄
The lesson is not necessarily to 'be cautious'. The lesson is to front-load the thinking so delivery can move with confidence.
| Principle | Application to a law firm IT programme |
|---|---|
| Think slow, act fast | Spend serious time on discovery, data, workflow mapping, integration design, and business readiness before signing up to hard dates. |
| Reference-class forecasting | Ask vendors for actual implementation durations, cost profiles, data migration issues, adoption problems, and change-request volumes from comparable law firms. |
| Modularity | Break the rollout into distinct workstreams: data, finance, matter workflows, documents, integrations, reporting, training, and support model. Each can be sequenced, tested, and delivered independently. |
| Avoid premature commitment | Do not commit to a go-live date until data quality, integration scope, reporting needs, and process redesign are genuinely understood. |
| Prototype before scale | Run pilot matters, sample migrations, workflow prototypes, billing scenarios, and reporting mock-ups before full rollout begins. |
| Right team early | Involve finance, risk, compliance, the people who rely on IT, data, training, and vendor delivery people before design is frozen. Not as observers; as contributors. |
| Short execution window | Once design is locked and readiness is proven, move with tight cadence. A drawn-out, morale-sapping implementation is a risk in itself. |
| Evidence over optimism | Challenge vendor promises. Require examples, assumptions, exclusions, dependencies, and named responsibilities in writing, not just in a sales deck. |
Connection to Listen. Shape. Deliver.
How Thinking Slow and Acting Fast links to the first 90 days
⌄
My Listen. Shape. Deliver. model is that principle applied to the first 90 days in a new IT leadership role. The phases are not arbitrary; they are a deliberate sequence that front-loads thinking so delivery can move with confidence.
Think slow →
Listen
Days 1 to 30
the author principles in play
- Ask "why?" before "what?" - understand the real problem before forming any view
- Reference-class thinking - what does the landscape actually look like?
- Get the right people early - meet every team member and key supplier
- Make uncertainty visible - surface risks, gaps, and legacy decisions
- Avoid premature commitment - no hard positions until discovery is complete
Think slow →
Shape
Days 31 to 60
the author principles in play
- Plan one level deeper - validate findings into structured recommendations
- Be honest about politics and incentives - challenge assumptions, not just confirm them
- Decide late, prepare early - keep options open while building delivery readiness
- Treat risk as real - risks that do not change the plan are theatre
- Present options, not mandates - decisions stay where they belong
Act fast →
Deliver
Days 61 to 90
the author principles in play
- Keep the window of exposure short - execute with cadence and tight governance
- Iterate before you scale - fix foundations first, then quick wins, then strategy
- Build modular - workstreams that can be sequenced, tested, and corrected
- Delivery is designed, not wished - governance and sequencing are the work
- Evidence over optimism - progress reported honestly, not against fiction
The key difference between my approach and a typical 90-day plan is sequence. Most leaders arrive and start shaping on day one. I spend 30 days genuinely listening before forming a view, and 30 days validating before committing to delivery.
+
Further reading
The thinking behind the principles - available if you want to go deeper
⌄
The Core Model
Bad project behaviour vs. the the author approach, stage by stage
⌄
| Stage | Bad project behaviour | Optimal behaviour |
|---|---|---|
| Idea | "We need a new system." | "What outcome are we actually trying to achieve?" |
| Business case | Benefits inflated; costs softened; timelines made politically acceptable. | Use comparable projects, external challenge, and realistic contingencies. |
| Planning | Treated as delay. Pressure to "just get started." | Treated as the cheapest place to discover problems. |
| Design | Over-customised, bespoke, optimistic. | Modular, repeatable, testable, scalable. |
| Approval | Based on confidence and persuasion. | Based on evidence, assumptions, reference data, and delivery readiness. |
| Execution | Slow, exposed, constantly discovering new problems. | Fast, focused, with major unknowns already reduced. |
| Governance | Reports progress against a plan everyone knows is fiction. | Forces truth into the room early enough to act. |
Why Complex Projects Fail
The structural reasons large infrastructure projects overrun
⌄
High bespoke complexity
Every site, geography, regulatory environment, and stakeholder set can be different. Complexity compounds across every handoff.
Long delivery windows
More time for inflation, political change, legal challenge, supply-chain disruption, and leadership turnover to derail delivery.
Optimistic approval cases
Costs and timelines are routinely softened to get approval. The project is approved on fiction, then delivered in reality.
Late discovery
Ground conditions, regulatory issues, engineering complexity, or integration problems emerge after commitment, when change is most expensive.
Poor modularity
Unlike solar or repeatable manufacturing, many major projects are hard to standardise, so learning does not compound across phases.
Weak feedback loops
Lessons from one project are not transferred into the next because teams, suppliers, and political structures change between programmes.
What Made Successful Projects Different
Six factors that separated delivery from failure
⌄
Made uncertainty visible early
They did not confuse hope with a plan. Risks were surfaced and priced before commitment, not managed after it.
Used experienced judgement
They relied on people who had seen the movie before. Pattern recognition beats optimism in complex delivery.
Compared against reality
They looked at what similar projects actually cost and took, not what internal estimates or vendor promises suggested.
Simplified and standardised
They avoided unnecessary bespoke complexity. Standard components, repeatable methods, and familiar patterns reduced risk.
Protected execution
Once ready, they moved quickly. Short delivery windows meant less exposure to change, fatigue, politics, and cost drift.
Kept learning loops short
Small iterations corrected the path before failure became expensive. They did not wait for a phase to complete before asking whether it was working.
The bottom line
Big projects succeed when leaders refuse to confuse approval with readiness. They define the real objective, plan in detail, benchmark against reality, reduce unknowns early, modularise wherever possible, and then execute fast with experienced people and tight governance.