Technical program management fundamentals

A project manager is accountable for delivering a defined scope to a plan, and the plan is largely the deliverable. A TPM is accountable for an outcome that spans several teams none of which they manage, and the deliverable is a decision rate: dependencies resolved, sequencing agreed, risks surfaced early enough to act on. The technical part is not decoration. A TPM has to read a design document well enough to know that two teams have agreed on an interface in words but not in behaviour, and to notice that a milestone described as done has never been exercised. Take that technical judgement away and the role collapses into status collection, which is the version of it that gets eliminated in reorganisations.

The engineering manager owns the people, the technical quality and how their team's work gets done. The TPM owns the cross-team outcome, the sequencing between teams, and the risk picture. In practice the boundary is tested constantly, because a program slipping usually has a cause inside a team. The rule that holds is that a TPM raises the symptom and its delivery consequence, and the manager chooses the remedy inside their team. A TPM who starts reassigning engineers or arbitrating code review disputes has taken over a job they will do worse and lost the neutrality that made them useful. The failure in the other direction is a TPM who reports a team as late for three weeks without asking why.

A project has one scope, one plan and one end. A program is a set of projects and ongoing workstreams pursued together because they share an outcome, and the coordination between them is where its value and its cost both live. The practical differences are that a program has no single backlog, its parts have different cadences, and it usually has parts that are not projects at all — a compliance obligation, an ongoing migration, a vendor relationship. That is why program planning is about interfaces and sequencing rather than tasks, and why a program plan that looks like one very large project plan is usually a sign nobody has identified the joins.

A dependency is work you need from someone else: their API, their sign-off, their data migration. It has an owner you can talk to and a date you can negotiate. A constraint is a limit you cannot negotiate inside the program — a regulatory deadline, a shared environment that takes one change per week, a frozen budget, four engineers and no more. The distinction matters because the responses differ completely. You manage a dependency by agreeing an interface and a date and then verifying progress against it. You plan around a constraint, because pushing on it wastes the time you needed for sequencing. Candidates who describe a constraint as a dependency tend to spend weeks trying to negotiate with physics.

It means every commitment you rely on was given voluntarily, so the mechanisms available to you are information, sequencing and reciprocity rather than instruction. Concretely: you make it obvious to a team what their slip costs someone else, you give them something in return for the thing you need, and you make the consequences of a decision visible to the person who owns both sides. Its real content is credibility, which is built by being accurate. If your dependency dates have been right, your escalations have been necessary, and your status has not been optimistic, teams treat your requests as load-bearing. Spend that on one unnecessary escalation and the next request is negotiated from scratch.

None of them unilaterally, which is why the honest framing is that you control the visibility of the trade between them. Scope belongs to product, resource to engineering leadership, and the schedule is derived from both rather than chosen. What a TPM owns is that the three are stated consistently and that changing one is never allowed to happen silently. The failure mode is a program where scope grows through a series of small reasonable additions while the date and the headcount stay fixed, and nobody ever made that decision. Making the arithmetic visible at the moment of each addition is the job, and it is unpopular precisely because it forces a decision that was more comfortable left implicit.

A charter exists so that six months in, an argument about whether something is in scope can be settled by reading rather than by seniority.

section                what it must contain                         why it is there
---------------------  -------------------------------------------  ----------------------------
Outcome                one sentence, in business terms, with the    stops the program being
                       measure that says it happened                judged on output instead
                                                                    of outcome

In scope               named deliverables, by workstream            the list arguments are
                                                                    settled against

Explicitly out         the three or four things people will         omitting this is why scope
                       assume are included and are not              creep is never noticed at
                                                                    the moment it happens

Success measures       the metric, its current value, its target    a target with no baseline
                       and who reports it                          cannot be claimed or denied

Constraints            fixed dates, fixed budget, environments,     distinguishes what can be
                       regulatory obligations                       negotiated from what cannot

Decision rights        who decides scope, who decides resourcing,   the single most-skipped
                       who accepts risk, who can block launch      section, and the cause of
                                                                    most escalation churn

Assumptions            what must be true for the plan to hold,      converts a silent belief
                       each with an owner and a check date          into a tracked risk

The two sections that do the work are the explicit exclusions and the decision rights, and they are the two most often left out. Exclusions are what make scope creep detectable: without them, every addition is arguably always-intended, and the program absorbs six weeks of work nobody ever approved.

Decision rights matter because the majority of escalations that stall are not disagreements about the right answer, they are disagreements about whose answer counts. Writing down that resourcing trades are the engineering director's call and scope cuts are the product lead's turns a two-week deadlock into a two-day one.

Assumptions with check dates are the part experienced TPMs add and juniors do not. An assumption is a risk that has not been noticed yet — "the vendor sandbox will be available in March" is load-bearing, and giving it an owner and a date in February is how you find out in time.

A workstream is a stream of related work with one accountable lead, its own cadence, and a boundary you can describe in a sentence. The count is a design decision rather than a description: too few and the interesting dependencies are hidden inside a workstream where the program cannot see them, too many and you spend all your time on coordination overhead you created. The test is whether each workstream has a genuine single owner who can commit on its behalf. If two people have to be in the room for any commitment, it is two workstreams pretending to be one, and the disagreement between them will surface as a slip rather than as a decision.

