Project management without the certification theatre

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.

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.