Learning Objectives
By the end of this lesson you will be able to:
- Identify which deferred PDM artefacts to prioritise in mop-up and which to defer further
- Explain why business transformation realisation is usually better left until post-implementation in a recovery scenario
- Describe the pressures on both sides of the DMZ in a crisis and how to re-establish working relationships
- Apply a least-worst-case approach to decisions when there is no good option
What Post-Implementation Mop-Up Is
Once Phase 1 and Phase 2 are complete - DQRs consolidated, stakeholders engaged, release plan running - there is a set of things that a well-run project would have completed months ago but that you have had to defer.
Mop-up is not optional. These items will not disappear. The question is which ones to address now and which ones to defer further, accepting the documented risk.
This lesson covers the four areas most commonly neglected in a failing project:
- Business transformation realisation
- Project decomposition
- Reality checks
- DMZ relationship repair
Business Transformation Realisation
A Business Transformation Register (BTR) documents what each data owner will do differently once the legacy system is retired - the business change that makes the migration worthwhile beyond simply moving data from one place to another.
Refer to Lesson 03.06 - Business Transformation Register for the full process.
In a crisis, the BTR will almost certainly not have been prepared. The instinct is to rush to complete it now. Resist this instinct.
The conversation that initiates business transformation realisation - “your legacy system is going away, here is what you need to do differently” - is much easier to have when go-live is months away and still feels abstract. It is much harder when the data owners are watching a crisis unfold and every instinct tells them to cling to the familiar.
Attempting BTR conversations at this stage risks:
- Antagonising data owners who already feel mistreated by the project
- Triggering last-minute scope changes that destabilise the release plan
- Giving stakeholders a reason to delay sign-off on decommissioning
The pragmatic approach: log it as an issue on the programme risk register, ensure it is picked up in the post-implementation review, and accept that it will need to be handled in a post-go-live engagement. It is a least-worst-case outcome, not an ideal one.
Project Decomposition
A properly run project decomposes the migration problem into Key Business Data Areas (KBDAs) early in the analysis phase, independent of physical system boundaries. Refer to Lesson 02.05 - Key Business Data Areas.
In a failing project, decomposition will have been driven by physical data stores - “we are migrating the CRM system” rather than “we are migrating the Customer and Interaction data domains.” The consequence is that cross-system data consistency problems keep surfacing unexpectedly.
At Phase 3 you must make a judgement: is there enough time and political capital to re-decompose the problem along data-centric lines? The honest answer is usually no.
What you can do:
- Acknowledge formally that the decomposition is sub-optimal
- Raise a risk on the programme register: “inadequate landscape analysis means additional migration model gaps may be discovered in later releases”
- Point to the extra iterations in the recovery plan as the mitigation
- Keep the business domain experts engaged so that gaps are surfaced quickly when they appear
This keeps the programme honest without triggering a re-scoping exercise that would consume months you do not have.
Reality Checks
A thorough migration includes reality checks: verifying that migrated records correspond to real business entities, cross-referencing migrated data against existing business knowledge, and confirming with domain experts that what is being loaded makes sense.
Under crisis conditions, there is rarely time for formal reality checking. The approach:
- Use the business domain experts and additional legacy data stores uncovered during stabilisation as informal reality checks - they will tell you quickly if something looks wrong
- Log any concerns as DQRs - apply Golden Rule 3 and get data owners to assess whether remedial action is needed post-implementation
- If matching data to business reality becomes an issue and there is nothing that can be done before go-live, document the risk with the data owner’s acknowledgement
One benefit of introducing DQRs at this late stage is that it embeds a corrective mechanism that outlasts the project. Post-implementation data quality corrections are handled through the same DQR process - the infrastructure for ongoing improvement is already in place.
Repairing the DMZ Relationship
In a failing migration the client-supplier relationship across the DMZ is almost always under serious strain. Understanding why helps you repair it.
Refer to Lesson 04.02 - DMZ & Commercial Interests for the underlying model.
What the client sees
The client feels misled. They allowed themselves to believe the supplier would handle data migration end-to-end. Now they discover that when the supplier said “data migration,” it meant only the final load into the target system - not the upstream landscape analysis, profiling, gap analysis, or data quality remediation. The client has been left to sort out problems they did not know they owned.
What the supplier sees
The supplier is losing margin. It has committed resources to a project that is overrunning, and it can see a significant payment milestone (go-live) receding. It has experienced staff who could help but would expect compensation for the additional deployment. It is also worried about liability - if the supplier becomes too involved in fixing the client’s data, it may share responsibility for the outcome if things go wrong. So it retreats behind its contract.
And there is a configuration management problem: the client requests changes; the supplier implements them; the client’s data no longer loads against the updated validation rules; the client blames the supplier for making changes. The supplier wonders why the client did not understand the impact of its own change requests.
The path to repair
Neither side is simply being obstructionist. Both are responding rationally to their commercial and contractual positions.
The repair approach:
- Recognise the DMZ explicitly. Name it. Acknowledge that both parties have legitimate commercial interests and that the confusion about where the DMZ sits has been a source of problems.
- Establish DMZ-spanning processes. Configuration management that crosses the client-supplier boundary: change requests from the client are assessed for impact on the supplier’s load validation before they are implemented.
- The client sorts out the client side. Data quality issues in the client’s data stores are the client’s responsibility to fix. The supplier should not be asked to lower its load validation standards to accommodate poorly prepared data.
- Be realistic about supplier incentives - without being cynical. The supplier may genuinely want to help. It may have staff who have rescued projects like this before. Find out what it would take to deploy them and take it seriously as an option.
Accepting Least-Worst-Case Outcomes
A recurring theme in Phase 3 is the “least-worst-case” decision. There is no good option - only a choice between bad options of different kinds.
The discipline is:
- Make the decision consciously, not by default
- Get the appropriate business stakeholder to own the decision
- Document it - what was decided, why, who decided, and what the mitigation or remediation plan is
- Move on without relitigating it
A project recovery is not a project done right. It is a project done acceptably, with clear eyes about what was compromised and why.
Key Takeaways
- Business transformation realisation is usually better deferred in a crisis - attempting it antagonises stakeholders and destabilises the release plan
- Accept sub-optimal project decomposition if re-scoping is not viable; raise it as a documented risk with mitigation
- Reality checks can be handled informally via domain experts and the DQR process - they do not need to stop the programme
- DMZ relationship repair requires naming the boundary explicitly, establishing cross-boundary configuration management, and being realistic (not cynical) about the supplier’s commercial position
- Every Phase 3 decision is a least-worst-case choice - make it consciously, get business sign-off, document it, and move forward
Previous lesson: 09.03 - Phase 2: Planned Recovery
Next: 09 Quiz - Crisis Recovery
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 17 - Rescuing Failing Data Migration Projects