The critical path is the longest chain of dependent work through a plan, and its length is the shortest possible duration of the program. Its importance is that it tells you where effort changes the date and where it does not. Adding people to work that is not on the critical path improves nothing about the finish, which is why "everyone is busy" and "we are on track" are unrelated statements. The path is also not static: as work completes and estimates change, a different chain becomes the longest one, so a critical path calculated once at planning time and never revisited is a historical document rather than a management tool.

Float is how long a task can slip before it delays something downstream. Work on the critical path has zero float by definition, so any slip there moves the program date immediately. Float is what makes a plan survivable, and it is consumed silently: three teams each taking two extra days on work with a week of float have spent the week, and nothing on any status report changed colour. That is why tracking float rather than only dates is the more sensitive instrument. A plan where most paths have run out of float is fragile even while every date still looks achievable, because it has no capacity left to absorb anything.

Six tasks, two teams, one shared review step. The arithmetic is the whole point.

task  description                 duration  depends on
----  --------------------------  --------  -----------
A     schema agreed                 5d      -
B     API built                    15d      A
C     mobile client built          20d      A
D     integration test              8d      B, C
E     security review                5d      B
F     launch readiness              3d      D, E

paths through the plan
  A -> B -> D -> F   =  5 + 15 +  8 + 3  = 31d
  A -> C -> D -> F   =  5 + 20 +  8 + 3  = 36d   <- critical path
  A -> B -> E -> F   =  5 + 15 +  5 + 3  = 28d

float
  C   0d   on the critical path
  B   5d   B finishes day 20, D cannot start until C finishes day 25
  E   8d   E can finish as late as day 33 without delaying F

The program is 36 days, not 56, and not the sum of anything. Candidates who add durations are describing effort, not duration, and the two differ by however much runs in parallel.

The useful finding is in B's five days of float. Speeding up the API buys nothing at all, because integration test waits on the mobile client either way. If a director offers you two engineers, putting them on B is a visible burst of activity that does not move the date by one day, and saying so is exactly the value a TPM adds at that moment.

The second finding is what happens when C slips. Six days of slip on C moves the program date by six days and simultaneously consumes B's entire float, so a plan that had two independent paths now has one, and B becomes critical too. That is the point at which reporting has to change, because the number of things that can now hurt you has doubled while the date moved by less than a week.

Float on E is worth reading as an opportunity rather than a comfort. Eight days of slack on the security review means the review can be scheduled early without cost, which converts a late-program unknown into an early finding. Deliberately spending float to pull risk forward is one of the more sophisticated moves available in program planning.

Because it can be declared complete by whoever is under the most pressure to declare it complete, and it usually is. "API complete" is satisfied by merged code, by a deployed instance, or by another team successfully calling it in a shared environment, and those are weeks apart. A milestone earns its place when it names the observable evidence: the consumer team has made a successful call against the deployed staging instance with a non-trivial payload. That version cannot be talked into being true. It also removes the argument at the moment it matters most, which is the week before an integration everybody has been assuming was already proven.

A rolling-wave plan is detailed for the near term and coarse beyond it, and is refined as work approaches. A fully detailed plan specifies everything up front. The rolling-wave version is usually the honest one, because the detail in month nine of a fully specified plan is invented and everyone knows it, yet it gets reported against as though it were evidence. What a rolling-wave plan must keep firm despite the coarseness is the milestone set and the dependency dates, because those are what other teams commit against. Coarse near-term detail is the failure mode in the other direction: vagueness about the next six weeks is not agility, it is an absent plan.

You stop asking for an estimate and buy information instead. Timebox a spike with a defined question and a decision at the end of it — "two engineers, one week, can we read the legacy format at all" — and plan the dependent work as a range with the spike as its gate. That is honest and actionable, whereas a made-up number is neither. The part candidates miss is placing the spike early rather than where it naturally falls in sequence. An unestimatable piece of work is the largest uncertainty in the plan, so it should be attacked in the first third while there is still room to respond to whatever it tells you.

Buffer belongs at the end of a chain of dependent work, held visibly at program level and drawn on by decision. It does not belong hidden inside individual task estimates, where it disappears in two ways: work expands to fill it, and when a task with padding still overruns you cannot tell whether the padding was too small or the estimate was wrong. Distributed hidden buffer also cannot be reallocated, because nobody knows where it is. Held openly, buffer becomes a fact you can report — "we have nine days of program buffer and have spent four" — which is one of the most informative sentences available in a status update.

Boxes and arrows are worth more than a paragraph here because the shape shows which team is waiting on whom.

flowchart TD
    A[Platform: schema frozen] --> B[Backend: API deployed<br/>to staging]
    A --> C[Mobile: client built<br/>against schema]
    B --> D[Joint: end-to-end run<br/>in staging]
    C --> D
    B --> E[Security review]
    D --> F[Launch readiness gate]
    E --> F

Two properties of this map matter more than its contents. The schema freeze is a single upstream node that two teams depend on, which makes it the highest-leverage date in the program and the one worth over-protecting. A one-week slip there costs a week on both downstream branches at once, and no amount of downstream effort recovers it.

