Organizational Change Management (OCM) is the art of leading people through change. And big change, such as implementing a system that significantly changes the way you do your job, needs space and time for people to transition successfully. That's why, to an OCM professional, Agile development sprints for a major system implementation can fly by. Before you know it you feel you need more and more time to get users ready for the deployment, and everyone's looking to you to get them there without delaying the release. To help solve for that, I've found utilizing some key assets throughout the product-build sprints keeps me on schedule, arriving at the release date with users in a very healthy readiness position.

What's important when?

The Goal of the Release Product– There has to be some sort of goal or minimum design that defines the first release. Ensure the goal is clearly communicated at the beginning of the project to anchor a high-level "to be" vision (that may be the most you know about "to be" for a long, long time!).

The System Architecture/Work Flow Design – The developers have to be developing against a design of some sort, so get your hands on it as soon as possible to frame the training needs and curriculum design.

The Stories – Read them at the beginning of each sprint to assess people, process, organization, and system changes and impact. Validate them at the end of the sprint during a product demo.

The Readiness Activities – Determine how you're going to address the impacts and when after discovering them from the stories during each sprint, in order to execute the change readiness activities before release without unnecessary extension of the release date.

The Beta Users – Engage them in demonstrations and focus group sessions from the beginning, and throughout the development process, to provide actionable system and process feedback. Also engage them during testing to practice the training scenarios and identify any issues that will need to be addressed in training.

The Playback Demonstration – See the functionality produced at the end of each sprint to validate impact assessments and any artifacts in the works (i.e., training materials).

The Test (or Training) Environment – Use this site for iterative training development during the sprints, demonstrations to the Beta Users, and "live" training delivery (this significantly reduces training development time).

The Instructor Train the Trainer – Ensure an opportunity, before training, to allow instructor teams to practice the classroom technology, course content, and time management of the course flow.

The Users' Training – Deliver training within two weeks of the release to maximize learning retention. Include workshop opportunities for students who need extra practice. If the user base is larger than a two-week training schedule can sustain, consider a phased release.

Hands On Training Design – Inevitably, we deliver training while some portion of testing and last-minute system readiness changes are going on. So, deliver training using the Test (or Training) environment. This will minimize your training materials, and avoid wasting precious time reworking them. Also, use the Beta Users in the classroom to support the instructors, since they have proficiency with the system at this point.

The Floor Walkers – Leverage the Beta Users as Floor Walkers at Go Live to quickly address issues and facilitate the business transition to BAU problem solving.

These assets can help you find that precious OCM space and time throughout the system development process, and lead your users through a successful system implementation.