Module 09 Quiz: Crisis Recovery - PDM Academy

Checking your access…

Sign in to take the quiz

PDM Academy is open access with no payment required, but you need to be signed in so we can save your score. Sign-in takes one click from your inbox.

Sign in to continue

⚠

Complete all lessons first

You need to finish every lesson in this module before taking the quiz. Go back to the dashboard to see which lessons are still outstanding.

Back to your course

Ten questions on stabilising and recovering a failing migration. Retake it as often as you like - your best score is saved.

1Which two root causes are present in almost every failing data migration project?

Insufficient budget and poor ETL tooling An open responsibility gap and uncontrolled issues with no single DQR log Inadequate testing and missing project decomposition Waterfall methodology and lack of Agile experience

2You are rescuing a failing migration, but the programme also has serious ERP and change-management problems. What should you do?

Expand scope to fix all project problems Escalate ERP and change-management issues to their owners and focus strictly on data migration Wait for ERP and change management to stabilise first Merge all issues into the DQR log regardless of category

3What is the most important first concrete action when stabilising a failing migration?

Conduct a fresh landscape analysis Escalate to the executive sponsor Consolidate all outstanding issues into a single DQR log Replace the delivery team

4During stabilisation, business domain experts are saying 'I told you so.' What is the recommended response?

Exclude them to avoid escalating tensions Acknowledge they were right, apologise, and channel their knowledge into re-engaging them as owners of the solution Document their complaints and address them after go-live Remind them the migration team was not responsible for the original plan

5The recovery approach is 'Agile' regardless of how the project originally ran. What does that mean in the PDM recovery context?

Moving to Scrum sprints with daily standups Scrapping documentation for verbal agreements Planned releases, collaborative DQR prioritisation, and iterative delivery Giving the dev team autonomy to fix issues in any order

6A less-than-optimum data load is being considered because the deadline is critical. Under Golden Rule 3, what is required?

The technical lead approves and documents it in the test log The data owner approves the compromise, it is documented as a DQR, and a remediation plan is agreed It is accepted informally to avoid bureaucracy The programme manager approves on behalf of all stakeholders

7In a recovery scenario, should you attempt to complete the Business Transformation Register with data owners?

Yes - decommissioning needs it and it is overdue Yes - data owners are more motivated now the crisis is real Usually no - the conversation is harder in a crisis and risks antagonising owners; log it as a post-implementation item Only if the sponsor specifically requests it

8The supplier is retreating behind its contract during the crisis. What does this typically reflect?

Deliberate obstruction to increase billable hours A rational commercial response to financial exposure and concern about sharing liability for failure Poor project management on the supplier side A lack of technical capability

9How should Scrum teams on the programme be managed during Phase 2 (Planned Recovery)?

They retain full autonomy; the board sets direction but not backlogs They are disbanded and replaced with a single workstream They are subordinated to the DQR/release planning board; product owners sit on the board and backlogs follow release priorities They manage their own DQR lists and report weekly

10Which best describes the 'least-worst-case' approach used throughout Phase 3?

Accepting all compromises without documentation to keep momentum Consciously choosing between bad options, getting business sign-off, documenting the decision and rationale, and moving on without relitigating it Escalating every difficult decision to the sponsor Deferring all difficult decisions until after go-live