The end-to-end run is the node owned by nobody. Both the backend and mobile boxes have a team name in front of them; the joint node does not belong to either team's backlog and is the classic candidate for arriving unplanned and unstaffed. Assigning it an owner and a date at planning time, rather than discovering it in week twelve, is most of what dependency mapping is for.

The security review branch is short and has slack, which invites the mistake of scheduling it last because it can be. Scheduling it early costs nothing and removes the possibility of a launch gate being blocked by a finding that needs three weeks of remediation nobody has.

A usable risk names what happens, what would trigger it, how bad it is, who owns it and what would be done. "Scaling risk" fails on all five and is what most registers contain. The trigger is the part that converts a worry into something manageable, because it tells you when to act rather than leaving the risk to be re-debated at every review. Impact needs to be in a unit the audience can trade against something else, which for an executive means cost or a missed commitment rather than a technical description. And an owner has to be a person, not a team, because a risk owned by a team is checked by nobody.

A risk has not happened and has a probability; an issue has happened and needs a response now. The reason to be strict is that they belong in different forums and get different handling. Risks are reviewed on a cadence and managed by mitigation; issues are worked immediately and reported until closed. Registers rot in a specific way when the distinction is loose: they fill with issues that are already consuming the team, which makes the risk review a status meeting, which means nobody surfaces anything speculative in it. The forward-looking function is then lost, and the register becomes a record of things you already know.

The columns are not bureaucracy. Each one closes off a specific way the risk gets ignored.

field           entry
--------------  ----------------------------------------------------------------
id              R-14
statement       Single-writer order database saturates on write throughput
                before the Q4 volume increase
trigger         Peak writes exceed 80 percent of measured ceiling for three
                consecutive days
current         62 percent of ceiling, growing about 9 percent per quarter
impact          Write latency degrades for all tenants at once. No partial
                mitigation. Prior comparable incident cost 210,000 in credits
                plus 11 engineer-weeks
likelihood      Medium. Ceiling reached inside four quarters at current growth
owner           Priya Raman, platform lead
mitigation      Raise ceiling by moving audit writes off the primary. Two
                engineers, three weeks. Not yet scheduled
contingency     Rate-limit non-critical writes per tenant. Degrades reporting,
                keeps ordering alive. Runbook RB-22, untested
decision needed Fund mitigation in Q3 or accept and re-review at 80 percent
                trigger. Owner of that decision: engineering director
review          Monthly, or immediately on trigger

The trigger and the current reading together are what make this row actionable, because they replace an argument about whether the risk is real with a number anyone can look up. A register full of medium-likelihood entries and no measures is a register that gets skimmed.

Separating mitigation from contingency is the distinction most candidates blur. Mitigation reduces the chance the thing happens; contingency is what you do once it has. Both are needed, and a row with only a mitigation is a plan with no answer to the case where the mitigation was not funded.

The untested contingency is deliberately recorded as untested. That single word is worth more than the runbook reference, because an untested contingency has an unknown success rate and should not be counted as coverage in any report.

The last line is the one that makes this a program artefact rather than an engineering note: it names the decision needed and who owns it. Without that, the row can be reviewed monthly forever without anything happening, which is the most common fate of a well-written risk.

A mitigation acts before the event to make it less likely or less severe: reducing load, adding a second qualified engineer, pulling an integration test earlier. A contingency is the prepared response once the event occurs: a rate limit you can switch on, a manual fallback process, a rollback. You want both, because mitigations are frequently deferred for cost reasons and a risk with a deferred mitigation and no contingency is simply unmanaged. The property that decides whether a contingency counts is whether it has been exercised. An unrehearsed contingency has an unknown success rate, and reporting it as coverage is how programs discover in an incident that the fallback never worked.

Anything whose absence stops the program and for which no substitute exists: one engineer who understands a system, one shared environment, one vendor with no alternative, one approver on holiday during the launch window. The delivery version is not primarily about redundancy engineering, it is about queueing — four workstreams behind one reviewer means the program's throughput is that person's calendar. The useful discipline is to look at the critical path and ask what single resource each step depends on. If the answer is the same name or the same environment three times, that is your real constraint, whatever the plan says about task durations.

You convert an expectation into an agreement, in writing, with three specifics: what exactly is being delivered, the date, and how both sides will know it is done. Then you verify against intermediate evidence rather than asking for status, because a monthly "on track" from a team with other priorities carries almost no information. The part that determines whether this works is reciprocity — you tell them what your program does for theirs, you take work off them where you can, and you make their contribution visible to their own leadership. A dependency held only by a date in your plan and no relationship is the one that slips without warning.

Three things: someone with the authority to accept it did so explicitly, the acceptance is written down with the reasoning, and it carries a review date or a trigger. Absent any of the three, what you have is drift dressed as a decision, and the distinction becomes very sharp in a post-incident review. The written reasoning matters more than the acceptance, because circumstances change and the reason is what tells a future reader whether the decision still holds. A risk accepted because volume was flat should be revisited automatically when volume starts growing, and only a recorded rationale makes that possible.

It is the last date the thing can arrive without moving anything downstream, which is its promised date plus its float. Tracking it changes the conversation with the providing team from a negotiation about their convenience to a fact about consequences: "the eleventh is your date, the eighteenth is when it starts costing us, past that the launch moves". It also stops you spending escalation capital on slips that cost nothing. A dependency arriving four days late into two weeks of float is not an event, and a TPM who escalates it teaches everyone to discount the next escalation, which is a real cost paid for no gain.

