Program & Project Leadership

Projects rarely fail because someone forgot to build a schedule.

They fail when decisions stall, dependencies remain invisible, ownership is unclear, risks surface late, vendors move out of sync, and execution separates from the business objective. We lead the complex technology programs where that has already started to happen.

The Field — Technology Program Management in Practice

A plan is not execution.

Seven workstreams move through the same environment at different speeds. Height in this field is priority — what the program is actually protecting at that moment. Workstreams trade places constantly, and a program is healthy when those trades are deliberate. One stalls without announcing it, and the schedule keeps reporting green for another three weeks. Program leadership is holding the whole field in view and deciding what has to happen next.

Seven workstreams moving through one program Seven continuous strands - people, technology, vendors, budget, security, operations and dependencies - enter at the left in one order and leave at the right in a different order, against a governance channel bounded by two horizontal rules. Height represents priority. The strands cross one another twenty-five times; none branches, merges or ends. Technology is marked blocked and runs dashed until it resolves. Operations crosses up and out of the channel under an executive escalation and returns. Security carries a risk mark and dependencies is tied to budget. Vendors degrades, breaks away downward out of the channel into a diagnostic recess, runs a three-part probe, passes a validated gate, and climbs back to rejoin one rank higher than it left. All seven converge on a single objective tick at the right. Neutral lines represent interconnected workstreams and dependencies. Height reflects priority — what the program is protecting at that moment. Red markers identify points where attention, intervention, validation, escalation, or a deliberate decision is required: a caliper marks a decision that is required and has not been made; a crossbar marks a path that is blocked, running dashed until it resolves; a tie marks a dependency between two workstreams; a circle marks a risk; a line crossing out of the channel marks an escalation to executive authority; a gate marks a validated return to the flow. PEOPLE TECHNOLOGY VENDORS BUDGET SECURITY OPERATIONS DEPENDENCIES OBJECTIVE DEPENDENCIES VENDORS OPERATIONS SECURITY PEOPLE TECHNOLOGY BUDGET RISK DEPENDENCY ESCALATED BLOCKED DECISION REQUIRED VALIDATED DIAGNOSTIC WHERE IT STOPPED WHY WHAT CHANGES STAKEHOLDER ALIGNMENT TRACKED TOGETHER REJOINED — DIFFERENT ROUTE OBSERVE OBSERVE OBSERVE ADAPT ADAPT ADAPT DELIVER DELIVER DELIVER VALIDATE VALIDATE VALIDATE DECIDE DECIDE DECIDE LEGENDWORKSTREAM / DEPENDENCY PATHRISKDEPENDENCYBLOCKEDDECISION REQUIREDESCALATEDVALIDATED / REJOINEDVERTICAL POSITION REFLECTS PRIORITY — WHAT THE PROGRAM IS PROTECTING AT THAT MOMENT.

Project Recovery

Sometimes the project does not need another plan. It needs someone to determine why the current one stopped working.

You may already have a project manager, a signed vendor, a detailed plan and a steering committee, and still be losing the quarter. We start with diagnosis, not a replan: the first two weeks go on isolating the actual failure — a decision that never closed, a dependency nobody owned, a scope that changed without anyone repricing it, a vendor working to a different definition of done. Then we re-enter the work with the authority to fix it.

Detail — Vendors, re-drawn at 1.8×

DIAGNOSTIC WHERE IT STOPPED WHY WHAT CHANGES VALIDATED

Recovery begins with diagnosis.

Where the failure turns out to be architectural rather than managerial, recovery runs alongside Technology Strategy & Modernization. Where it is an implementation problem — a build that will not integrate, a cutover nobody will sign — it runs alongside Engineering & Infrastructure.

A risk discovered early is manageable.

A risk discovered late becomes a crisis.

Late is where the money is. A dependency surfaced in week four is a sequencing decision. The same dependency in week fourteen is a change order, a slipped cutover, and a milestone invoice paid against work nobody validated. Most programs keep a risk register. What they need is a forcing function — someone whose actual job is to surface the thing nobody wants to raise, put a name against it, and put a date on the decision.

The objective stays fixed. The route can change.

Iterative delivery is a behaviour before it is a schedule. Each increment produces evidence, that evidence changes what should be built next, and the objective it is measured against holds still. In practice that means a shorter distance between something becoming true and a decision being taken about it — which is why the same handful of actions recur, unevenly, on different workstreams, at different points in the work, rather than once at the top of a phase.

Agile does not mean ungoverned. Governance in an iterative program is lighter and more frequent. Decisions still have an owner, a date and a record, and the record exists to make the next decision faster, not to defend the last one.

Executive Reporting

Visibility changes the conversation.

What most reporting shows

47 tasks updated · sprint 14 closed · 12 tickets moved to done · weekly call held · vendor onsite tuesday · 3 change requests logged · status: green · 88% complete · raid log reviewed · burndown on track · 6 actions carried forward · demo scheduled · 2 defects reopened · stage gate pack circulated · 4 meetings held · resource plan refreshed · 19 items in review · workshop completed · status: green · 5 risks restated · integration testing underway · governance forum convened · 31 comments resolved · plan rebaselined · 9 actions closed · supplier call minuted · training material drafted · cutover runbook in progress · 7 dependencies logged · status: green · reporting pack issued

What actually changed this week?Not what was worked on

What is blocked, and since when?Age matters more than count

What decision is required, from whom, by when?Named, not implied

What is at risk, and what would it cost?In business terms

Who owns it?One person

What happens next?And what happens if it doesn’t

Reporting that answers those six questions turns a status meeting into a decision meeting. Everything else tells an executive that a program is busy, which they already assumed, while leaving them no way to know whether it is going to land.

Embedded Program Leadership

An accountable senior leader, inside your program.

We join your team, your cadence and your governance, and we carry the outcome. That means sitting in your steering meetings and chairing the ones that need chairing, holding vendors to what their statements of work actually say, making the unpopular call about sequence when two directors both need to be first, and staying through acceptance, validation and the weeks after go-live — the period when most programs are quietly abandoned by everyone who was there for the launch. A review ends with a document. This ends with a program that landed.

Engagements include program leadership · project leadership · technology implementations · modernization programs · project recovery · agile and iterative delivery · stakeholder alignment · governance · dependency management · vendor management and coordination · risk management · executive reporting · implementation oversight · acceptance and validation · post-implementation accountability.

Where a program is putting automation or decision support into a process people already depend on, it runs with AI & Automation — because the governance problem there is proving the machine’s judgment before anyone is asked to act on it.

When execution has already stalled, the useful next step is a conversation, not a proposal.

Tell us where it is stuck — the decision that will not close, the vendor that will not commit, the dependency nobody will own, the date that nobody in the room believes any more. We take on cross-functional technology programs: multi-vendor, multi-year, regulated, or already late. We will tell you what we would do first, and whether we are the right people to do it.

Talk Through Your Challenge

Still determining what should happen first? Start with the Technology & AI Opportunity Assessment.