Learning Objectives
By the end of this lesson you will be able to:
- Explain how to build a DQR-based release plan under crisis conditions
- Describe how Scrum and Waterfall teams are subordinated to the release planning board during recovery
- Apply Golden Rule 3 when less-than-optimum data loads are unavoidable
- Identify what “planned activity” looks like in practice for stakeholders and senior management
The Transition from Stabilisation to Planned Recovery
Phase 2 begins when stabilisation is complete - when you have a consolidated DQR log, business stakeholders engaged, and a communicable plan.
The shift is significant. You move from reactive (stopping things getting worse) to proactive (delivering measurable improvements on a predictable schedule).
The programme will not suddenly become easy. More data gaps will surface. Senior management will still be breathing down necks. But the difference between Phase 2 and the preceding chaos is that you now have a mechanism for managing what comes next.
Step 8 - Prioritise DQRs and Build the Release Plan
Start with the DQR log built in Phase 1. Each DQR needs:
- Priority - business-led, not technically determined. Which data issues block go-live? Which can be deferred? Which can be accepted as-is with a documented compromise?
- Estimate - a realistic time to fix. Not optimistic. Not padded to hide incompetence. Honest.
- Release allocation - which planned release will this DQR be resolved in? Or is it discounted (deferred post-implementation or accepted as a known risk)?
The output is a release plan: a sequence of releases, each with a defined set of DQRs to be resolved, a date, and a named responsible person for each DQR.
This release plan is your primary communication artefact. It tells senior management:
- What is being fixed
- When it will be fixed
- Who is responsible
It will not tell them what they want to hear (an immediate go-live). But a credible plan, even one with bad news in it, is better than the ambiguity of a project in free fall.
Step 9 - Institute Release and Configuration Management
The release plan only works if the release process is disciplined.
Refer to Lesson 04.01 - Config & Release Management for the full PDM approach. In a recovery context, the essentials are:
- Every fix is a configurable item - tracked, versioned, assigned
- Releases are planned and dated - not “when it’s ready”
- The DQR/release planning board controls scope - no ad-hoc fixes outside the release cycle
- Key data stakeholders sit on the planning board - they approve what goes into each release and sign off when a DQR is resolved
The planning board does not need to be a formal governance body with a charter. It needs to meet regularly (weekly is usually right in a recovery), have the right people in the room (technical leads and data stakeholders), and have clear authority over release content.
Adapting the Delivery Team
If the team has been running Scrum
Scrums will now be subordinate to the release planning board.
Programme priorities flow from the DQR/release plan to the product owners, who manage their backlogs accordingly. Product owners must sit on the release planning board - development priorities need to be visible there.
Work packages (products, in Agile language) are agreed at planning board level and documented as DQRs. DQRs are allocated to releases. The expectation is that each DQR is delivered and unit-tested in time to be combined with other items in its planned release.
Slippage, newly discovered gaps, and defects are reported back to the planning board via the DQR process - not managed informally within the scrum.
Scrum teams accustomed to more autonomy will push back. Be direct: the previous approach failed. This is how it will be until the project is stable.
If the team has been running Waterfall
The same DQR/release board structure applies. The difference is there are no product owners to act as intermediaries between the board and the delivery team - the board manages priorities directly.
Waterfall teams will face a larger culture shift. Short release cycles and collaborative prioritisation are unfamiliar. The benefit is that the Waterfall team’s instinct for documentation and traceability is an asset - DQR records will feel natural to them.
Step 10 - Hold the Line on Golden Rule 3
Golden Rule 3: the enterprise leads, the technologists support.
Under recovery conditions this rule is most likely to be violated in the direction of expediency: loading data that is known to be substandard because the deadline pressure is intense and “we can fix it later.”
There will be times when a less-than-optimum data load is the right decision. The project may genuinely need to go live with known data quality compromises in order to preserve the business case. That is a legitimate judgement.
But the judgement must be:
- Made by the enterprise, not the technical team
- Documented - on a DQR, with the data owner’s name against the compromise decision
- Accompanied by a remediation plan - when will the compromised data be corrected? By whom? Via which release?
Loading substandard data because it is technically convenient, without business sign-off and without a fix plan, is not a compromise - it is a debt with no repayment schedule. It will surface as a post-implementation problem that no one owns.
What “Under Control” Looks Like
At the end of Phase 2, the situation should feel different - not fixed, but controlled.
| Indicator | What it looks like |
|---|---|
| Predictability | Stakeholders know what is being fixed and when |
| Business engagement | Data owners are co-prioritising the DQR list |
| Release cadence | Regular, planned releases are delivering visible improvements |
| Issue management | New problems enter the DQR log and are allocated to releases - not handled ad-hoc |
| Golden Rule 3 | All data quality compromises are business-led and documented |
You will not be popular. The programme may still miss its original deadlines. But you will have a credible, improving situation rather than an uncontrolled one.
Key Takeaways
- The release plan, built from prioritised DQRs, is the primary communication artefact for Phase 2
- Scrum and Waterfall teams are subordinated to the DQR/release planning board - not the other way around
- Less-than-optimum data loads are sometimes necessary but must always be enterprise-led, documented, and accompanied by a fix plan
- Phase 2 ends not when everything is perfect, but when the project is predictably improving
Previous lesson: 09.02 - Phase 1: Stabilisation
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 17 - Rescuing Failing Data Migration Projects