A Non-Traditional Approach to Technical Implementations

One of the more challenging aspects of large-scale technical implementations is making sure the technical design sufficiently meets the needs and expectations of those who will be using the new system. Although training is typically thought of as the mechanism that bridges a system’s development to wide-scale deployment, an additional opportunity exists to have training contribute during the early phases of a project where system requirements are being established.

At the start of an implementation, balancing technical and end-user needs is less difficult. The focus is on creating momentum as the team’s members begin to settle into their respective roles. It's a fast learning curve, with each person trying to get their hands around how to take the original concepts and turn them into meaningful tasks. There's a general sense of progress, mostly because there is so much to do.

At some point, the project takes a turn. People peek out from behind their work plans and realize months have gone by. They can point to hours upon hours of work, and hundreds of folders, files, and emails moving this effort forward, but the "go-live" date that originally looked so far off is now just around the corner.

Inevitably, everyone's work is segmented across mini-teams – groups that are responsible for different elements of the larger project. What results is often a “silo-effect”, where each of these small groups begins working on their part of the project as if it were a stand-alone effort – rarely communicating to the other groups who are also acting in the same way. Project-wide meetings get replaced with mini- team meetings, further isolating the groups from each other.

One of the concerns across all the different groups is when and how to communicate the upcoming changes to the user community. On the one hand, project managers are concerned about bringing end-users into the process too early, possibly leading these users to declare that the anticipated change won't meet their needs. On the other hand, communicating the changes too late in the project runs the risk of not getting organizational "buy-in".

All the while, "training" is considered premature. And here's the fallacy; the belief that training's primary roll begins when the system is ready to roll out. When utilized properly, training can be a catalyst to bridge early design concerns and user needs. Schedule a pilot training during the design phase of the project and watch what happens. The discussions shift from mini-team progress objectives to what needs to happen across teams for the system to be ready for end-users.

What does this tell us? Project sub-groups alone cannot keep a unified user experience at the forefront; that training and communication can play a critical role in keeping the technical design squarely focused on the user environment – a holistic view which can help avoid costly design mistakes, omissions or mismatched functionality.

Here are some examples of how a training group (or “Training”) can help bridge the gap between early technical design and end-user needs.

1. In the early design phase of the project, use the training group to assist the team in communicating technical design requirements.
Technical people can use help in communicating their work across teams. By assisting project team members with the communication element of their design, Training can provide a valuable service at a time when everyone can use simple ways to learn from each other. It also enables the training group to get up to speed on the scope of the system changes and puts them in a collaborative relationship with people who can help with training needs later on.

2. Make sure the training group attends as many technical meetings as they can. In most cases, inviting Training to design meetings will never cross the technical team’s mind. The reality is that these meetings provide more information than any individual interviews that may be done. Even if they only listen and take notes, Training will learn very quickly who knows what, and who is in a position to help down the road.

3. If training is provided by an external resource, integrate a core team of employees to share in the delivery of the program.
Bringing together individuals from various areas of the user community to collaborate on the project will have a very positive affect on how the larger community views and accepts the change. Get this group involved in the process as early as possible.

4. Utilize visuals and graphics of the change being worked on.
When project work is represented in diagrams versus narrative format, people working on the system are better able to have a dialogue and collaborate with each other. Training is in an ideal objective position to help with this task. In addition, this becomes important material for the training programs that will be designed.

5. Have Training ask functional people for input on presentation material.
Developing a solid communication link establishes a rapport between the functional and training group. It also allows for the extraction of critical presentation material content and demonstrates to technical people how to think from an end-user perspective.

6. Schedule a communication/training pilot.
The key for this component is to get it scheduled. With just a date in place, the technical group will be more receptive to user issues, because they know their work will be shared with key stakeholders. Besides the practice opportunity, the planning for a pilot and event itself can be used to uncover outstanding technical issues that need to be resolved.

7. Open the lines of communication between the technical and training team.
While Training needs to show respect for the technical team’s available time, technical people want to contribute to the creative process of training. Encourage this dialogue.

8. Have Training facilitate technical meetings.
This will accelerate Training’s ability to synthesize information across groups and offers a mechanism to keep the lines of communication open.

Integrating a training strategy early on is an underutilized catalyst that can bring teams together in pursuit of a common goal. Although training is often perceived as the final step in an implementation process, it can be used to facilitate better communication among the team. Of even greater value is its ability to drive and focus change that gets buried under mountains of tasks.