Module 1: The role in context

Understand the purpose of delivery management, its decision boundaries and the behaviours that make honest delivery information possible.

Welcome

This course follows BookWell, a fictional appointment-booking service. Maya guides product priorities, Alex supports delivery, Priya leads engineering and Jordan sponsors the work. Researchers, designers, testers, support colleagues, an internal platform team and an external payment supplier all contribute. The names, dates and figures are invented to make decisions concrete. You can start with little or no delivery management experience; specialist terms are explained as they arise.

The course has 24 in-depth lessons and four checkpoint quizzes. Every teaching lesson contains two to four different activities that ask you to make, sequence, calculate or compare a decision. The activities are for practice. The checkpoint quizzes require 80% to pass and can be retried. There is no final assignment.

View larger

Learning outcome

By the end of this lesson, you will be able to diagnose a delivery condition using evidence of a usable result.

The delivery situation

A useful way to approach the role is to look at the gap between an intention and a result. An organisation intends to improve a service. A team begins work. Between those two points sit decisions, uncertainty, tools, relationships and constraints. Delivery management helps the team navigate that gap.

Imagine a team that starts every week with a full plan but repeatedly finishes less than expected. The immediate explanation might be that people need to work faster. An investigation could reveal something different: a specialist is available only on Fridays, urgent requests arrive through private messages, and finished work waits several days for a release decision. Asking everyone to try harder would leave these conditions intact.

View larger

Activity: Investigate the result

Begin by observing how an item actually reaches a user. Follow a recent example from the first request through discussion, implementation, checking and release. Notice where it waited and where people lacked information or authority. Talk to the people doing the work before proposing a solution.

Your involvement should help create clear ownership. If a specialist must approve something, establish what they need and when. If priorities conflict, bring the appropriate decision-makers together. If a process is repeatedly delaying work, help the team test a better arrangement.

Ownership of delivery does not grant unlimited authority over colleagues. Agree what decisions you can make, what the team decides and what needs another role's approval. Taking responsibility includes making a problem visible when it exceeds your authority and following through until someone accepts the decision or action.

Looking more closely

A useful intervention begins with a specific result and the path work must travel to produce it. Ask what a user can actually do now, which step is still unproven and which people can change the condition. The Delivery Manager may arrange access, convene a decision or make a dependency visible; that does not make them the designer, engineer or product owner. Keep returning to the distinction between activity and delivery evidence. A task count can be accurate yet still leave the customer journey broken.

Your behaviour teaches people what happens when they bring you information. If bad news produces blame, the next warning may arrive later. If every question produces an instruction, colleagues may stop exercising their own judgement.

Aim to make early, accurate information useful. When someone raises a concern, first establish what they have observed, what the impact could be and what support would help. Acknowledge the contribution without immediately accepting their interpretation as the only explanation.

For example, "Testing always holds us up" is an interpretation. "These three items have waited for a test environment since Monday" gives the team something it can investigate. Moving from labels to observations makes disagreement easier to resolve.

Activity: Action or authority?

BookWell in practice

Alex joins BookWell and finds a dashboard reporting that the new booking journey is 80% complete. Nobody can demonstrate a successful booking through the payment supplier's test environment.

Alex asks the team to walk through the journey. They discover that most screens exist, but access to the supplier environment has not been arranged. Alex works with the supplier contact to secure access and with Priya to schedule an early integration check. The useful result is evidence that the journey works, or early discovery of what prevents it.

This intervention gives the team a clearer picture without Alex taking over engineering decisions.

Activity: Define progress

Key points

• Investigate the conditions surrounding delivery before judging individual effort.
• Follow work through to a usable result rather than relying only on reported activity.
• Match every important action or decision with someone who has the authority to own it.

Learning outcome

By the end of this lesson, you will be able to set out decision ownership for scope, technical readiness, spending and external commitments.

The delivery situation

Role titles provide a starting point for a conversation. A working agreement makes the relationship usable.

In the BookWell examples, Maya guides product priorities using customer and business evidence. Priya guides technical choices with the engineers. Alex helps make the delivery plan, constraints and decisions coherent. This division is an illustrative agreement for this team; your organisation may assign responsibilities differently.