You look at the joins rather than the workstreams, because undeclared dependencies live between boundaries: a shared library, a schema two teams both write to, an approval nobody scheduled, an environment, a person on two programs. Three questions surface most of them. What must be true before this milestone can start, and who makes it true. Who else changes the things you change. What have you assumed someone else is doing. The last one is the highest-yielding, because an assumption held by two teams in opposite directions is invisible in every status report until the week it is tested.

A stakeholder is anyone who can affect the outcome or is affected by it, which is a larger set than the people in your meetings and includes support, sales, legal, and the team whose roadmap you displaced. Sorting them by influence and interest is the standard move and it is only useful if it changes behaviour: high influence and high interest get direct conversation before decisions are made, high influence and low interest get short written summaries with anything needing their decision flagged explicitly, and the rest get the broadcast update. The failure this prevents is the senior stakeholder who first learns about a change at the point of no return and reasonably objects to having been informed rather than consulted.

Order matters more than wording, because an executive is deciding whether to trust the number and needs the shape before the detail.

1. The new date, first sentence, no preamble.
   "Launch moves from 14 October to 11 November."

2. The single cause, in one sentence.
   "The payments platform dependency slipped three weeks and it is on
    the critical path."

3. What you already checked, so they do not ask.
   "I re-ran the path. Six days are absorbed by float in the mobile
    workstream, so the program moves fifteen working days, not the
    full three weeks."

4. The options, with the recommendation named.
   "Two ways to hold October: cut bulk export, which two launch
    customers asked for, or pull two engineers off the billing
    migration, which makes that late instead. I recommend neither.
    I recommend the new date."

5. Why this date is more reliable than the last one.
   "We now have a weekly checkpoint against a named intermediate
    deliverable, and the integration test moved to week six, so the
    next slip surfaces in six weeks rather than in fourteen."

6. What you need from them, and by when.
   "I need the date confirmed by Thursday so I can tell the two
    customers before their planning call."

Leading with the date is uncomfortable and correct. An executive who has to wait through three minutes of context before hearing the number spends that time anxious rather than listening, and often interrupts to ask for it, which loses you the framing entirely.

Step five is the one that separates a competent update from a trusted one. The question after any date change is whether this is the last one, and the only credible answer names what changed about how the plan is being verified. A new date produced by the same process that generated the old one deserves no more confidence, and saying so before they ask it is what buys the benefit of the doubt.

Step six prevents the most common waste in executive communication, which is a well-delivered update that ends without a decision and therefore requires a second meeting.

Four things: the date and whether it moved, what changed since last week, the decisions you need and from whom, and the risks that are newly live or newly retired. What does not belong is a list of completed tasks, which is activity rather than progress, and a repetition of the risk register, which nobody reads twice. Length is a design constraint rather than an aesthetic one: an update long enough to need skimming is skimmed for colour, so the substance has to survive being read in ninety seconds. The decisions-needed section is the part with the highest return and the part most often omitted.

Because a stakeholder's tolerance for bad news is high and their tolerance for late bad news is nearly zero, and the difference is about their own credibility rather than about the program. A director who told their leadership the date was safe on Monday and hears otherwise on Friday has been made to look uninformed, and that is remembered longer than the slip. The practical consequence is that you communicate a risk when it becomes material rather than when it is confirmed, with the uncertainty stated. "There is a real chance this moves and I will know by Thursday" costs you nothing and is the sentence that makes you trusted.

The facts are identical and the framing differs by what each audience decides. Engineers need the mechanism and the consequence for their own work: what slipped, what it means for sequencing, what changes about their next two weeks. A VP needs the outcome, the options and the decision they own, with the mechanism available but not narrated. What must never differ is the substance — two versions of a slip with different severities eventually meet in a room, and the damage from that is disproportionate. The test is whether both audiences would recognise the other's version as the same event described at a different altitude.

It records what was decided, by whom, when, and why, and its value is almost entirely in the last of those. Decisions get revisited constantly as people rotate through a program, and without a recorded rationale each revisit re-runs the original argument from nothing. With one, the question becomes whether the reasoning still holds, which is faster and usually produces a better answer. The log also settles the recurring dispute about whether something was decided at all, which in a long program consumes a surprising amount of time. It works best kept in the open where anyone can read it, not in a TPM's private notes.

You stop relying on their attention and design around it, because the pattern rarely changes on request. That means putting their decisions on the calendar with a stated deadline and a default — "if I do not hear by the twelfth I will proceed with option A" — and making sure the default is one you can live with and they will not enjoy. It also means giving them something short enough to actually read, and getting their objection early by asking a specific question rather than sending a document. The failure to avoid is treating their silence as agreement and then discovering their objection at a launch gate.

Red, amber and green describe whether a workstream will hit its commitment, and the labels become useless the moment they are not defined against explicit criteria. Without them, colour tracks the lead's temperament and the political cost of amber. That cost is the real mechanism: if amber triggers a review meeting, a recovery plan and a director's questions, rounding a marginal amber to green is individually rational, and the program goes red in a single week after months of green. Making amber cheap and useful — help rather than scrutiny — is the only fix that works, and it is an organisational change rather than a reporting one.

