How to read DelPulse
DelPulse is a product operating model for business platforms. New functionality is delivered through programmes and projects; once live, stable and handed over, it is owned and improved as a product.
How DelPulse is organised
- Five layers. Portfolio funds; Programme and Project delivers new functionality; Network coordinates several organisations; Product owns and improves what is live; Team builds, tests and releases.
- Three flows. Project to product for new functionality, Demand to value for change to live products, and Service management for keeping live services running.
- Foundations shared by all: the safe change pipeline, the DelPulse Value Index, measures, the maturity model and Jira.
- Levers: the established frameworks DelPulse draws on, each with its official sources.
Project or product?
Ask one question at triage: is this new functionality, or a change to something live and handed over? New functionality follows the project lifecycle. Changes to live products follow the demand-to-value flow. The mode test makes the decision consistent.
How to read an element page
Every role, event, artifact, board, stage and phase has its own page with the same sections, in the same order:
- Why it matters: the problem it solves, and key facts such as when it happens and who leads it.
- How to run it: the steps, in order.
- Rules: what must happen. A default tag means you may tailor it and record why.
- In the DelPulse workspace: where it lives in the platform, and how to set it up if you use Jira or Azure DevOps instead.
- Draws on: the levers behind it, linking to their official sources.
- Connected: the roles, events and artifacts it works with.
Where to start
- Read the DelPulse rules.
- Take the self-assessment to find your starting configuration.
- Read the layer pages for that configuration.
- Use Handover for any live project.
Colours and icons
- Portfolio
- Programme and Project
- Network
- Product
- Team
- Foundations
Role Event Artifact Foundation
Glossary
| Term | Meaning |
|---|---|
| CAB | Change advisory board: the group that approves changes to live systems. |
| CRQ | Change request: the record raised for a change board. |
| CSO | Safety and Compliance Officer: the person responsible for safety risk management under the relevant safety standard. |
| DPIA | Data protection impact assessment. |
| ELS | Early life support: intensive support immediately after go-live. |
| Gate | A decision point at the end of a lifecycle phase, with written criteria. |
| Handover | The formal transfer of a product from a project to the Product layer. |
| Pulse Cycle | The 12-week, six-sprint rhythm of the Network and Portfolio layers. |
| PVI | DelPulse Value Index: weighted value × urgency ÷ size, used to order backlogs. |
| RAID | Risks, assumptions, issues and dependencies. |
| SRO | Senior Responsible Owner: the one person accountable for a programme or project. |
| Stabilisation | The phase after ELS that prepares a live system for handover. |
| UCD | User-centred design. |
| WIP | Work in progress. |