This visual shows how BookWell's agreement separates four decisions that could otherwise be described loosely as “owning delivery”.

View larger

Activity: Who decides?

Avoid asking only, "Who owns delivery?" Break the question into specific decisions. Who decides which problem to address? Who can change scope? Who confirms technical readiness? Who authorises spending? Who announces a launch? Who handles an employment concern? These decisions may have different owners.

A Delivery Manager needs enough understanding of colleagues' work to recognise when their involvement is needed. A researcher can explain what evidence supports a proposed journey. A designer can explore how people understand it. Engineers can explain implementation uncertainty. Operations colleagues can identify what must happen when the service fails. Involve these perspectives while decisions are still changeable.

Where a Project Manager exists, clarify responsibility for organisational reporting, funding, milestones and coordination. Avoid creating two plans that tell different stories. Agree one dependable source of delivery information and identify who maintains each part.

Looking more closely

Role clarity matters most when a decision is contested or delayed. A short agreement can identify who proposes, who provides evidence, who decides and who communicates. Use real examples rather than abstract responsibility labels. An agreement also needs an escalation route: if two authorised owners disagree, who settles the trade-off and by when? Review boundaries as the product, team and governance change. Avoid building parallel reporting structures simply because two job titles sound similar.

Some delivery problems persist because the right people have not made a decision together. A meeting should end with a clear choice, an owner for the next action or a well-defined need for more evidence. Invite only the people whose information or authority is needed.

Prepare the decision question before the conversation. Describe the outcome at stake, the options, their delivery effects and any limits on authority. Give participants enough information to challenge assumptions. If a decision is not possible yet, agree the smallest investigation and when the group will meet again.

During the discussion, let technical and non-technical perspectives be heard. Restate disagreement as a trade-off rather than a personal conflict. Ask what each option protects and what it gives up. The Delivery Manager may facilitate without owning the final choice.

BookWell in practice

Maya has told stakeholders that bookings will improve before the summer campaign. Alex has drafted a release forecast. Both think they own the launch plan.

They agree that Maya will propose the smallest useful release, Priya and the team will explain feasibility and readiness, Alex will maintain the delivery forecast and dependencies, and Jordan will authorise the external commitment under BookWell's governance arrangements. Marketing will use that agreed commitment when planning the campaign.

They also agree to revisit the forecast whenever scope or a critical assumption changes. Their agreement is short enough to use in a real conversation.

Jordan, Maya and Priya disagree about whether to release without refund testing. Alex frames the decision around customer harm, evidence, campaign impact and the ability to limit exposure. Priya explains the technical risk; Maya explains user value; Jordan makes the release decision under the agreed governance. Alex records the result and ensures support and marketing receive the same message.

Activity: Agree a launch plan

Key points

• Discuss specific decisions rather than relying on broad role labels.
• Include specialist perspectives early enough to affect the plan.
• Agree how overlapping roles will share information and resolve disagreements.

Learning outcome

By the end of this lesson, you will be able to respond to delivery concerns without blame and test a plausible system cause.

The delivery situation

Your behaviour teaches people what happens when they bring you information. If bad news produces blame, the next warning may arrive later. If every question produces an instruction, colleagues may stop exercising their own judgement.

Aim to make early, accurate information useful. When someone raises a concern, first establish what they have observed, what the impact could be and what support would help. Acknowledge the contribution without immediately accepting their interpretation as the only explanation.

For example, "Testing always holds us up" is an interpretation. "These three items have waited for a test environment since Monday" gives the team something it can investigate. Moving from labels to observations makes disagreement easier to resolve.

View larger

Activity: Respond to a warning

Choose your level of intervention deliberately. Sometimes a colleague needs a direct action: access to a system, an introduction or a decision from a sponsor. Sometimes the team needs facilitation so it can agree its own approach. Sometimes a person wants coaching: help thinking through options. Ask which form of support would be useful instead of assuming.

Be careful about becoming indispensable. If every dependency, meeting and update passes through you, your absence becomes a delivery risk. Make contacts, decisions and working information accessible. Help colleagues resolve recurring situations themselves while remaining available for harder problems.

