What delivery managers actually spend their week on

Nine skills are listed against the delivery manager role, at level 2, in the government’s capability framework. Seven are the ones anybody would guess: agile and lean practices, communicating between the technical and non-technical, life cycle management, maintaining delivery momentum, making a process work, planning, and team dynamics and collaboration.

The other two are commercial management and financial management.

No agile certification examines either. No two-day course covers what a break clause does to a delivery plan, or how to read a supplier’s invoice against the work actually accepted. Yet the state, which defines the role in a published framework and recruits against it across every department, has decided that a delivery manager who cannot handle a contract and a budget is not a delivery manager. That judgement was earned expensively, and the receipts are public. How many people hold the job is not, so treat any headcount you see quoted for it with suspicion.

The week is mostly other people’s unmade decisions

The framework describes the core duty plainly enough: identify obstacles and help the team to overcome them, and focus the team on what is most important to the delivery of products and services.

In practice almost no obstacle worth a delivery manager’s time is technical. A technical obstacle has an owner sitting in the team, and the team will clear it without help. What arrives on the delivery manager’s desk is a decision that belongs to somebody outside the team who has not made it: which of two data owners is accountable for a field, whether the security function will accept a control, whether the finance director will fund the second environment, whether the supplier’s change is in scope.

Each of those has a cost per day of delay that nobody calculates and everybody pays. The single most useful thing a delivery manager does is convert a vague dependency into a named person, a specific question and a date, and then make the cost of missing that date visible to somebody senior enough to care. That is the job. The ceremonies are how the information gets collected, and they are the least interesting part.

This is also why the role does not scale by adding process. A second stand-up does not produce a decision the first one failed to produce. The constraint is authority elsewhere in the organisation, and process cannot manufacture authority.

Do not let the reporting culture do the work of reassurance

The most instructive British account of what happens when it goes wrong is still the National Audit Office’s examination of the early years of Universal Credit, published on 5 September 2013. Its diagnosis of the programme’s management is worth reading against your own governance pack.

Major Projects Authority and supplier-led reviews in mid-2012 identified a fortress mentality within the programme team and a good news reporting culture. The department, the report found, did not have any adequate measures of progress. It failed to fully implement two thirds of the recommendations made by internal audit and the Major Projects Authority in 2012, and without timely management information it fell back on periodic external assurance reports to assess progress.

Read that last sentence as a delivery manager. An organisation that cannot see its own progress becomes dependent on outsiders to tell it, and outsiders arrive quarterly at best. Between visits, the programme runs on the assumption that no news is good news, which is precisely the condition in which a good news culture flourishes.

The counter-practice is unglamorous. Make bad news cheap to deliver and quick to act on. A team that has watched one person get a hard time for flagging a slip will not flag the next one, and the delivery manager will find out about it six weeks later from a supplier. Track the implementation rate of your own assurance actions as a first-class metric, because an organisation that commissions reviews and does not act on them has bought a document rather than an improvement.

There is a related warning in the same report about continuity. Including the reset and the director general in post at the time, the programme had five different senior responsible owners since mid-2012. Delivery managers absorb that churn. Every new accountable owner arrives with a different tolerance for risk, a different view of scope and a need to be re-educated about decisions that were settled a year earlier, and none of that time appears on a plan.

Do not manage with velocity

Velocity is a forecasting aid for a stable team on comparable work. It is not a productivity measure, it cannot be compared between teams, and the moment it is reported upward it stops measuring anything, because the unit of measurement is set by the people being measured.

The government’s own guidance is notably relaxed about method for exactly this reason. It records that scrum is the most commonly used agile method and that kanban is a way of visualising and improving working practices so that work flows through a system quickly, then tells teams they may choose tools and techniques from several to suit their circumstances. A delivery manager who inherits a method as a mandate has inherited somebody else’s answer to a question their team has not been asked.

Useful alternatives exist and they are all about flow rather than effort. How long does a unit of work take from the moment it is accepted to the moment a user has it. How much work is in progress at once. How often does something come back. Those numbers are comparable over time, they are difficult to game without actually improving, and they point at queues, which is where delivery time is genuinely lost.

Do learn the contract

The commercial and financial skills in the framework are not decorative, and the reason a delivery manager needs them is structural. On any programme of size, a meaningful share of the team is not employed by the organisation. Their working week is shaped by a statement of work written before the team existed, by a change control process with its own timetable, and by a commercial incentive that may or may not point in the same direction as the delivery plan.

A delivery manager who has not read that statement of work is negotiating blind. The specific things worth knowing are which activities are in scope, what the change mechanism costs in elapsed days rather than money, what happens at the next break point, and what the supplier has to demonstrate to be paid. None of it is difficult. It is simply nobody’s obvious duty, which is why it usually goes undone until the first serious dispute.

The same applies to the budget. A delivery manager who can say what the team costs per fortnight can reason about whether a two-week delay is worth avoiding at a given price. One who cannot will treat every delay as equally bad and every acceleration as equally good, and will spend the team’s goodwill on things that did not matter.

The dos, condensed

Convert dependencies into named people and dates. Make the reporting of bad news cheap and act on it visibly. Measure flow, not effort. Read the contract and the budget. Protect the team’s pace, because a team that has been pushed through three crunch releases delivers less in a year than one that never was.

And accept that most of what determines delivery was decided before the team formed, in a business case, an operating model and a set of contracts. The role’s real leverage is in being present when those decisions get revisited, which requires the standing described in the framework rather than the ceremonies described in the certification. The neighbouring question of who decides what gets built is covered in product management, in about three minutes, and the wider argument about whether any of this constitutes agile is taken up in most agile transformations stop at the stand-up. Both sit under SaaS and enterprise software.