# Project management without the certification theatre

*Scope, estimates and the difficult conversation you are avoiding, which is the whole job.*

## Production summary

- Modules to record: 2
- Total script: 1249 words, about 8 minutes of finished audio
- Voices: Amara (host) and Nadia (practice educator)
- Level: New and accidental project managers

## Accreditation wording that must appear in the description

- **The CPD Certification Service** (planned): Application scheduled.

> Do not upgrade any of these words in a description or a thumbnail. Aligned is not accredited, and planned is not approved.


---

## Scope, estimates and the amber that lasted four months

**Runtime** about 4 minutes. **Words** 616. **Starts at** 00:00 in the full course recording.

### Learning outcomes to state on camera

- Write scope that makes change visible
- Estimate in ranges and communicate uncertainty honestly
- Run status reporting that surfaces problems early
- Escalate before it is a crisis

### Script


`[CUE 1]` *Eight small changes absorbed quietly, with the delivery date silently moving.*

**AMARA**  [00:00]
I inherited a project that is already late and I have no certification.

**NADIA**  [00:05]
Which puts you in the majority. Most projects are run by people who were good at something else, and most project failure has nothing to do with methodology.

**AMARA**  [00:16]
What does it come from?

**NADIA**  [00:18]
Three things. Scope nobody agreed. Estimates nobody believed. And a status report that said amber for four months and then said red two weeks before the deadline.

**AMARA**  [00:29]
Scope creep.


`[CUE 2]` *The displacement sentence forcing a visible trade decision.*

**NADIA**  [00:30]
Except scope creep is not the problem, and this is where most advice goes wrong. Scope changing is normal and usually correct. The world moved, or somebody learned something.

**AMARA**  [00:41]
So what is the problem?

**NADIA**  [00:43]
Scope changing invisibly. Absorbed quietly by a team who did not want to seem difficult, until the original date arrives and the work is not done, and nobody can point at when it went wrong.

**AMARA**  [00:57]
So how do I stop absorbing things?

**NADIA**  [01:00]
One sentence. Yes, and here is what that displaces.


`[CUE 3]` *Single number estimate hardening into a commitment across three meetings.*

**AMARA**  [01:04]
That is it?

**NADIA**  [01:05]
That is it, and it does an enormous amount of work. It does not say no, so you are not obstructive. And it forces the conversation about consequence that everybody was avoiding, with somebody who actually has the authority to make the trade.

**AMARA**  [01:22]
Estimates. I get asked how long and I have to say something.

**NADIA**  [01:27]
Then say a range with a confidence, because a single number is a lie. Give one and it is heard as a commitment, and every conversation after that treats it as one.

**AMARA**  [01:40]
People hate ranges. They want a date.


`[CUE 4]` *Three point estimate with the resolution date attached.*

**NADIA**  [01:42]
They want certainty, which does not exist, so give them something better. Six to ten weeks. Six if the data is as clean as we have been told, ten if it is not, and we will know within a fortnight.

**AMARA**  [01:58]
The last bit is the useful part.

**NADIA**  [02:01]
It is the whole thing. It converts uncertainty into a scheduled decision point instead of an argument. Nobody can be annoyed with a range that comes with a date for resolving it.

**AMARA**  [02:14]
Should I estimate for my team if they are busy?

**NADIA**  [02:18]
Never. Manager produced estimates are consistently optimistic, and worse, the people doing the work do not own them. Then when it slips it is your number, not theirs, and nobody is accountable.


`[CUE 5]` *Watermelon status: green outside, red inside, then red two weeks out.*

**AMARA**  [02:31]
Status reporting. Ours is amber constantly.

**NADIA**  [02:33]
Watermelon reporting. Green on the outside, red in the middle. And amber for months is the most dangerous status there is, because it sounds like it is being managed.

**AMARA**  [02:45]
Why does everybody do it?

**NADIA**  [02:47]
Because red is treated as a confession rather than as information. In a culture that punishes red, you get green reports right up until delivery fails, and then everybody is surprised.

**AMARA**  [02:59]
So what do I write instead?


`[CUE 6]` *Escalation with problem, options, consequences and a recommendation.*

**NADIA**  [03:02]
Report against a specific dated commitment. Not amber, some challenges. Instead: we committed to migrating forty records a day, we are achieving twenty two, and at that rate we finish three weeks late.

**AMARA**  [03:15]
That is much harder to ignore.

**NADIA**  [03:17]
It is impossible to ignore, and that is the point. It is also much harder to blame you for, because you have given a number and a forecast rather than a mood.

**AMARA**  [03:30]
Last thing. Escalation feels like admitting I cannot cope.

**NADIA**  [03:34]
Which is why people wait, and by the time they escalate all the good options have gone. Escalate when a decision is needed above your authority, when a risk has actually materialised, or when you need something you cannot get yourself.

**AMARA**  [03:50]
How do I do it without looking like I am struggling?

**NADIA**  [03:54]
Bring the problem, the options with their consequences, and your recommendation. That turns you from somebody bringing a problem into somebody bringing a decision. Same escalation, completely different impression.

### Sources for the on screen credit

