Project Management Leadership with AI · Execution, control, risk and quality · lesson 8 of 21 · 13 min

Leading execution: kickoff, cadence and RAID

From plan to action

Execution is where most of the budget is spent and where leadership matters most. The PM's job shifts from designing the plan to creating conditions for the team to deliver: clarity, rhythm, removal of blockers and fast decisions.

A strong kickoff

A kickoff aligns everyone on purpose, scope, roles and ways of working. Agenda (90–120 minutes):

Why this project matters (sponsor, 10 min).
Objectives, scope and exclusions (PM, 15 min).
Plan overview: milestones, lifecycle, key dates (15 min).
Roles and RACI; decision rights and escalation (15 min).
Ways of working: tools, meetings, definitions of done, communication norms (20 min).
Top risks and assumptions (15 min).
Questions and commitments (10 min).

Follow up with a short written summary and the working agreements.

Operating cadence

A predictable rhythm reduces coordination overhead:

| Cadence | Purpose | Participants | |---|---|---| | Daily (15 min) | Coordinate, surface blockers | Delivery team | | Weekly | Progress vs plan, look-ahead, RAID review | PM, leads | | Fortnightly / per sprint | Demo, retrospective, re-planning | Team, product owner, stakeholders | | Monthly | Governance: forecasts, exceptions, decisions | Board / steering committee |

The RAID log

A RAID log tracks Risks, Assumptions, Issues and Dependencies in one place.

Type | ID  | Description                                   | Owner     | Impact | Action / next step               | Due    | Status
R    | R07 | Vendor API may not support bulk export        | Tech lead | High   | Proof of concept by Sprint 3     | 12-Apr | Open
A    | A03 | Business users available 2 days/week for UAT  | PO        | Medium | Confirm with department heads    | 05-Apr | Validating
I    | I11 | Test environment down since Monday            | Infra     | High   | Escalated to IT ops; workaround  | Today  | Escalated
D    | D04 | Needs new CRM fields from CRM programme       | PM        | High   | Agreed delivery in CRM release 2 | 30-Apr | Tracking

Review it weekly. Issues need resolution owners and dates; dependencies need an owner on both sides.

Removing blockers and making decisions

Keep a visible blocker board; review daily.
Use a decision log: date, decision, rationale, who decided. This prevents re-litigating decisions.
Escalate early with options: "Here is the problem, here are three options with impacts, here is my recommendation."

Managing scope during execution

Changes will come. Use the agreed change process: log, assess impact, decide at the right level, update plans. In agile settings, new items go into the backlog and are prioritised by the product owner, with trade-offs visible.

Worked example

Illustrative. A fictional telecom company in Islamabad rolling out a new billing system had weekly meetings that ran 90 minutes and resolved little. The PM restructured: a 15-minute daily stand-up per workstream, a 45-minute weekly leads meeting focused only on RAID items marked high and the look-ahead, and a decision log. Within a month, the average age of open issues fell from three weeks to under one, and decisions stopped being revisited.

Leadership behaviours during execution

Be visible and accessible; walk the floor (physically or virtually).
Protect the team from noise and unplanned requests.
Recognise progress publicly; address problems privately and promptly.
Model calm under pressure; the team takes its cue from you.

Common mistakes

Kickoff as a slide presentation without discussion or agreements.
Meetings without purpose or outcomes.
RAID logs that grow but are never reviewed.
Escalating problems without options.
Allowing informal scope changes through side conversations.

Quick self-check

Look at your RAID log. How many issues are older than two weeks? How many dependencies lack an owner on the other side? Those two numbers are a quick health indicator for execution.

Adapting your leadership style

Execution leadership is not one style. With a new team or unfamiliar work, be more directive: clarify tasks, check progress frequently and explain decisions. As the team gains confidence, shift toward coaching and delegation, giving autonomy over how work is done while holding a clear line on outcomes. Situational leadership models describe this shift; the practical lesson is to match support and direction to each person's competence and commitment for the task at hand.

Hands-on: a RAID log with automatic flags (Excel)

