Program Management: Lessons learned from an ERP

deployment into a $1B subsidiary run with legacy software

Change Management/Training
1. Cannot overestimate the effort required to train users
2. Ideally, have at-hand support at every location for the first week or two.
3. Training plan needs to include classroom-style with hands-on demos, plus follow-up
assignments the users can do at home. Participation in training must be tracked.
4. Identify hot spots locations where there is a pattern of disengagement via lack
of participation in training. Use top-level governance to address
5. Expect a dip in peoples performance for the first few days of launch, partly due to
training, partly due to bugs. This many mean some overtime hours for people to
catchup on activities at the start or end of the day.
6. Highest level leadership must impress the importance of the launch to the field
staff and emphasize the need to attend training and complete follow-up activities.
7. Do surveys on engagement: do people think of this system as their system, or
something that those other people are making them take? Are there things in
the new system that they are excited about? On launch day, will they be looking
for ways to work through training/system issues, or use issues as an excuse to stop
trying?
8. Banners, posters, pocket cards, t-shirts, hats, etc. should all be used to get people
in the right mindset. Include status in every edition of the corporate newsletter
and on a prominent place on the website.
9. Ideally, the ERP deployment should be declared the #1 priority for the company.
That way, as resource needs conflict with program needs, the right
people/money/equipment can be moved into place quickly.

Program Management: Lessons learned from an ERP

deployment into a $1B subsidiary run with legacy software
Software Development
1. Use mocks to confirm integrity of data-mapping via live testing. Include in the
program plan.
2. Allocate sufficient resources to proactively confirm data integrity. Automation
preferred.
3. Develop and use a regression test suite, ideally automated. Opportunity for offshore resources to run scripts.
4. Allow for the fact that data issues can drive software development (ex: the
definition of a database field can drive functionality vs the other way around). Tie
the database developers to the other code developers (i.e., dont let walls develop
between the two teams).
5. Agile approach is recommended, even if it has some waterfall elements. Especially
incorporate:
a. 2-week sprints, with stories
b. Tracking of velocity (planned vs actual)
c. Daily scrum meetings (note, these are SHORT, 15 minute meetings)
d. Implement end-to-end stories, where possible
6. Do not neglect reports: these will be needed on launch day. One suggestion:
track reports as a workstream in the program plan.
7. Take action on teams that are chronically behind schedule. Add/change resources
as needed.
8. Use the agile velocity metrics to identify bottlenecks. Address bottlenecks
aggressively add resources, even if it slows things down initially.
9. Have a bug taxonomy (i.e., critical, severe, major, minor), based on levels of
disruption to business process. Project status should include status of critical and
severe bugs. By definition, the product cannot launch with ANY critical bugs, and
only a small number of severe bugs.

C. Program Management: Lessons learned from an

ERP deployment into a $1B subsidiary run with legacy
software
Launch Day activities
1. Establish a war-room where issues can be brought
2. The cutover plan needs to be in the form of detailed checklists that have been
validated for completeness, accuracy, and timing via the Mock practice sessions
prior to launch.
3. Name a Release Coordinator (probably NOT the program manager) who will be the
focal point for launch day activities
4. Ensure key resources (help desk, developers) are proactively monitoring the
system
5. Be ready to triage bugs, separating training issues from system bugs will require
technical expertise. As a result, the normal help desk will probably NOT be the
place for problem calls.
6. Have a criteria, not a timeframe for transitioning from hypercare to operational
mode (example: no remaining Critical or Severe bugs).

Program Management: Lessons learned from ERP

deployment into a $1B subsidiary run with legacy
software

Program Management
1. Have an architecture diagram that captures the target system and a program plan
at the right level of granularity (not too high, not too low).
2. Maintain ONE risks and issues log. Score risks and issues by severity (both) and
probability (risks).
3. Hold governance reviews held to a strict schedule, using a set format (example:
decisions required, status of deliverables, timeline, and budget, outstanding risks).
4. Change approvals: adding scope is not acceptable during the late stages of the
program. All new requirements must be agreed by the Program Manager. Guard
against new requirements masquerading as Critical bugs.
5. Culture: risks and issues must be brought forward. Programs are red, not people.
Identify a problem early and it belongs to us, identify it late, and it belongs to you.
6. Ensure that everyone understands the Program Manager is accountable for the
success of the program. The Program Manager is accountable to the Steering
and/or Executive Committee for the program. If necessary the Program Manager
can be role fulfilled by two people aka two-in-the-box: an IT lead and a business
lead.
7. Be ready to block out vacation days near launch windows. Anticipate summer and
school vacation schedules.
8. Program Plan needs to extend past launch day to include month-end and quarterclose financial activities in the new system.
9. Are managers walking the halls, celebrating milestones, tracking how their people
are doing both agains their objectives and emotionally?
10. Make status visible: Kanban boards, poster-sized printouts of project status
(updated weekly). Be clear that project status is not a secret, send the same
material used for the executive committee reviews out to the team.
11. The skillset in the PMO should be commensurate with the size, scope, importance,