Phase 1: Stabilisation

Learning Objectives

By the end of this lesson you will be able to:

• Apply the seven stabilisation steps to a failing data migration project
• Explain how to buy time to re-plan without escalating panic
• Describe how to consolidate scattered issues into a single DQR log
• Identify the political approach needed to re-engage the business under pressure

What Stabilisation Means

Stabilisation does not mean fixing the migration. It means stopping the situation from getting worse and creating the conditions under which controlled, effective work becomes possible.

The most common mistake in a crisis is to carry on doing more of whatever was being done before - faster, with more people, with more pressure. This accelerates the wrong activity. Resist it.

Stabilisation is complete when you have:

• A single, consolidated view of all outstanding issues
• The business re-engaged, at least informally, as a partner in the solution
• A realistic plan that can be communicated to senior stakeholders
• Legacy data stores placed under version control

Step 1 - Understand the PDM Foundations

Before anything else: if you have been brought in to rescue a project that has not been run on PDM principles, you need to understand those principles now.

Pay particular attention to:

• The Responsibility Gap - Lesson 01.02. You need to close it, and you cannot close it if you do not understand why it opened.
• The Golden Rules - Lesson 01.03. You will be reapplying all four.
• Key Data Stakeholder Management - Lesson 03.05. You are about to need stakeholders you may not have met.
• Release and Configuration Management - Lesson 04.01. This is how your recovery plan will be structured.

You do not have time to implement everything perfectly from the start. But you need to know what you are aiming for.

Step 2 - Buy Time to Re-Plan

The urge to “do something” is understandable. It is also dangerous. A plan built in panic will compound the existing problems.

You need time to:

• Assess the full scope of the problem
• Build a realistic release plan
• Communicate that plan to all stakeholders

How you buy this time depends on the political environment. The enterprise will be under pressure and will want visible activity. The following two steps (3 and 4 below) are both necessary and visibly purposeful - use them to demonstrate control while buying the space to re-plan properly.

Step 3 - Consolidate All Issues Into a Single DQR Log

This is non-negotiable and must happen immediately.

Every failing project visited in the field has the same problem: there is no single repository for migration-related issues. Problems are tracked in emails, personal spreadsheets, test defect logs, and verbal agreements. No one has a complete picture.

Your first concrete action:

1. Gather every outstanding issue from every source - emails, tickets, meeting notes, spreadsheets, individuals’ heads
2. Enter each issue as a DQR on a single DQR log
3. Tag each DQR as either data migration or not data migration - triage immediately
4. Prioritise the data migration DQRs with business input (this is how you start closing the responsibility gap)

The act of prioritisation requires business involvement. This is intentional - it draws the enterprise back into the project as a participant in solutions, not just a recipient of problems.

Refer to Lesson 03.08 - Data Quality Rules Concepts and Lesson 03.09 - Working with the DQR List.

Step 4 - Reopen the Landscape

A failing project has almost certainly missed legacy data stores. Under normal delivery pressure, the team focused on the major systems being replaced and ignored anything that looked peripheral.

Now those peripheral systems are surfacing as blockers.

You will not have time to conduct a full landscape analysis. But you must:

1. Identify every data store that is being raised as a source of problems - including those outside the original scope
2. Assess each one rapidly: is data from this store needed in the target?
3. Place every identified store under version control, even informally

This is also a political opportunity. The business domain experts who have been saying “I told you so” are suddenly your most valuable allies. Do not be defensive with them. Acknowledge that the landscape was incomplete and ask for their help to fill the gaps. This is how the enterprise re-enters ownership of the migration process.

Refer to Lesson 03.01 - Landscape & Discovery.

Step 5 - Create an Emergency KDSM

You need to know who the data stakeholders are, even if you cannot formalise their roles in the usual way.

Build a working Key Data Stakeholder Map - it does not need to be a formal document at this stage. You need:

• Who knows each data domain
• Who has authority to make data quality decisions
• Who can approve a data compromise if a less-than-optimum load is required

In a crisis, you may not be able to get formal sign-up to ownership responsibilities. The most you may achieve is that stakeholders are willing to lead without formally accepting liability. That is enough to work with. Document what you have and proceed.

Refer to Lesson 03.05 - Key Data Stakeholder Map.

Step 6 - Get the Business to Own the Problem

This is the hardest step and the most important one.

Golden Rules 1 and 2 have been violated. That is why the project is in trouble. Reinstating them requires honesty about what went wrong - but honesty delivered carefully.

What to say: “You were right. We should have involved you earlier. We are responsible for that. Now we are in this situation, how do we get out of it together?”

The enterprise is unlikely to rush forward to accept formal responsibility when everything is visibly failing. Do not ask for formal responsibility. Ask for shared involvement in the solution. Ask for their knowledge. Ask them to co-prioritise the DQR list.

The business domain experts who have been excluded will find satisfaction in being heard. That satisfaction can be channelled into active participation if handled with sensitivity.

Step 7 - Stop Fixing, Start Consulting

Rein in the reaction to fix every problem as it surfaces.

In the early stages of stabilisation you do not know where all the data gaps lie. You will find more as you go. Trying to fix everything immediately leads to thrashing - half-fixed problems, wasted effort, contradictory changes.

Instead:

• Accept that the problem space is not yet fully defined
• Explain to the team and stakeholders that the process will be iterative
• Commit to fixing things in a planned, release-based sequence - not in the order they are discovered
• Plan explicitly for more gaps to emerge and build buffer into the release plan

This is the transition from reactive firefighting to controlled delivery. It is the end of stabilisation.

Recognising When Stabilisation Is Complete

Stabilisation is complete - not when the project is fixed, but when you can answer yes to all of the following:

When you can say yes to all six, you are ready to move to Phase 2.

Key Takeaways

• Stabilisation is about control, not speed - resist the urge to do more of what was already failing
• A single DQR log is the immediate, non-negotiable first concrete action
• Reopening the landscape and engaging “told you so” stakeholders is a political opportunity, not just a technical task
• You may not get formal business ownership - shared involvement in the solution is enough to start with
• Stabilisation ends when you have a complete issue picture, business engagement, and a communicable plan

Previous lesson: 09.01 - When Migrations Go Wrong

Book Reference

Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):

• Chapter 17 - Rescuing Failing Data Migration Projects