The test of a report is what a sceptical director can do with it in two minutes.

PROGRAM: Unified Checkout            WEEK 14 OF 26
DATE: 11 Nov  (was 14 Oct, changed wk 12, approved by S. Okafor)
CONFIDENCE: Medium.  Buffer 9d, spent 4d.

WORKSTREAM        RAG    EVIDENCE FOR THAT COLOUR
Backend API       Green  Consumer team calling deployed staging instance
                         since wk 13
Mobile client     Amber  Two of five screens behind. Recovery: contractor
                         starts wk 15. Recheck wk 17
Payments platform Amber  Dependency date 18 Nov, latest useful 22 Nov
Migration         Green  Rehearsal on prod-shaped data, 4h 20m, window is 6h
INTEGRATION       Amber  Owned by program. First end-to-end run wk 16.
                         No evidence before then

DECISIONS NEEDED
  Bulk export in or out of launch scope      owner: product   by 14 Nov
  Contractor extension beyond wk 20          owner: eng dir   by 21 Nov

RISKS NEWLY LIVE
  R-14 write ceiling now 71 pct, trigger is 80 pct

RETIRED THIS WEEK
  R-09 vendor sandbox available, tested wk 13

The evidence column is what makes the colours arguable, which is the point. A green with "consumer team calling deployed staging instance since week 13" can be checked; a green with no evidence is an opinion, and a hostile reader is right to treat it as one.

Integration appears as its own line owned by the program rather than being distributed across the workstream rows. That is deliberate: the work between teams belongs to nobody's workstream, so a report that only rolls up workstreams is silent about the riskiest part of the program and can be green everywhere while the date is unreachable.

The buffer line converts confidence from a feeling into arithmetic. Nine days held and four spent by week fourteen is a fact a reader can extrapolate, and it is far more informative than the word medium on its own.

Retiring risks explicitly matters more than it looks. A register that only grows teaches readers that nothing on it ever resolves, and they stop reading. Showing something closed with the evidence that closed it is what keeps the live entries credible.

A burn-up plots completed work and total scope as two separate lines, so scope growth is visible as a rising ceiling. A burndown plots only remaining work, which means added scope and slow progress look identical: the line simply fails to fall. That ambiguity matters in a program, because the two have completely different remedies and the conversation with a stakeholder is entirely different. Being able to point at a scope line that has risen twenty percent since baseline is a far stronger position than asserting that requirements keep changing, and it moves the discussion to a decision about scope rather than about team speed.

Because it is usually derived from tasks closed against tasks planned, and both terms move. New tasks appear as understanding improves, so a program can close work all week and go backwards. Worse, the remaining work is not a random sample: the hard, uncertain, cross-team parts are systematically left until later, so the last twenty percent of the tasks routinely holds most of the risk. That is the mechanism behind a program that sits at ninety percent for two months. Milestones with evidence-based exit criteria are the alternative, because they are binary and cannot be part-claimed.

Something that moves before the date does, so you still have room to act. Dependency dates shifting, float being consumed, a growing gap between planned and actual start dates, review queues lengthening, the date of the first end-to-end integration being pushed. A lagging indicator tells you what already happened: a missed milestone, an actual slip. Programs are typically instrumented almost entirely on lagging indicators, which is why they discover problems at the point where the only remaining levers are scope and date. The single most useful leading indicator is usually the trend in dependency dates, because it moves weeks before anything visible does.

They are engineering-health measures, not program measures, and the TPM use is diagnostic rather than reporting.

metric                    what it measures            what a low value implies
------------------------  --------------------------  ---------------------------
Deployment frequency      how often code reaches      large batches, so integration
                          production                  risk is concentrated late

Lead time for changes     commit to running in        long feedback loops, so
                          production                  defects are found far from
                                                      their cause

Change failure rate       share of deploys causing    quality problems that will
                          degradation                 surface as unplanned work
                                                      eating your schedule

Time to restore service   how long recovery takes     incidents that consume days
                          after a failure             rather than hours of the
                                                      team you were counting on

The reason a TPM cares is that all four predict how much of a team's capacity is going to be involuntarily reallocated. A team with a high change failure rate and slow restore times has a fluctuating amount of its week consumed by unplanned work, which makes their commitments to your program less reliable regardless of intent.

Deployment frequency has the most direct planning consequence. A team deploying monthly cannot give you evidence of integration until their next release, so your first end-to-end proof point is bounded by their cadence rather than by your plan, and no amount of pressure changes that.

What these must not become is a program scorecard reported upward. They are owned by engineering leadership, they are trivially gamed once they are used for judgement, and a TPM who starts reporting another team's failure rate to a steering committee has traded a diagnostic instrument for one conversation.

You derive it from something visible and state what it assumes, rather than asserting it.

Remaining scope at week 14      118 items
Completed in the last 6 weeks   14, 11, 19, 9, 16, 13  -> mean 13.7/week
Slowest 3-week window           9, 11, 13             -> 11.0/week
Fastest 3-week window           16, 19, 14            -> 16.3/week

At mean rate        118 / 13.7  =  8.6 weeks   -> week 23
At slow rate        118 / 11.0  = 10.7 weeks   -> week 25
At fast rate        118 / 16.3  =  7.2 weeks   -> week 21