Columns: A ID | B Type (R/A/I/D) | C Description | D Owner | E Next action | F Due | G Status | H Priority (H/M/L) | I Raised
J Age (days)     =IF(G2="Closed","",TODAY()-I2)
K Overdue        =IF(AND(G2<>"Closed",F2<TODAY()),"OVERDUE","")
L Weekly agenda  =IF(OR(H2="H",K2="OVERDUE",AND(G2<>"Closed",J2>21)),"REVIEW","")
Summary: open by type =COUNTIFS(B:B,"I",G:G,"<>Closed") ; median age of open issues =MEDIAN(IF((B2:B500="I")*(G2:G500<>"Closed"),J2:J500))

In Jira or Asana, create the same fields (type, owner, due, priority) and a saved filter for "priority = High OR due < today OR created < -21d" (syntax varies by tool).

Template: kickoff agenda (90 minutes)

1 Why this project matters (sponsor, 10 min)       2 What we will deliver and not deliver (15 min)
3 How we will work: lifecycle, cadence, tools (15)  4 Who does what: RACI for key decisions (15)
5 Top risks and assumptions (15)                   6 Ways of working and escalation (10)
7 First two weeks: actions, owners, dates (10)

Prompt template: meeting notes to actions (approved AI tool; record only with consent and per policy)

From the meeting notes below, produce: (1) decisions made (what, why, who), (2) actions (task, owner, due date),
(3) new or changed RAID items (type, description, suggested owner). Only include owners and dates that were stated;
otherwise write [OWNER?] or [DATE?]. Keep wording neutral.

The PM checks every item against their own notes before publishing.

How to measure success

Median age of open issues (target: under a week for high-priority items).
Share of RAID items with an owner and a date (target 100%).
Decisions reopened after being logged (target: rare, and only with new information).

Video lecture: Leading execution: kickoff, cadence and RAID

Lecture coming soon · 10 chapters · about 8 minutes. Read the full transcript below.

From plan to action
Why it matters
The concept: kickoff and cadence
The RAID and decision logs
Worked example one: turning an update into a decision
Worked example two: the Islamabad billing rollout
Watch me do it: a RAID log that manages itself
Removing blockers and managing scope during execution
Leadership behaviours and common mistakes
Recap and try this now

Lecture transcript

From plan to action

A telecoms company in Islamabad, a fictional one, was rolling out a new billing system. Every week, the project meeting ran for ninety minutes. Everybody gave an update. Nothing got decided. Issues sat open for three weeks on average, and decisions made one week were quietly reopened the next. The plan was fine. Execution wasn't. In this lecture you'll learn how to turn a plan into action: running a kickoff that aligns people, designing an operating cadence where meetings exist to decide rather than to report, keeping a RAID log and a decision log that people actually use, and removing blockers quickly. By the end, you'll be able to redesign your project's meeting rhythm so that issues get resolved in days, not weeks.

Why it matters

Why does this matter? Because plans don't execute themselves. Execution is where the project manager's leadership becomes visible: setting a rhythm, keeping attention on what matters, and removing obstacles faster than they accumulate. Meetings are the main tool, and also the main risk. Every hour in an unfocused meeting is an hour multiplied by everyone in the room, taken from delivery. And issues compound. An issue left open for three weeks doesn't just delay one task. It blocks the work that depends on it, creates workarounds, and erodes the team's belief that raising problems achieves anything.

The concept: kickoff and cadence

Here's the key idea: every meeting in your cadence should have a purpose, a timebox and an output. It starts with a kickoff: why the project matters, what we're delivering, how we'll work, who does what, and the ways of working, such as tools, meeting rhythm and escalation. Then the rhythm. Daily, a short stand-up per workstream, fifteen minutes, focused on progress towards this week's goals and blockers. Weekly, a leads meeting, perhaps forty-five minutes, focused only on high-priority RAID items, decisions needed and the look-ahead for the next few weeks. Monthly, board and exception reporting. Think of it like the rhythm of a well-run hospital ward: quick handovers every shift, a daily huddle for problems, and a weekly review for bigger decisions. Nobody reads out everything they did yesterday.

The RAID and decision logs