You will also need to challenge people with greater organisational authority. Prepare evidence and explain consequences. "We cannot do that" may end a discussion. "The proposed date leaves no time to test payment failures; here are two ways to change the plan" makes a decision possible.

Looking more closely

Servant leadership is practical work: make it easier for colleagues to act, while holding difficult facts in view. It is neither passive agreement nor taking every decision yourself. When a concern arrives, move from a label to an observation, then to a testable explanation. Ask who experiences the delay, how often it occurs and what changed before it appeared. This lowers defensiveness and improves the chance of solving the actual problem. A repeated queue may need a change to capacity or policy rather than a motivational speech.

A delivery measure can reveal a pattern without explaining its cause. When something worsens, investigate the work behind the number.

Choose a few recent items and reconstruct their journey. Identify when they started, moved, waited, returned for changes and finished. Ask the people involved what happened at each transition. Use their experience to interpret the timestamps rather than assuming the tool tells the complete story.

Look for recurring constraints. Perhaps completed code waits for review because one specialist is serving three teams. Perhaps items repeatedly return from testing because acceptance conditions are unclear. Perhaps releases happen only monthly even though work is ready each week. These conditions suggest different responses.

Activity: Signs of a system issue

BookWell in practice

A tester tells Alex that a booking can appear successful even when payment fails. Alex thanks them for raising it and asks Priya to help establish the behaviour and its impact. The team records the defect, adjusts its release readiness criteria and updates the forecast.

Alex does not promise a date before the team understands the fix. Nor does Alex require every subsequent defect to be personally approved. The team agrees which problems it can manage and which need wider attention.

BookWell has ten items in progress, and six are waiting for Priya's review. The team discovers that Priya is also resolving supplier issues and supporting another product.

Activity: Choose a response

Key points

• Respond to unwelcome information in a way that encourages accuracy next time.
• Use observations and consequences to challenge assumptions.
• Help the team become more capable of acting without depending on you for every step.

Module 2: Working with teams

Create conditions in which a multidisciplinary team can collaborate, make decisions and maintain a sustainable pace.

Learning outcome

By the end of this lesson, you will be able to identify team conditions that support collaboration, inclusion and sustainable delivery.

The delivery situation

A team needs a practical understanding of what it is trying to achieve together. A list of assignments may organise individual activity without explaining the shared result.

At BookWell, "complete the booking backlog" gives little guidance when new information appears. "Help customers complete and understand a booking without contacting support" gives colleagues a basis for discussing priorities and trade-offs. The Product Manager can refine the desired outcome using evidence, while the team discusses how to pursue it.

Make everyday expectations explicit. A working agreement can describe how new requests enter, where decisions are recorded, when colleagues are available for collaboration and how urgent concerns are raised. Keep it short. An agreement that nobody remembers is unlikely to influence behaviour.

View larger

View larger

Activity: Whose view is missing?

Include people who can be overlooked by the team's usual working pattern. A colleague in another time zone may need written context before a decision meeting. Someone may contribute more effectively after a few minutes to think. Accessible documents and clear language help participation. Do not equate speed of speaking with quality of judgement.

Psychological safety concerns the ability to raise uncertainty, admit mistakes or disagree without fear of humiliation. It does not mean that every proposal is accepted or that commitments have no consequences. You can expect responsible action while treating questions and mistakes as information to examine.

Also check whether the team can actually perform the work it has accepted. A missing specialist, unstable membership or repeated context switching can undermine even a thoughtful working agreement. Make the effects visible and discuss options with the people who control staffing and priorities.

Looking more closely

A multidisciplinary team needs both the right perspectives and a way to use them. Invite research, design, engineering, testing, operations and support when their evidence can still influence a choice. Agree how work enters the team, how disagreement is handled and what information everyone can see. Then inspect whether the agreement works for people with different schedules or access needs. If a supposedly shared process relies on private messages or late meetings, some colleagues may be excluded from decisions without anyone intending it.

A sustainable pace is a condition for reliable delivery, not a reward after a deadline. A team that repeatedly extends its hours may appear to gain capacity while defects, handovers and attrition increase. Look for patterns over several weeks rather than praising a single heroic recovery.