Scope has grown 9 items/month for 3 months. If that continues,
add roughly 2 weeks:                            -> week 25 central

Stated: "Week 25. The range is 23 to 27. It assumes throughput holds
near recent average and scope growth continues at the rate of the
last three months. It excludes the integration finding due in week 16,
which is the one thing that could move it outside that range."

The number to give is the one derived from the slower assumptions, because throughput has a floor and scope does not have a ceiling. Forecasts built on the fastest recent weeks are wrong in a predictable direction, and being wrong in a predictable direction is how a TPM loses the ability to be believed.

Naming the excluded unknown is what makes the range honest. A range that silently omits the largest source of variance is a false precision, and the interviewer's follow-up is always some version of what is not in this number.

The scope-growth adjustment is the part most candidates leave out entirely, and it is frequently larger than the throughput uncertainty. A forecast that treats remaining scope as fixed when it has grown every month for a quarter is not a forecast, it is a hope with arithmetic attached.

A team standup coordinates individuals inside one backlog. A program standup coordinates leads across boundaries, so its content is different: only cross-team blockers, dependency dates that moved, and decisions needed this week. Nothing that can be resolved inside a single team belongs in it. Run it short, twice a week rather than daily in most programs, and treat any item that turns into a discussion as a signal to take it offline with the two people who own it. The failure mode is a round-robin of team status, which produces a meeting six leads attend to hear the two minutes relevant to them.

This is the meeting that does the most work in a program and it is usually run as a status round instead.

30 minutes, fortnightly, providing and consuming leads both present.
Prepared beforehand, not discovered in the room.

item                       time  what happens
-------------------------  ----  -----------------------------------------
Dates that moved             8   only the ones that changed since last
                                 time. Provider states the new date,
                                 consumer states what it costs them.
                                 No discussion of why yet

Float remaining              5   for each live dependency: promised date,
                                 latest useful date, days between them.
                                 Anything under a week is called out

New dependencies             5   discovered since last review. Each gets
                                 a provider, a consumer, a date and an
                                 acceptance criterion before the meeting
                                 ends

Decisions needed             7   dependencies that cannot be resolved
                                 between the two teams. Named owner and
                                 a date, or it goes to escalation

Retired                      2   dependencies satisfied and verified.
                                 Read out, so the list visibly shrinks

Not in this meeting:  why a team is late, how they will recover,
                      anything involving only one team

The consumer stating the cost is the mechanism that makes this meeting work. A provider hearing "that costs the mobile team two weeks and moves the launch" from the affected lead rather than from you is what converts a date into a shared problem, and it removes you from the middle of a negotiation you have no authority in.

Tracking float rather than only dates is the second thing that distinguishes a real dependency review. Dates alone tell you nothing about severity, and a review that treats every slip as equally interesting spends its time on the ones that cost nothing.

The exclusion at the bottom is load-bearing. Once recovery planning enters this meeting it expands to fill the slot, the leads with nothing at stake disengage, and within a month attendance is delegated to people who cannot commit on their team's behalf.

Decisions. A steering committee that receives a status presentation and asks questions has cost six senior people an hour and changed nothing. The useful shape is a short written pre-read circulated in advance, an agenda consisting of the two or three decisions you need with options and a recommendation for each, and a record of what was decided. The TPM's job before the meeting is more important than in it: knowing where each member stands and having resolved what can be resolved bilaterally, so the meeting handles only the genuine disagreements. A committee with nothing to decide should be given the pre-read and no meeting.

It is the gate where the program checks evidence rather than opinion against a pre-agreed criteria list: the end-to-end path has run, the rollback has been rehearsed, on-call is briefed and staffed, support has documentation, the security review has signed, the migration has been timed inside its window. It works only when the criteria were agreed weeks earlier, because criteria invented at the gate become a negotiation under time pressure that the launch always wins. Who can block should be written down in advance and short — typically security, the on-call owner, and the accountable engineering leader — and every blocker must be a criterion, not a concern.

You look at decisions and interfaces rather than at working practices, because a program's failures are mostly located between teams. Useful questions: which dependency surprised us and when could it have been known, which decision took longest and why, where did our status differ from reality and for how long, which risk we wrote down did we not act on. Run it with the leads rather than with everyone, keep it to the program's own conduct rather than individual teams' internals, and produce a small number of owned changes. A program retrospective that generates twenty observations and no owner is a document, not a change.

You either find an owner in the room or delete it, and you say which out loud. An unowned action is worse than no action because it appears on a list as coverage, so the risk it was meant to address is treated as handled. Deleting it is a legitimate outcome and often the honest one: if nobody will own it, the organisation has implicitly decided it is not important, and making that visible is more useful than carrying it for four reviews. The pattern to watch is an action list that grows every meeting, which indicates a forum generating work rather than resolving it.

An escalation is asking someone with authority you lack to make a decision or unblock something, and it is legitimate when three conditions hold: the decision genuinely cannot be made at the current level, you have tried and can say what you tried, and you are asking for a specific decision by a specific date. Escalating to create pressure rather than to obtain a decision works once and is remembered. The framing that keeps relationships intact is to escalate the problem rather than the person, and to tell the other team you are doing it before you do, which turns it from an ambush into a joint request for a decision.

