There are ways to “sneak” educational opportunities throughout a software implementation project.
I am currently working on a major association management software upgrade and re-implementation project. The organization I am working with just suffered through a failed CRM implementation, so they feel tremendous pressure from their Board to prove that they can upgrade and improve the way they do business.
They had a list of business priorities and things they wanted to see come out of the project.
The leadership is willing to spend significantly on, and provide the time for, training.
In return, they wanted to see increased utilization of the tool, improvements in some very ineffective work processes, and evidence of progress during the project.
Throughout the project, we purposefully designed the activities we would have to do anyway for an IT implementation as participation and learning opportunities.
Baseline training from the vendor. This was done as soon as the test system with the organization’s data was hosted. This allowed for a bit of contextualization and a really good first pass of the system.
- For the folks who lived and breathed in the current system, it provided a solid overview of new navigation and allowed them to ask questions.
- For the folks who are going to be strongly encouraged to use the new system, it allowed them to also ask questions and start figuring out ways to make the tool work for them.
- All of the sessions were recorded for reference.
Business Analysis meetings. This organization had gone through a very extensive requirements cycle with little to show for it. Keeping that in mind, the vendor Business Analyst team referenced those requirements and asked some key questions to validate what they had + did some demos of possible solutions. Participation in these meetings helped the staff begin to process the changes that need to be made and what improvements they could make to how they operate. The vendor Business Analysis team then scampered off and began writing down their recommendations. It was heartening to hear after each meeting – “You know, I feel like we are finally getting somewhere.”
Test Script Jams. I re-purposed this from the concept of Documentation Jams used by The Storytelling Studio. I sat with each business unit, after poring through all of the notes I took during project initiation and the business analysis meetings, and walked with them through each of the tasks they perform for their job. It was divided into Daily / Weekly / Monthly / Annual processes. We want these test scripts to be as thorough as possible.
Test Script Development. We are currently at this part of the process as I write this. I am working with a couple of people on the project team who have been designated full time for this project to create the steps to perform each task that was identified in the Test Script Jams. At least one of these people will wind up being the “voice” of this solution during the primary implementation stage and in operations. The steps developed during this initial draft and during testing will form the foundation of the training and support documentation for the organization.
Process Training Round 1. After we received the Business Analysis recommendations and completed the Test Script Jams, we started putting together outlines for the vendor to deliver the first round of training for each of the business units. This training is meant to focus on how each unit will use the tool and prepare them for testing. As a result, the focus will be on specific steps and workflows vs. a broad overview. We will take the feedback from this training and the testing and use that to create the final implementation and operational training for this tool. Plus, this is another opportunity for exposure.
Testing Jams. This is also known as “User Acceptance Testing”. We put together 2 hour blocks of time to allow the business units to focus on testing. This is also a “safe zone” for them to practice and play with the system. Sneaky practice time. They will learn the most during this particular process since they are getting their hands dirty.
Documentation Jams. We are in the process of putting together a Knowledge Platform for documentation and training. The knowledge platform will be like a wiki, allowing for ease of editing as processes evolve in the field. I am encouraging the organization to use the Knowledge-Based Support model to operate this platform so that the workload of keeping the information updated is not on one person and is considered a natural part of operations. The Documentation Jams, themselves, will be blocks of time to allow the business units to document the final processes within that Knowledge Platform. Again – getting their hands dirty.
Implementation Training. This is what most people think of when they think of training for an IT implementation. All of the final documentation and processes will be reinforced here. At this point in the project – the staff have already been given multiple opportunities to learn the new tool and processes. My goal is that by the time we get to this part – the staff will be sick of “learning the tool” and go-live will be uneventful with minimal support needed.
The key difference that we designed this project for maximum participation from the business. Anyone who wants to play with us can. It’s not just the project team or specially-identified people who are involved. Someone has questions? I add them to the group. They get all communications and training for the “Power Users”.
You will notice I am not singling out people based on how well they use the current tool as my “Power Users”. I define a “Power User” as anyone who is remotely interested in this project. This is how you encourage utilization – through involvement. The experts provide feedback on how well the tool works and will stretch it to its limits. The new users get a safe place to learn, multiple exposures to the tool, and provide feedback on usability. My hope is that the “experts” begin to take some of the newer users under-wing as they get more comfortable with the new interface.
To do this, there are a few prerequisites:
- The organization needs to be willing to accommodate testing and training in their project timing. Too many organizations focus on “getting it running” and testing / training becomes a last minute panic job.
- The organization’s leadership needs to reinforce the importance of project participation. Making it “cool” or “fun” would be even better so it is more voluntary.
- The organization needs to be willing to provide their employees the time and space to learn this new tool and any new processes vs. piling the project on top of the usual work.
Of all of the prerequisites, the first one is mandatory. You have to accommodate the testing/training time and guard it as sacred. Your IT folks and contractors will happily eat into that time for their tasks, leaving your trainers to (again) try to develop materials with a changing environment.