Start with actual availability. Ask about support rota duties, leave, recruitment gaps and specialist bottlenecks. Then compare that capacity with work already in progress and new demand. A plan that fills every hour leaves no space for production incidents, learning or necessary collaboration.

Use a short weekly conversation to test whether the pace is working. Ask what work is being squeezed out, who is carrying the hidden load and which decision could reduce it. Make the problem visible without turning the conversation into a public assessment of individuals. A team may need to reduce work in progress, narrow a release, rotate a specialist duty or obtain a decision from a sponsor.

Activity: Working agreement

BookWell in practice

Sam is invited to review designs after implementation has started. Engineers then receive significant changes and become frustrated. The team agrees to discuss uncertain journeys together before implementation, while leaving space for new learning later.

They also record decisions in one shared place so an absent colleague can understand the reasoning. The agreement addresses a recurring collaboration problem without requiring every design detail to be final in advance.

BookWell's payment integration is late. Priya and two engineers have been working evenings while still handling support incidents. Alex brings the demand and capacity picture to Maya and Jordan. They keep the payment failure path in scope, defer discount codes and arrange a short protected test window. Alex reviews whether the change actually reduces overload the following week. The plan changes; the team is not asked to absorb the same demand silently.

Activity: Check inclusion

Key points

• Give the team a shared result to work towards.
• Make collaboration expectations explicit and usable.
• Check whether skills, availability and participation support the plan.

Learning outcome

By the end of this lesson, you will be able to design a conversation that ends in a usable decision, action or investigation.

The delivery situation

Facilitation helps a group do the thinking and decision-making it has gathered to do. Start by naming the intended result: a decision, shared understanding, a set of options or a plan of action.

If the purpose is simply to distribute information, a written update may be enough. If people need to resolve conflicting interpretations, a conversation may be more effective. Choose the form based on what must happen.

For a decision meeting, identify who has authority to decide, what evidence is needed and whose perspective would materially affect the decision. Share the context early enough for people to prepare. A meeting of ten people cannot compensate for the absence of the one person authorised to resolve the issue.

A short decision record can make the outcome usable after the meeting. This BookWell example separates an observation, the choice made, an owned action and an open question.

View larger

Activity: Prepare a decision meeting

During the discussion, separate observations, interpretations and proposals. "Customers made six support calls about this screen" is an observation. "The wording caused those calls" is an interpretation that may require investigation. "Change the heading" is a proposal. Treating them as different types of contribution helps people avoid arguing past each other.

Create room for quieter contributors. You might begin with a short period of individual note-taking, then invite each person to add an observation. For a remote group, confirm that everyone can access the materials and has an alternative way to contribute if the call fails.

Close by stating the decision or unresolved question, the owner of each action and the next review point. If the group lacks enough evidence, agreeing how to obtain it can be a valid outcome. Do not manufacture consensus just to finish on time.

Activity: Status or decision?

Looking more closely

Begin with the decision question, not the calendar invitation. Identify what evidence participants need in advance and who must be present because they hold knowledge or authority. During the conversation, separate facts, interpretations and preferences; otherwise people can appear to disagree when they are answering different questions. When no responsible decision is possible, specify the smallest investigation and a return date. This makes uncertainty productive. A short decision record is often more valuable than detailed meeting minutes.

Some delivery problems persist because the right people have not made a decision together. A meeting should end with a clear choice, an owner for the next action or a well-defined need for more evidence. Invite only the people whose information or authority is needed.

Prepare the decision question before the conversation. Describe the outcome at stake, the options, their delivery effects and any limits on authority. Give participants enough information to challenge assumptions. If a decision is not possible yet, agree the smallest investigation and when the group will meet again.

During the discussion, let technical and non-technical perspectives be heard. Restate disagreement as a trade-off rather than a personal conflict. Ask what each option protects and what it gives up. The Delivery Manager may facilitate without owning the final choice.

Activity: When evidence is missing

BookWell in practice

Alex facilitates a 25-minute discussion about failed payments. The desired result is agreement on the customer message and the technical condition that triggers it. Sam brings customer observations, Priya explains the system behaviour and Maya clarifies the intended outcome.

