Gates, boards and reports: the machinery that turns project data into decisions executives can actually make.
Big idea · Flow
The three I's
Ep 001 · Grant Stead
A ladder for executive reporting: each rung is worthless to a leader without the one above it.
Information · the raw data
Estimates · timesheets · quantities
→
Insights · "your PF is a 0.8"Rolled up · drillable · owned
→
Interventions · the options"The only thing that makes money": hold $90M and cut scope, or accept $100M: a decision framework, not a chart
A ladder for executive reporting: raw information (estimates, timesheets, quantities) rolls up into insights like 'your PF is a 0.8,' but each rung is worthless to a leader without the one above it. The top rung is interventions: concrete options such as holding $90M by cutting scope versus accepting $100M. Intervention is the only rung that makes money; it is a decision framework, not a chart.
Credited on air (~47:00–52:00) to a mutual friend now at Cenovus Energy
See it in contextFrom ep 001 · Grant SteadAlso filed under Leadership
Big idea · Bridge
Basics before the dashboards
Ep 002 · Jovita Stander
The shiny layer only works if the boring layer underneath is right. Jovita’s order of operations for any new program, and her caution for the AI era.
The boring layer (first)
- One project calendar, common cutoff dates
- Sense-check the week-over-week deltas
- Gut nagging? Go back to the source
- Golden thread: weekly → monthly → yearly
- Routine, repeated every 30 days
Order of operations
Garbage in · garbage out
The shiny layer (after)
- PMIS platforms & dashboards
- S-curves, infographics, storytelling
- AI tooling: amplifier, not fixer
- Faster, accurate data for decision makers
Get the boring layer right first: one project calendar, common cutoff dates, sense-checked week-over-week deltas, and a golden thread that lets a monthly report deconstruct cleanly into its weeks. Only then layer on the shiny stuff (PMIS platforms, dashboards, S-curves and AI), because those tools amplify whatever sits beneath them: garbage in, garbage out.
From the conversation, ~45:28–54:00 · “start with the basics… then go for the dashboards”
See it in contextFrom ep 002 · Jovita StanderAlso filed under Data & AI
Big idea · Bridge
Project success = PM success + product success
Ep 008 · Akin Oni
The iron triangle measures the operation. Akin’s 2006 paper title carries the warning (“The Operation Was Successful, But the Patient Died”) and his definition completes the equation.
Project management success
- On scope, on schedule, on cost
- The operation was successful
- What the triangle can see
Project success
Only when you have both
Product success
- Value delivered, benefits realized
- The patient is alive
- What the triangle can’t see
The iron triangle (on scope, on schedule, on cost) only measures project management success: the operation was successful. Product success asks whether the patient is alive: value delivered and benefits realized. True project success requires both, the equation at the heart of Akin's 2006 paper that Ed Merrow circulated across IPA.
From the episode, ~45:45–47:30 · and his 2006 paper, circulated by Ed Merrow across IPA
See it in contextFrom ep 008 · Akin OniAlso filed under Reference
Big idea · Matrix
The three shapes of a PMO
Ep 011 · Ahmed AbdelSalam
Same three letters, three completely different animals, distinguished by how involved the PMO is, and who answers for delivery.
AdvisoryReports and templates from outside the work. Not involved, doesn’t know the risks, and its templates often go unused. “I’m not a big fan.”
SupportingExperts embedded in delivery: cost, schedule, risk, procurement working hand in hand with the PM, who stays accountable. His preferred shape.
ControllingDelivery teams report into the PMO; one team answers for the entire program. A single point of accountability, if the leaders have the experience to carry it.
← lighter touch · · involvement & accountability · · full control →
Ahmed sorts PMOs into three types along one axis: how involved the office is and who answers for delivery. Advisory PMOs push reports and templates from outside the work and usually fail; supporting PMOs (his preferred shape) embed cost, schedule, risk and procurement experts alongside a project manager who stays accountable. Controlling PMOs take full accountability as the client's single answerable team, which works only if the leaders have the experience to carry it.
From the PMO chapter, ~34:50–41:00
See it in contextFrom ep 011 · Ahmed AbdelSalamAlso filed under Leadership
Big idea · Flow
The misdiagnosis loop: it’s never just the people
Ep 014 · Ellie Moradinezhad
When integration fails, every faction blames a different single cause, because blaming others is the simplest move. Ellie’s ERP case study shows what happens when someone finally root-causes the combination instead.
“Wrong people on deck”
“The old system was better”
“The procedures don’t fit us”
→
Root-cause analysisInterviews · workshops · private conversations · data
→
Fix the combinationTraining + procedures + system configuration, together: “if you fix three of them, you get much better results.”
When integration fails, every faction blames a different single cause (the people, the old system, the procedures) because blaming others is the simplest move. Ellie's ERP case study runs those complaints through real root-cause analysis (interviews, workshops, private conversations, data) and lands on fixing the combination instead: training, procedures, and system configuration together, which gives much better results.
From the ERP case study (~25:30–29:10) and the buy-in discussion (~29:30–33:45)
See it in contextFrom ep 014 · Ellie MoradinezhadAlso filed under Leadership
Big idea · Bridge
An approval system and a decision-making system are not the same building
Ep 017 · Iwona Wilson
Two organizations can hold identical process documentation and be doing completely different things with it. What separates them is not the framework: it is the set of capabilities that make the framework mean something. That set is what almost nobody buys, teaches or measures.
An approval system
- Phases and gates on a wall chart
- Templates and guidelines
- Approval lists and mandatory checklists
- Deliverable status as the gate conversation
- The question is: can we pass?
Capability
The missing span
A decision-making system
- Thinking through uncertainty
- Framing opportunities before they’re projects
- Aligning stakeholders across functions
- Naming and challenging assumptions
- The question is: is this a good decision?
Two organizations can hold identical stage-gate documentation and be doing completely different things with it. An approval system asks 'can we pass?' through templates, checklists, and deliverable status; a decision-making system asks 'is this a good decision?' by thinking through uncertainty, framing opportunities before they're projects, aligning stakeholders, and challenging assumptions. The span between the two is capability, the thing almost nobody buys, teaches, or measures.
From Iwona’s answer at ~1:33–1:35 · “having a process in place is not the same as having capabilities”
See it in contextFrom ep 017 · Iwona WilsonAlso filed under Careers & Talent
Big idea · Bridge
Simpler systems produce better data
Ep 024 · Hannah Garrett
Leadership buys the system that tracks every data point; the delivery team begs “no new tools, please.” Both are describing the same failure.
The overly robust system
- Tracks everything, so it asks for everything
- Every project decides again how to run a meeting or take notes
- “A bunch of data that never gets updated”
Simplify the system, get better data
One standard for everything that should be standard
The simple central system
- Studs before drywall: the standard never changes, the drywall can
- Painless to update, so it gets updated
- Energy left for the decisions that need judgment
The devil’s-advocate question from the project-controls side of the table is whether documenting everything is exactly how bureaucracy is born. Hannah’s answer: standardize everything that should be standard (one way to hold a meeting, one way to take notes) so people keep their energy for what genuinely requires judgment, and keep the system simple enough that it actually gets updated. An overly robust system that tracks every data point produces data nobody maintains; a simpler one produces better data. Structure, with a little flexibility.
From the conversation · “if you simplify the system, you’re going to get better data” (~33:10) · the studs-and-drywall rule (~27:05) · “create a standard for everything that should be standardized” (~25:39)
See it in contextFrom ep 024 · Hannah GarrettAlso filed under Data & AI
Big idea · Bridge
The efficiency inversion
Ep 026 · Ahmed Abdelfattah
More roles, more tools, more data, and in his observation a less efficient process, because the department optimizes itself instead of the project.
2008 · One planner, P3
- One planner (maybe two) per project
- Primavera P3, the only main tool
- A direct line to the project manager’s decision
- The schedule seen as “a wonder of the project”
More roles, less decided
The inversion
Now · The five-role department
- Scheduler, planner, controls manager, risk manager, reporting manager
- Focused “on the process itself”
- “A separate business other than the project management”
- His verdict: “less efficient than the past”
Ahmed’s opening observation from nearly 20 years in the discipline. In Egypt between 2008 and 2010, a project got one planner with Primavera P3, the schedule was “a wonder of the project,” and the planner had a direct line to the project manager’s decision. Today the same job is a department: scheduler, planner, controls manager, risk manager, sometimes a reporting manager. That department works to improve its own process, competing to be the best in the discipline, rather than working toward the completion date, the quality, or the purpose of the project. One apple against ten apples, and in his observation the ten are less efficient.
From the conversation · “like you are comparing one apple to 10 apples” (3:46) · “now we are focusing more on the process itself” (4:27) · “a separate business other than the project management itself” (5:13)
See it in contextFrom ep 026 · Ahmed AbdelfattahAlso filed under Schedule
Big idea · Bridge
Two reports, two purposes
Ep 026 · Ahmed Abdelfattah
What a document is for decides everything about it. Confuse the two and a controls team polishes pages nobody reads while the executive waits for the one report that needed building by hand.
Project records
- Daily, weekly, monthly: the contract record
- Drawings, approvals, claims, change orders, instructions
- Systematic, so month compares to month
- “Nobody reads it, but it’s still important”
Rename the monthly report a monthly record
then spend the effort here
Decision reports
- Executive, scenario and focus reports
- No template, ever
- Built on the reader’s time, purpose, background, even insecurities
- A story that ends with a conclusion
Reporting is two jobs that most controls teams blur together. The first is the contract record: monthly and weekly reports logging drawings submitted, approvals, claims, change orders and instructions received. They are systematic and templated, nobody reads them, and they still matter, so Ahmed would rename them monthly records. The second is the decision report (executive, scenario and focus reports), which is what clients actually pay project management for. It has no template, because it is built on how one person will perceive the information: their time limitation, purpose, background, even their insecurities, shaped into a story that ends with a conclusion.
From the conversation · “instead of monthly reports, we can say like monthly record” (36:47) · “there is no template” (37:36) · “a story that ends with a conclusion” (41:11)
See it in contextFrom ep 026 · Ahmed AbdelfattahAlso filed under Document Control
