§ CAPABILITY

Software Delivery Management

Someone accountable for the date. Scope held, dependencies tracked, risks raised while there is still time to act on them — without adding a layer between the team and the work.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

A date was communicated externally and nobody can say where it came from.
Usually means The commitment accumulated rather than being made. There is no record of what it assumed, so there is no way to tell what has changed since.
Every team reports green and the programme is late.
Usually means Teams are reporting on their own work and nobody owns the seams between them. Individual accuracy and collective inaccuracy coexist comfortably when nothing spans the gaps.
Status is collected by asking people in a meeting.
Usually means The written record is not trusted, so a meeting exists to reproduce it verbally. That meeting costs several people an hour a week and produces information that was already in the tools.
Risks are raised at the point they become facts.
Usually means There is no mechanism that rewards surfacing a risk early, so the incentive runs the other way — raising one gets you asked what you are doing about it. By the time it is undeniable, the cheap options have expired.

Someone owns the date

Programmes rarely slip because nobody worked hard.

They slip because the dependency nobody owned arrived three weeks late, because scope grew a piece at a time and each piece was individually reasonable, and because the first honest conversation about whether the date was real happened after it had passed. Every one of those is a gap in accountability rather than in effort.

So the first artefact is the commitment itself, written down: what was promised, to whom, by when, and — the part that is almost always missing — what it assumes. Assumptions written down are what make a later slip diagnosable. You can point at the one that failed, instead of holding an argument about who was optimistic.

The seams, not the teams

Individual teams are usually accurate about their own work. The programme is late anyway.

That combination is not a contradiction: it is what happens when nobody owns what runs between teams. The interface neither side considered theirs. The shared table two teams changed in the same week. The cutover that assumed a dependency had already landed. Each team’s report is honest and the aggregate is wrong.

The dependency map is the instrument here — every cross-team and vendor dependency with an owner and a date on it. Dependencies with no named owner are the single most common cause of a slip that surprises everybody involved.

Not a layer

The failure mode of this role is becoming a relay between the people doing the work and the people asking about it.

That version adds latency in both directions, removes accountability from both ends, and is the reason engineers are sceptical when the function appears. It is also self-reinforcing: once someone is carrying news, they get asked for news, and the job becomes news.

The alternative is that status comes out of the tools automatically and the role exists to hold the commitment and make decisions visible. If a weekly meeting is still needed to find out what happened, this is being done wrong.

Where it sits

This capability sits under Engineering Velocity where delivery predictability is the problem rather than delivery speed, inside Delivery Implementation as one of the tracks, and under Software Development where an owned scope needs someone accountable for its date.

It runs on top of two others. DORA Metrics supplies the measured picture that makes generated status possible at all. Process Rebuild is what gets changed when the reporting shows the problem is structural rather than situational. And Board Delivery Reporting is the same information rewritten for people who do not read a backlog.

How the work runs

  1. Establish the actual commitment

    What was promised, to whom, by when, and what happens if it slips. Most late programmes were never explicitly committed to in the first place — they accumulated a date.

  2. Map dependencies and their owners

    Across teams and outside vendors, with a named owner and a date on each. Dependencies with no owner are the single most common cause of a slip that surprises everyone.

  3. Install a reporting rhythm the team does not resent

    Status assembled from the tools the work already lives in, not from a weekly round of asking people what they did.

  4. Run risk in the open

    A live register with owners, dates and a decision attached — surfaced early enough to be cheap, rather than announced when it has become a fact.

What arrives

  • A written commitment with scope, date and the conditions attached to both
  • A dependency map with an owner and a date on every line
  • A risk register that produces decisions rather than a record of them
  • Status generated from the delivery tools rather than assembled by hand

What it costs your team

A working session at the start, then roughly two hours a week from engineering and product leads. The team's own time is not the mechanism.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • The commitment is written down, including what it assumes

    Costs It forces an uncomfortable early conversation about a date that may already have been communicated.

    Most late programmes were never explicitly committed to. A date appeared, was repeated, and became a promise without anyone stating what it depended on. Writing the assumptions down is what makes a slip diagnosable later — you can point at which assumption failed instead of arguing about who was optimistic.

  • Status is generated from the tools, never collected from people

    Costs It requires the delivery tools to be used consistently, which is its own piece of work.

    A weekly round of asking engineers what they did costs several people an hour and produces a version of information that already existed. Worse, it teaches the organisation that the written record is not trustworthy, which then makes the meeting permanent. Generating status is what allows the meeting to be deleted.

  • The role owns the commitment and never becomes a relay

    Costs It means pushing back on leadership requests for updates that the reporting already answers.

    The failure mode of delivery management is becoming a message-passing layer between the people doing the work and the people asking about it. That adds latency, removes accountability from both ends, and is why engineers are sceptical of the function. Owning the date — scope, dependencies, risk — is a different job from carrying news about it.

Frequently Asked Questions

Owning the date. Holding scope against it, tracking the dependencies that can move it, surfacing risk while it is still cheap to act on, and reporting honestly to whoever is relying on the commitment. It is accountability for an outcome rather than coordination of a calendar, and that distinction is what separates it from administration.
It is the function, run by us, for as long as it is needed. Where the answer turns out to be a permanent hire, we say so and help define the role — a governance function that runs indefinitely from outside the company is a dependency you should not want to have.
It should remove them. Most status meetings exist because nobody trusts the written record. When status is generated from the tools the work already lives in, the meeting that existed to collect it no longer has a job, and deleting it is usually the first visible win.
No, and collapsing the two is a common mistake. An engineering manager owns the people and the technical decisions. This owns the commitment — scope, dependencies, dates, risk. Asking one person to do both reliably produces someone doing neither well, usually because the people work is the part that gets deferred.
Then that is the first finding, and it is worth more than anything else in the engagement. A date is a decision, and a decision made against a plan nobody privately believes is the expensive kind. Saying so in week one costs an uncomfortable meeting; saying so in month five costs the quarter.

Sources

Page reviewed