They agree a message for the known failure condition. A timeout remains uncertain, so Priya takes an action to investigate it by Thursday. Alex records both the decision and the unresolved condition. The meeting produces a usable next step without pretending everything is settled.

Jordan, Maya and Priya disagree about whether to release without refund testing. Alex frames the decision around customer harm, evidence, campaign impact and the ability to limit exposure. Priya explains the technical risk; Maya explains user value; Jordan makes the release decision under the agreed governance. Alex records the result and ensures support and marketing receive the same message.

Activity: Good closure

Key points

• Design the conversation around its intended result.
• Distinguish evidence from interpretation and proposals.
• Close with clear decisions, actions and remaining uncertainty.

Learning outcome

By the end of this lesson, you will be able to facilitate a difficult team issue while protecting a sustainable workload.

The delivery situation

Disagreement can expose useful differences in knowledge. It becomes damaging when people cannot examine it safely or when the same unresolved tension repeatedly disrupts work.

Begin with specific behaviour and its effect. "You are uncooperative" attacks a person's character. "We changed the agreed interface yesterday without telling the integration team, and their work now fails" identifies an event that can be discussed.

Before bringing people together, understand whether the situation is suitable for facilitation. Routine disagreements about work may benefit from a structured conversation. Allegations of bullying, discrimination or serious misconduct need the organisation's appropriate management or people process. A Delivery Manager should not turn those concerns into an informal compromise session.

View larger

Activity: Open a tense conversation

For a normal working disagreement, hear each perspective and clarify the shared problem. Invite people to explain what they need, what constraint they face and what they believe the other person may be missing. Then identify an action that can be observed and reviewed.

Watch for overload behind apparent disengagement. A colleague who regularly misses meetings may be supporting several teams or responding to incidents. Establish the facts before inferring a lack of commitment. Where workload exceeds available capacity, work with those responsible to change the demand or support.

Feedback is more useful when it arrives close to the event and leaves room for a response. Explain what happened, describe its effect and invite the person's account. Agree the next behaviour and a review point. Your role may be to help the conversation happen rather than to conduct a performance discussion yourself.

Looking more closely

Tension often combines a relationship problem with a delivery-system problem. Listen for specific behaviours and effects, but also inspect conflicting priorities, overloaded specialists and unclear authority. A conversation that only asks people to communicate better may leave the pressure intact. Likewise, changing the workflow without addressing harmful behaviour may not rebuild trust. Keep employment or personal performance matters with the appropriate manager. Your role is to make work and choices visible, support constructive conversation and follow through on delivery changes.

A sustainable pace is a condition for reliable delivery, not a reward after a deadline. A team that repeatedly extends its hours may appear to gain capacity while defects, handovers and attrition increase. Look for patterns over several weeks rather than praising a single heroic recovery.

Start with actual availability. Ask about support rota duties, leave, recruitment gaps and specialist bottlenecks. Then compare that capacity with work already in progress and new demand. A plan that fills every hour leaves no space for production incidents, learning or necessary collaboration.

Use a short weekly conversation to test whether the pace is working. Ask what work is being squeezed out, who is carrying the hidden load and which decision could reduce it. Make the problem visible without turning the conversation into a public assessment of individuals. A team may need to reduce work in progress, narrow a release, rotate a specialist duty or obtain a decision from a sponsor.

BookWell in practice

Engineers say Sam keeps changing requirements. Sam says engineers ignore customer problems. Alex brings examples from two recent items into a discussion.

The team discovers that designs were treated as final even though research was still under way. They agree to label unresolved assumptions and involve an engineer in an early review. They will revisit the arrangement after three items. The agreement does not eliminate change; it makes the uncertainty visible sooner.

Activity: Route the issue

Key points

• Describe behaviour and impact rather than labelling people.
• Distinguish ordinary working conflict from concerns requiring formal support.
• Agree a concrete change and check whether it improves the situation.

Checkpoint

Use these five situations to check your understanding of the work so far. Choose an answer to every question. You need 80% to pass this lesson; you can review the feedback and try again.

After the quiz

Return to any lesson or decision cards you want to revisit. Passing this checkpoint records the lesson as complete.