Five short paragraphs, and the order is what makes it work.

Subject: Decision needed by Thu 14 Nov - checkout launch scope

The decision
  Bulk export in or out of the 11 November launch.

Why it cannot wait
  The mobile team needs a final scope by Friday to sequence the last
  two sprints. After Friday, keeping it in moves the launch by a week.

What we have tried
  Reduced the export to a single format. Estimated a phase-two
  delivery for December. Neither removes the two-week build.

The options
  In:   launch moves to 18 November. Two named launch customers get
        the feature they asked for on day one.
  Out:  launch holds 11 November. Export ships in December. Sales
        believes both customers accept a dated commitment.
  Recommended: out. The date is the harder commitment and the
  customers have a credible alternative.

Who disagrees, and on what
  Sales lead prefers in, on the grounds that a December date will not
  be believed after one slip. That is a fair point and it is the risk
  in my recommendation.

Leading with the decision and the deadline gets the message read. An escalation that opens with three paragraphs of history is triaged as background reading and answered late, which is functionally the same as not sending it.

The what-we-have-tried section is what stops the reply being a suggestion you already rejected, and it also establishes that the escalation is necessary rather than a first resort.

Representing the disagreement fairly is the section people skip and the one that earns you a decision rather than a request for more work. A decision-maker who suspects they are only hearing one side will go and ask the other, which costs a week. Presenting the strongest version of the opposing view yourself removes that step and, incidentally, makes your recommendation more believable.

The lowest person who owns both sides of the problem, which is almost never the most senior person you can reach.

flowchart TD
    A[Blocked dependency] --> B{Can the two leads<br/>decide it}
    B -- Yes --> C[Not an escalation.<br/>Get them in a room]
    B -- No --> D{One manager owns<br/>both teams}
    D -- Yes --> E[Escalate there with<br/>a recommendation]
    D -- No --> F[Joint escalation to<br/>both managers together]
    F --> G{Still unresolved<br/>after the agreed date}
    G -- Yes --> H[Their shared leader,<br/>with the history attached]

The branch to notice is the joint escalation. When two teams report into different managers, going to one of them alone produces a decision the other side did not participate in, which gets quietly re-litigated through the plan over the following weeks.

The other property worth reading off this is that skipping levels has a cost that is invisible at the time. A decision obtained from a VP over the head of a director who would have made the same decision leaves you with a director who now checks everything you send, and the next escalation takes twice as long.

You do not contest the technical claim, you interrogate its delivery consequences, which are yours to own. What has to be true for this approach to work, what happens if that turns out false, what is the earliest point we would find out, what does the alternative cost. Those questions are answerable by them and readable by you, and a claim that survives them is probably sound. If the answers are vague, the useful move is to ask for a second technical opinion from a named peer rather than to substitute your own judgement. Pretending to technical authority you lack is the fastest way to be excluded from technical conversations.

You first establish which of three causes it is, because the responses share nothing. They may be over-committed, in which case the fix is upward and about their portfolio rather than about them. They may be estimating badly, in which case smaller increments with earlier evidence gives you a working signal without needing better estimates. Or your work may be genuinely lower priority for them than they are willing to say, in which case the conversation is between the two owning leaders and pretending otherwise wastes a quarter. Treating a repeated miss as a discipline problem when it is a portfolio problem is the common error.

You do not attempt to resolve it, and you do not carry messages between them, because both moves put you in the middle of a dispute you have no standing in and both sides will eventually attribute the other's position to you. What you can do is make the trade explicit and the cost of delay concrete, in writing both would recognise as fair, and get them in the same room with a stated decision and deadline. If it stays unresolved, the escalation goes to their shared leader with the history attached rather than as a complaint. The thing to protect is the accuracy of your representation of both positions.

Credibility, which is the only currency you have. An escalation that turns out to have been resolvable between two leads teaches everyone that your requests can be discounted, and it teaches the teams involved that talking to you leads to their manager finding out. That second effect is the expensive one, because it reduces the information reaching you, which is the substrate of the whole role. The counterweight is that escalating too late is also a failure, and usually a larger one. The test is whether a decision is genuinely needed above the current level and whether waiting another week removes an option.

Typically a program scenario or two, a technical depth conversation, a behavioural round on conflict and influence, and often a written exercise such as a status update or a risk assessment. The scenario rounds are the core and they are graded on process rather than answer: how you decompose an ambiguous situation, what you ask before proposing, and whether your proposal is scoped to what you found. The technical round is not testing whether you could implement, it is testing whether you can hold a design conversation, spot a hand-wave, and translate an architectural constraint into a delivery consequence.

The structure is what is being graded, so making it audible is worth doing deliberately.

step                       what you say                        why it scores
-------------------------  ----------------------------------  -------------------------
Restate the constraint     "So the date is fixed, and the      shows you identified
                           dependency is on a team outside     what makes this hard
                           the program"                        rather than the surface

Ask two or three           "Is the date a commitment to a      a scenario is deliberately
questions                  customer or an internal target"     underspecified. Asking is
                                                               the first scored behaviour

State what you would       "I would check whether downstream   evidence before diagnosis
look at first              float absorbs any of it before
                           quoting a new date"