- APM Body of Knowledge, Association for Project Management
- Government Functional Standard for project delivery, Infrastructure and Projects Authority
- Estimation and forecasting research literature, International Journal of Project Management

---

## Risk, dependencies and the people problem

**Runtime** about 4 minutes. **Words** 633. **Starts at** 04:06 in the full course recording.

### Learning outcomes to state on camera

- Write a risk that can be acted on rather than logged
- Manage dependencies you do not control
- Run a stakeholder map that changes what you do
- Close a project properly, including the benefits nobody checks

### Script


`[CUE 1]` *A vague risk rewritten as cause, event and effect, generating an action.*

**AMARA**  [04:06]
Our risk register has eleven items and none of them have moved in four months.

**NADIA**  [04:12]
Then it is furniture, and it is doing nothing except making somebody feel governed. What do the entries look like?

**AMARA**  [04:20]
Things like resource availability, with a red dot.

**NADIA**  [04:23]
Which cannot be acted on by anybody. A usable risk has three parts: a cause, an event and an effect.

**AMARA**  [04:31]
Rewrite that one for me.


`[CUE 2]` *The test question: what would you do differently tomorrow if you believed this.*

**NADIA**  [04:33]
Because the migration depends on one person who is also running month end, there is a risk that migration testing slips, which would delay go live by two to three weeks.

**AMARA**  [04:46]
That one I could actually do something about.

**NADIA**  [04:49]
And you immediately know what: get a second person trained, or move the testing window away from month end. The rewrite generated the action by itself.

**AMARA**  [04:59]
Is there a test I can apply?

**NADIA**  [05:02]
One question. What would you do differently tomorrow if you believed this? If the answer is nothing, it is not a risk, it is a worry, and it should not be on the register clogging it up.


`[CUE 3]` *Dependency log with owner, date needed, and what happens if it does not arrive.*

**AMARA**  [05:17]
What about accepting risks? That feels like giving up.

**NADIA**  [05:20]
It is a legitimate answer and it is badly underused. Avoid, reduce, transfer, accept. What matters is that accept is a recorded decision with a name against it, rather than a silence that later looks like nobody noticed.

**AMARA**  [05:36]
You said dependencies are where projects actually fail.

**NADIA**  [05:39]
Almost always. Your own work is the part you control, and it is rarely what sinks you. It is the other team's deliverable, the approval sitting in an inbox, the supplier who was always going to be four weeks.

**AMARA**  [05:54]
So what do I record?


`[CUE 4]` *A dependency agreed three months ago decaying through two reorganisations.*

**NADIA**  [05:56]
Three things for every dependency. Who owns it. What date you need it. And what you will do if it does not arrive.

**AMARA**  [06:06]
That third one is unusual.

**NADIA**  [06:08]
And it is the one that turns a dependency log into something useful rather than a list of hopes. If you cannot answer it, you have not got a plan, you have got an expectation.

**AMARA**  [06:22]
Anything else?

**NADIA**  [06:22]
Re confirm as the date approaches. Somebody agreed in a meeting three months ago, and since then they have had two reorganisations and a new priority. That dependency is not confirmed, it is remembered, and those are very different things.


`[CUE 5]` *Stakeholder grid with the enthusiastic corner overserved and the blocker ignored.*

**AMARA**  [06:38]
Stakeholders. We have a list.

**NADIA**  [06:40]
A list achieves nothing. Sort them by how much the project affects them against how much influence they have, and then say what you will do differently for each group.

**AMARA**  [06:52]
Where do people go wrong?

**NADIA**  [06:54]
They spend all their time with the enthusiastic people, because that is pleasant, and none with the person who can stop it. And then they are stopped, usually late, usually publicly.

**AMARA**  [07:07]
Who gets ignored?


`[CUE 6]` *Benefits review date set at kickoff and firing six months after go live.*

**NADIA**  [07:08]
Low influence, high interest. Which is very often the people who will actually use the thing you are building. They cannot stop you, so they get overlooked, and then adoption fails and everybody is surprised.

**AMARA**  [07:22]
Last thing. Closing down.

**NADIA**  [07:24]
Closure is not the go live date. It is handover to whoever runs it now, documentation somewhere findable, outstanding issues transferred with owners, and your resources released.

**AMARA**  [07:34]
And you said there is a bit nobody does.

**NADIA**  [07:38]
Checking whether the benefits happened. Projects get justified with a benefits case and closed at delivery, so nobody ever asks whether any of it materialised.

**AMARA**  [07:48]
Which means?

**NADIA**  [07:49]
Which means organisations repeat expensive mistakes indefinitely, because nothing ever taught them it was a mistake. Set a benefits review date at the start, three or six months after go live, in the calendar of somebody who will still be there. Measure the thing you said would change. And publish the answer even when it is uncomfortable.

**AMARA**  [08:12]
Especially then, presumably.

**NADIA**  [08:13]
Especially then. An organisation that only publishes the successes is training itself to believe everything works.

### Sources for the on screen credit

- APM Body of Knowledge, risk and stakeholder management, Association for Project Management
- Government Functional Standard for project delivery, Infrastructure and Projects Authority
- Benefits management guidance, Infrastructure and Projects Authority

---

*Copyright WAJD Group. Built by WAJD AI.*