Project Management
Making complex things move — and land.
Plans matter. So do people, dependencies, money, scope and the inconvenient things that happen after somebody has declared the plan complete. My approach is pragmatic: enough structure to know where we are, enough flexibility to change direction, and enough evidence to know whether we are actually making progress.
Project management without the theatre
I am not particularly interested in whether a programme calls itself Agile, Waterfall, Scrum, Kanban or something invented during the last transformation workshop.
I am interested in whether we know what we are delivering, what has to happen first, who is doing it, what it costs and whether it works.
Methodology is useful. Delivery is the point.
The delivery journey
|
DEFINE What are we actually delivering? |
→ |
PLAN Products, work, people and dependencies. |
→ |
DELIVER Let teams get on with it. |
→ |
PROVE Evidence that it actually worked. |
Start with the product
I generally start with a Product Breakdown Structure (PBS) rather than immediately producing a heroic Gantt chart. It forces a more useful question than simply asking what tasks we need to do:
What products must exist for the outcome to be achieved and accepted?
In PBS terms, a product is not only the final business outcome. It includes the tangible components and the enabling artefacts needed to create, prove, operate and accept it.
A migrated service, for example, may be the headline product. Underneath it sit other products: configured environments, migrated data, interfaces and reports, but also the design specifications, mappings, migration code, test scripts, reconciliation evidence, runbooks and acceptance records needed to get it there.
The distinction I find useful: the end product is what the project ultimately delivers; component and enabling products are what must exist to build it, control it, prove it and make it operational.
Once those products are visible, the work, estimates and dependencies become much easier to see. It also gives governance something tangible to measure. A completed and accepted product is rather more convincing than “Task 437 is 73% complete”.
|
PBS What must exist? |
→ |
WBS What work creates it? |
→ |
PLAN When & who? |
→ |
DELIVERY Is it complete and accepted? |
| Product level | Examples |
|---|---|
| End product | Live migrated service, operational data platform, implemented business capability. |
| Component products | Configured environments, migrated datasets, integrations, reports, security roles and operational processes. |
| Enabling products | Designs, mappings, code, test scripts, reconciliation reports, runbooks, training material and acceptance evidence. |
Minimum Viable Product
MVP is useful until it becomes shorthand for the smallest thing we can get away with.
For me, an MVP is the smallest coherent product that delivers something useful, can be tested in the real world and teaches us enough to make the next decision.
A sensible MVP:
- does something genuinely useful;
- protects the critical outcome;
- makes compromises visible;
- provides something we can learn from;
- doesn't quietly move essential scope into somebody else's future problem.
Agile or Waterfall? Yes.
I don't see delivery methods as competing religions. Different levels of a programme need different levels of control. A migration can have fixed governance and cutover milestones while the teams underneath it work perfectly happily in two-week Sprints.
Milestones • dependencies • cost • governance
|
Gantt / Plan When things need to happen |
Jira / Kanban What is actually moving |
Scrum How teams deliver |
Estimating: the same old questions
Scrum changes how work is organised. It does not make the traditional questions disappear.
| How much? | How long? | When will it finish? | What will it cost? |
One simple approach I use is three-point estimating: best case, most likely and worst case. The interesting bit is often not the resulting number but discovering why one person thinks something takes two days and another thinks it takes three weeks.
|
BEST CASE Things go well |
MOST LIKELY The realistic view |
WORST CASE Things do not |
Planning is useful. Reality retains a veto.
Dependencies matter
If Task B cannot start until Task A produces something, I would rather show that relationship explicitly than have somebody manually move dates around every Friday.
The same applies to constrained resources. The point of a plan is not to create the world's largest Gantt chart. It is to understand what moves when something else moves.
Governance should help
Governance should make delivery easier to understand and easier to correct. It should not merely create another meeting where everybody agrees that red is actually amber-red.
The practical toolkit is fairly ordinary: PBS, WBS, RAID, estimates, dependencies, decisions, change control, cost, schedule and acceptance criteria. The value comes from using them to make decisions rather than simply collecting them.
Evidence rather than optimism
Where the programme warrants it, Earned Value gives a simple objective view:
|
PV Planned Value What should be done? |
EV Earned Value What is actually done? |
AC Actual Cost What did it cost? |
Variance isn't automatically failure. It is information. Understand the cause, understand the consequence and make a decision.
When the plan goes wrong
Distressed programmes rarely need a prettier status report. They need enough structure to establish what is true.
I normally start with six questions:
- What genuinely exists?
- What is incomplete?
- What is on the critical path?
- Which assumptions have become dependencies?
- What decisions are waiting?
- What can be simplified without breaking the outcome?
|
ESTABLISH What is true? |
→ |
PRIORITISE What matters now? |
→ |
DECIDE What changes? |
→ |
RECOVER Get moving again. |
In short
Structure where structure helps.
Agility where agility helps.
Evidence everywhere.
The objective is not to prove that we followed the methodology. It is to deliver something useful, understand the compromises we made, and be able to demonstrate that it works.