Project Management Support
Projects fail on governance far more often than on technical grounds. The technology usually works; what goes wrong is that nobody owns the decision, the status report says amber for four months, and the sponsor discovers the true position when the deadline arrives. Independent oversight is uncomfortable precisely because it surfaces that earlier.
1
Establish
Governance and roles
2
Baseline
Scope, cost, schedule
3
Track
Progress and risk
4
Report
Honest status
5
Close
Benefits and lessons
How We Support Projects
01
Establishing Governance
Before anything else, who decides what. Most project delay is decision delay, and projects without a named sponsor holding authority stall at the first choice that costs money.
- Sponsor named with defined authority
- Steering committee mandate and membership
- Decision rights and escalation thresholds
- Reporting cadence and format agreed
02
Baselining
A scope, cost and schedule baseline that changes only through change control. Without one, scope creep is invisible because there is nothing to compare against.
- Scope defined including what is explicitly excluded
- Cost baseline with contingency identified separately
- Schedule with dependencies and critical path
- Change control process agreed before work starts
03
Tracking and Risk Management
Progress measured against deliverables rather than against effort expended. Percentage complete based on time spent is the single most misleading metric in project reporting.
- Progress measured against completed deliverables
- Risk register maintained with owners and mitigations
- Issues escalated against defined thresholds
- Dependency tracking across workstreams and suppliers
04
Independent Assurance Reporting
Status reported honestly, including when it is unwelcome. A project running amber for months without escalation is a governance failure rather than a delivery one.
- Status reported independently of the delivery team
- Amber and red status escalated rather than carried
- Realistic forecast to completion
- Variance against baseline quantified
05
Closure and Benefits
Projects rarely close properly. Benefits go unmeasured, lessons go unrecorded, and the same mistakes repeat on the next one because nobody wrote down what happened.
- Formal closure against the agreed scope
- Benefits measured against the original business case
- Lessons documented and circulated
- Handover to operational ownership confirmed
What You Receive
- Governance structure with named sponsor and decision rights
- Scope, cost and schedule baseline with change control
- Risk and issue register with named owners
- Independent status reporting against the baseline
- Forecast to completion updated as evidence changes
- Closure report with benefits measured and lessons recorded
Indicative Timeline
An assurance review takes one to three weeks. Ongoing project management or PMO support runs for the life of the project, with governance established in the first two to three weeks.
- Governance establishment: one to two weeks
- Baselining: one to two weeks
- Ongoing tracking and reporting: project duration
- Assurance review: one to three weeks as a standalone
How We Engage
Different levels of involvement suit different situations and different project sizes.
PMO Setup
Establishing the office, templates and reporting discipline for organisations running several projects.
Project Management
Running a specific project where you lack the capacity or the independence internally.
Assurance Reviews
Independent point in time review of whether a project is where its status report claims.
Recovery
Assessment and replanning of a project already in difficulty, which needs candour more than method.
Steering Support
Preparing packs and providing an independent view to a steering committee.
Closure
Formal closure, benefits measurement and lessons capture, routinely skipped.
Frequently Asked Questions
Why use an external project manager?
Usually for capacity or for independence. An internal manager reporting to the sponsor whose project it is finds honest red status difficult, and that difficulty is exactly what allows problems to persist unreported.
What is a project assurance review?
An independent check on whether a project is actually where it says it is. It examines evidence of completion rather than accepting status reports, and it commonly finds progress overstated, usually without any intent to mislead.
Our project is already in trouble. Can you help?
Yes, and recovery work is common. The first step is an honest reassessment of position, scope and remaining cost, which is frequently unwelcome. Recovery based on an optimistic restatement fails a second time.
Do you manage technical projects?
We manage the project rather than perform the technical work, coordinating your specialists or suppliers. Where the project is a system we are also building, we would flag that we are then assuring our own delivery.
What size project justifies this?
Anything where failure would materially hurt, or where several workstreams and suppliers have to coordinate. Small single team projects rarely need formal governance and adding it wastes effort.
Why do projects fail?
Unclear ownership, scope that expanded without anyone deciding to expand it, and status reporting nobody challenged. Technical failure is comparatively rare, and it is usually the visible symptom of one of those three.
Related Services
This sits inside our Consulting practice. Related work: Custom Software and App Development where the project is a system build, and Cloud Migration and Infrastructure for infrastructure programmes.
