WHY THIS MATTERS TO YOU

General project management principles apply to any project. But ERP and WMS implementations have specific characteristics that create predictable failure points not covered in a generic PM course. If you have lived through a bad implementation, you already know some of these. This module names them, explains why they happen, and gives you the tools to prevent them.
This is where your background as a BA or consultant intersects directly with everything in this course.

What Makes Implementation Projects Different

ERP and WMS implementations are complex for reasons beyond technology. They change business processes, which changes how people work, which creates organizational resistance. They involve data migration, which exposes years of data quality problems that nobody knew existed. They require decisions that nobody has ever made before, which creates analysis paralysis and delayed sign-offs.

Implementation-Specific Risk	Why It Happens	How to Manage It
Scope grows after go-live commitment	Stakeholders see the system and realize they want more	Lock scope before UAT begins; use change control for post-commitment additions
Data migration takes longer than planned	Data quality issues surface only when migration scripts run	Do a data audit early; build migration timeline with discovered complexity, not assumed complexity
Key SMEs are unavailable during critical phases	They have day jobs and the project is secondary	Get formal availability commitments; escalate non-attendance immediately
UAT reveals design gaps, not just bugs	Requirements were incomplete or misunderstood	Hold design sign-offs before build; use prototypes to validate understanding
Training happens too late	Training is often the last thing planned	Plan training as a parallel track, not a phase after everything else
Go-live timing is driven by the calendar, not readiness	Fiscal year end, board meetings, or contract terms create artificial pressure	Define readiness criteria upfront; make go-live conditional on meeting them

The Four Phases of Implementation PM

While every implementation has its own structure, four PM responsibilities are consistent across all of them:

• Discovery governance: ensuring requirements are complete, signed off, and baselined before build begins
• Configuration control: ensuring what is being built matches what was signed off
• Testing management: ensuring test scripts cover all requirements and defects are tracked to closure
• Go-live readiness: ensuring every go-live checklist item is verified before the cutover begins

The Go-Live Readiness Checklist

A go-live readiness checklist is a formal gating document that defines every condition that must be true before the project is allowed to go live. It is the PM’s most important tool for preventing a premature go-live.

• All UAT test scripts passed or approved workarounds documented
• All critical and high defects resolved
• Data migration validated in the production environment
• All users trained and training completion documented
• Go-live support plan confirmed (hypercare team, escalation path)
• Go-live communication sent to all affected users
• Rollback plan documented and tested
• Sponsor sign-off obtained

 

WHAT THEY SAY	WHAT THEY MEAN
We are going live on the 15th no matter what	This is a date-driven go-live without a readiness gate; document the risk in writing and get the sponsor to acknowledge it
UAT found some issues but they are minor	Define ‘minor’ explicitly; classify defects by severity and confirm that all critical items are resolved before cutover
We will fix that after go-live	Some items can wait; document them formally as deferred items with owners and target dates, not as ignored issues
The data migration tested fine in the sandbox	Sandbox data is clean; production data is not; always run a final data validation in the production environment

COMMON MISTAKE

MISTAKE: Treating the go-live date as fixed and letting readiness gates slide to meet it.

What it looks like: With three days to go-live, 12 open UAT defects remain, 40% of users have not completed training, and the data migration ran with errors that were not fully resolved. The PM declares the project ready because the date cannot move. Go-live happens. Three weeks of hypercare chaos follows.

Reality: A go-live that should have been delayed by two weeks is far less damaging than a failed go-live. Define readiness criteria and hold them. If the date must be held, have an explicit conversation about which readiness criteria will be accepted as incomplete and what the plan is for each.

QUESTIONS TO ASK YOUR STAKEHOLDER

Is there a documented go-live readiness checklist with specific, measurable criteria?
Are there open defects from UAT? How are they classified and what is the resolution plan?
Has data migration been validated in the production environment, not just in a sandbox?

Is training complete for all user groups? Is there documentation of training completion?
Is there a rollback plan if go-live needs to be reversed? Has it been tested?

Module Quiz

1. A client insists on going live on a specific date even though data migration has not been validated in the production environment. What should the PM and BA do?
2. Proceed since the client accepted the risk
3. Document the risk formally, have the sponsor acknowledge it in writing, and make the consequences explicit
4. Cancel the project
5. Run migration the night before go-live and hope it works

Answer: B

Why it matters: When leadership overrides readiness criteria, the risk must be formally documented and acknowledged. This protects the project team and creates accountability for the decision.

2. During UAT, users report that several design decisions do not match their actual workflow. This is most likely caused by:
3. A bug in the configuration
4. Incomplete or misunderstood requirements not caught before build began
5. Poor UAT test script design
6. Team members making unauthorized changes

Answer: B

Why it matters: Design gaps found in UAT are almost always rooted in requirements that were not complete or not validated against actual user workflows before build began.

3. A post-go-live defect is found that was deferred before go-live. It was documented as ‘will fix after go-live’ but has no owner or target date. What is the risk?
4. It will automatically be resolved
5. It will be forgotten since the project team has moved on
6. It will be escalated to the vendor
7. It will appear in the lessons learned

Answer: B

Why it matters: Deferred items without owners and dates are rarely addressed. They must be formally tracked with ownership and a committed resolution date.

4. Which of the following is a implementation-specific risk that a generic PM course would not typically cover?
5. Scope changes need change control
6. Data quality issues surface during migration that were unknown at project start
7. Risk registers should be maintained
8. Communication plans are important

Answer: B

Why it matters: Data quality surprises are specific to implementation projects. They are not a generic PM concept but are one of the most common causes of implementation delays.

5. Why is a rollback plan important for a go-live?
6. It is a PMP exam requirement
7. If the go-live fails or causes critical issues, the team needs a documented, tested path to restore the prior state
8. It satisfies the change control process
9. It is only needed for cloud implementations

Answer: B

Why it matters: Go-live can fail for many reasons: data corruption, integration failures, unexpected performance issues. A tested rollback plan limits the damage and gives the team a clear response procedure.