Give the options with      "Three levers: scope, resource,     shows you did not reach
a recommendation           date. I would recommend..."         straight for one

Name what would            "If the customer commitment is      shows the answer is a
change your answer         contractual, I would recommend      method, not a script
                           the scope cut instead"

Say what you would         "I would move the integration       the part almost everyone
change structurally        test earlier so the next slip       omits, and the strongest
                           surfaces in week six"               signal available

The two behaviours that most reliably separate candidates are near the top and the bottom. Asking about the nature of the date before answering is the difference between a candidate who manages programs and one who processes tickets, because almost every subsequent choice depends on it.

Naming the structural change at the end is the highest-value thirty seconds in the round. Most candidates solve the incident presented and stop. An interviewer is listening for whether you also fix the mechanism that let it arrive as a surprise, because that is the difference between a TPM who handles slips and one whose programs have fewer of them.

Saying what would change your recommendation protects you from the follow-up designed to test whether you have a method or a memorised answer, and it costs one sentence.

Whether you can locate the cause in something you controlled, at the right altitude. Blaming another team fails obviously. Blaming yourself for something you had no lever over fails less obviously but still fails, because it shows you cannot tell what was in your remit. The strong answer names a specific decision you made or did not make, says what signal was available at the time that you did not act on, and describes what you changed afterwards in a way that is concrete enough to be checked. What sinks this answer is a failure attributed to bad luck or to a stakeholder, with the improvement being vaguely better communication.

Specific enough to be interrogated, which means real magnitudes and real durations: four teams, eleven weeks, a three-week dependency slip, nine days of buffer. Vague scale reads as either inexperience or exaggeration, and interviewers probe it. The corollary is that every number you offer must survive a follow-up, so do not round a two-team program up to five. If you genuinely cannot recall a figure, say so and give the shape — "I do not remember the headcount, it was three teams and about a quarter" — which costs nothing. Being caught adjusting a number under questioning is much worse than not having it.

Because the round tests whether you can participate in a technical decision, not whether you know terminology, and a fluent vocabulary without underlying understanding is detected in about two follow-ups. The specific gap is usually the inability to convert an architectural fact into a delivery consequence: knowing that a service is a single point of write contention is only useful if you can say what that means for the sequencing of two teams and for the launch risk. The way through it is not learning more terms, it is being able to ask the three or four questions that expose a hand-wave and being comfortable saying you do not know something.

Enough to read a design document and identify what is unresolved, to know when two teams' agreement is verbal rather than actual, and to challenge an estimate on its assumptions rather than its size. Not enough to review code or design the system. It is tested by conversation rather than by quiz: an interviewer describes an architecture and watches whether your questions are about the parts that carry delivery risk. Candidates fail this in both directions — by having no technical opinions at all, and by trying to redesign the system in front of an engineer, which signals that they will do the same thing to their teams.

Same program, same facts, two answers to "tell me about a dependency you managed".

WEAK
  "We depended on the platform team for an API. They were slipping,
   so I escalated to their director and got it prioritised. We
   delivered on time. I learned the importance of building
   relationships early."

STRONG
  "Four workstreams depended on one payments API. In week three I
   asked for an intermediate deliverable rather than a single date,
   so we had a deployed stub by week five and could integrate
   against it.

   In week eight their date moved out by three weeks. Because we had
   the stub, two of the four workstreams kept moving, and I could
   quantify the impact as fifteen working days rather than the full
   three weeks after checking float.

   I took the trade to the engineering director with two options and
   a recommendation. We cut bulk export and held the date. The part
   I got wrong: I had not tracked the latest useful date for the
   other three dependencies, so I could not answer immediately when
   she asked what else was exposed. I added that column the same
   week and it caught a second slip in week eleven."

The weak version is a summary of an outcome with a generic lesson, and it is unfalsifiable — nothing in it could be checked or probed, which is exactly why it scores nothing. Every sentence would be true of a hundred programs.

The strong version is specific enough to be interrogated, and it invites the interrogation deliberately. It also demonstrates behaviours rather than asserting them: asking for an intermediate deliverable, checking float before quoting, arriving with options.

The admitted gap is the part candidates are most reluctant to include and the part that makes the answer credible. It is chosen carefully — a real mechanical omission with a concrete fix and evidence the fix worked — rather than a decorative weakness. A story with no error in it reads as rehearsed, and interviewers ask for the failure anyway.

A strong answer names a specific launch, the criterion it did not meet, who knew, and what the candidate did with that knowledge before the gate. It distinguishes a considered acceptance from a drift: someone with authority decided to ship with a known gap, in the open, with a mitigation and a review date, and the candidate's contribution was making the gap and its cost visible enough that the decision was real. It then says what the gap cost after launch, in specifics, and what changed in the readiness criteria afterwards.

The weak substitute takes one of two forms. The first is a story where nothing was actually wrong and the candidate's only concern was that testing felt rushed, which shows they have never been near the decision. The second is a story where the candidate objected, was overruled, and positions themselves as having been right all along; that answer tells an interviewer they will treat a legitimate business decision as a personal defeat and re-fight it. What is being tested is whether a candidate can hold both that shipping with known risk is sometimes correct and that their job is to ensure the risk was chosen rather than discovered.