The RAID log is the backbone of execution: risks, which might happen; assumptions, which we're treating as true and must verify; issues, which are happening now; and dependencies, which we need from others. Every item needs an owner, a next action and a date. Otherwise it's a list of worries, not a management tool. Alongside it, keep a decision log: what was decided, why, by whom and when. That single habit stops decisions being quietly reopened, and it's invaluable when a new stakeholder asks 'why did we do it this way?'. In the weekly leads meeting, review only the high-priority items and anything that's gone stale, and escalate or close them. The log should shrink as much as it grows.

Worked example one: turning an update into a decision

Let's practise a small but powerful habit. In a status meeting, someone says: 'integration is delayed'. That's an update. The meeting could note it and move on, and next week it'll still be delayed. Instead, ask three questions. What decision do you need? From whom? By when? The answer: we need the tech lead to decide whether the two developers stop work on reporting to fix the API issue, today, because every day of delay pushes testing. The tech lead decides on the spot: prioritise the API fix, reporting slips a week, which is within tolerance. That goes into the decision log with the rationale, and the action goes into the RAID log with an owner and a date. Thirty seconds of structure turned an update into progress.

Worked example two: the Islamabad billing rollout

Back to the fictional telecoms company in Islamabad. The project manager restructured the rhythm. A fifteen-minute daily stand-up per workstream, focused on blockers. A forty-five-minute weekly leads meeting that looked only at RAID items marked high, decisions needed and the look-ahead for the next three weeks. And a decision log, reviewed at the start of each leads meeting. Within a month, the average age of open issues fell from three weeks to under one, and decisions stopped being revisited. Total meeting time actually fell. The difference wasn't working harder. It was designing meetings to decide things, and making the log, rather than people's memories, the record of what had been agreed.

Watch me do it: a RAID log that manages itself

Let me show you how I set up a RAID log so it largely manages itself. One table with a type column, R, A, I or D, then the description, owner, next action, due date, status, priority and date raised. Two calculated columns: age in days since it was raised, and an overdue flag when the due date has passed and the status isn't closed. Conditional formatting makes overdue items red. Then a saved filter for the weekly leads meeting: priority high, or overdue, or open for more than twenty-one days. That's the agenda, generated automatically. This works in a spreadsheet, in SharePoint lists or in tools like Jira or Asana with custom fields. Whatever the tool, the rule is the same: nothing without an owner and a date.

Removing blockers and managing scope during execution

A project manager's most valuable execution skill is removing blockers. When something's stuck outside the team's control, escalate early, with options rather than just a problem: here's the issue, here are two ways forward, here's what each costs, here's my recommendation. Protect the team's focus from interruptions and competing demands; you are, in part, a shield. And manage scope during execution. Small 'can you just' requests arrive constantly. Individually harmless, together they're a hidden change programme. Log them, estimate them and decide them in a weekly batch with the product owner or sponsor. That makes trade-offs visible and keeps the baseline honest without being bureaucratic.

Leadership behaviours and common mistakes

A few words on behaviour, because execution is leadership. Be visible and calm, especially when things go wrong; teams take their emotional cue from the project leader. Be consistent: the same questions, the same standards, every week. And adapt your style to the situation: more directive with a new team or in a crisis, more coaching as people build skill, and more delegation as they become confident. The common mistakes: status theatre, where meetings exist to report rather than decide; no decision log, so decisions keep reopening; heroics, where the project manager fixes everything personally and becomes the bottleneck; and hiding bad news until it's too late to act on.

Recap and try this now

Let's recap. Execution starts with a kickoff that aligns why, what, how and who. It runs on a cadence where every meeting has a purpose, a timebox and an output: short daily stand-ups, a weekly leads meeting focused on high RAID items and decisions, and monthly exception reporting. The RAID log gives every risk, assumption, issue and dependency an owner, an action and a date, and the decision log stops decisions being reopened. Remove blockers by escalating early with options, and batch small requests so scope stays visible. Your try-this-now: create a RAID log and a decision log for your current work, set up the high-or-overdue filter, and review both with your team this week.

Key takeaways

A strong kickoff aligns purpose, scope, roles, ways of working and risks.
A predictable cadence (daily, weekly, per sprint, monthly) reduces coordination cost.
Keep one RAID log and a decision log; review weekly and act on aged items.
Escalate early with options and a recommendation; manage change through agreed processes.

Try it

Create a RAID log and decision log for your current work and review them with your team this week.