Delivery Modelling
Objective¶
Generate a "point in time" alignment between product management, design, engineering leadership, and key business stakeholders on:
- the order in which problems will be addressed in the medium-term (up to 9-18 months).
- dependencies between problems and with other business objectives.
- ownership of problems.
- our perception of the scale and types of the work required.
Delivery Modelling¶
Delivery modelling is a collaborative event during which a delivery model is produced or updated.
During the event, the Problem Owner will share problem value propositions and any relevant information - this will vary depending on the "maturity" of the problem (how far through the lifecycle it is).
Participants will consider and discuss dependencies, work involved for all disciplines (such as product management, design, engineering) and the likely "rough order of magnitude" of the work, and the Problem Lead will document these details.
Participants will use information from up-to-date delivery plans, to provide more granular detail.
Warning
Rough Order of Magnitude (ROM) is an estimation approach which uses limited information to create a speculative indication of the scale of work required. ROM estimates are highly likely to be inaccurate, particularly given that solutions are unlikely to be well defined.
Where clearer estimates are available, these should be used in place of, or as part of ROM estimates.
The problem ownership will be assigned (or re-assigned), in doing so the delivery team is determined. This may change at a later time (e.g. future modelling session).
Delivery Models¶
The Delivery Model is a single, evolving artefact produced collectively. It provides a reference for the outcomes of the delivery modelling discussions.
A delivery model shows the agreed approach to solving problems in the medium term, based on the information available at the time of the modelling.
Model not Plan
A delivery model is not a plan, nor a commitment.
It can be used to inform and evolve targets, but it must not be used to create deadlines.
Responsibilities¶
| Owner | Responsibility |
|---|---|
| Problem Leads | Accountable for preparing and sharing problem information and capturing outcomes of discussion, and for ensuring Key Problem Stakeholders are involved appropriately. |
| Product Management | Responsible for participating in modelling, and sharing relevant product insights, and providing relevant estimations. |
| Engineering Leadership | Responsible for participating in modelling, sharing relevant technology insights, and providing relevant estimations. |
| Design Team | Responsible for participating in modelling, sharing relevant user/design insights, and providing relevant estimations. |
| Delivery Management Team | Accountable for ensuring that modelling is performed and models produced are current, maintained and accessible. Responsible for organising delivery modelling events. |
Triggers¶
Delivery models need to remain "fresh". As a delivery modelling session produces "point in time" view, this may become outdated due to a number of factors, such as:
- Scope of work changes, indicating the ROM estimates are inaccurate
- Problems are broken down and can be prioritised and solved independently
- More granular estimates are produced, indicating the ROM estimates are inaccurate
- Business priorities change
The models will likely need to be updated each quarter, but whenever the model is determined to be "stale", a modelling session should be scheduled in order to make it fresh again.
Note
All Problem leads, Product Managers, Engineering Leadership members, designers, and delivery managers are collectively responsible for flagging that the delivery model is stale, as and when they discover relevant information.
Toolkit¶
Toolkit