WBS & Phases
Four columns you type. The rest is arithmetic.
A new project arrives with 88 tasks already written across seven phases and tagged to twelve workstreams — Financials, OTC, PTP, Mfg/WMS and Cross-Module carry the module work, alongside Mobilization, Training, Go-Live and the rest. You are editing a plan, not building one.
- Task / Deliverable — the seeded wording, which you are meant to trim. Deleting what does not apply is the expected first move.
- Base Hrs — the methodology's estimate for a typical client.
- Scope× — your multiplier for this one. 1 is typical; 1.5 is half again as much work; 0.5 is a client who already has it.
- % Complete — the single completion signal. No parallel status field to drift out of sync.
Discovery
Kickoff and charter, current-state review, gap analysis, requirements confirmation.
Design
Chart of accounts, process design by workstream, integration and migration mapping specs.
Build
Configuration, customisation, integrations, draft data loads.
Test
UAT scripts executed, defects triaged P1 to P3, rework and retest, dress rehearsal.
Training
Train the trainer, end-user sessions, runbooks and quick-reference guides.
Go-Live
Cutover, final loads, reconciliation, the go/no-go decision and switch-on.
Post Go-Live
Hypercare, defect burn-down, responsibility handover, closure.
Timeline
A Gantt you did not have to draw.
The timeline lays itself out from the phase plan and the task hours. Workstreams inside a phase run in parallel, the way they actually do, rather than in one long queue.
Not started
Grey. Nothing has been typed against it yet.
In progress
Dark green fill against a lighter bar, showing the percent complete you typed.
Complete
Solid green. Nothing left to do on the row.
Overdue
Red. Past its finish date and not at 100%.
RAID Log
One log. Four kinds of thing that bite.
Risks, assumptions, issues and dependencies in a single register, because they convert into one another constantly and splitting them across four tabs loses the thread.
| Field | What goes in it |
|---|---|
| Type | Risk, Assumption, Issue or Dependency |
| Impact | High, Medium or Low — scored 3, 2, 1 |
| Probability | High, Medium or Low — scored 3, 2, 1 |
| Score | Impact × probability, so 1 through 9. A 9 is high and likely. |
| Owner | A person, not a team |
| Raised / Due | Dates, so age is visible |
| Mitigation | What is being done about it |
| Status | Open, Mitigating, Closed or Accepted |
Accepted is a real answer
Most registers only let a risk be open or closed, which pushes teams into closing things that are not resolved. A risk you have looked at, priced and decided to live with is Accepted — still visible, no longer chased.
It drives the client report
An open risk scored high on both axes pushes the weekly report to amber on its own. Three or more open issues does the same. You can override the colour, but you have to do it deliberately.
Decisions get their own record
The Issues & Decisions tab is a dated, numbered log kept separately from RAID, because a decision is not a problem and you will want to find it in month nine without filtering past a hundred closed risks.
Load your plan and see it laid out.
Every tracker takes a CSV. Bring the plan you have now and look at it as a timeline, a budget and a readiness score in the same afternoon.