Training Plan: Enterprise Systems

Similar to the Data Migration Plan and Testing Plan, in preparing the Project Document and the Detailed Project Plan, a few other planning documents are created including the Training Plan.

There are generally multiple levels of training provided during a project beginning with project team training. During the project, there may be validation training for GxP systems, testing training prior to test execution, and production cutover training which may extend past Go-Live depending on the system roll out.

At the beginning of the project, before contracts are signed with implementation partners, the Project Manager in collaboration with the implementation partners and the functional leads should begin to draft the Training Plan to make sure there is a clear understanding of who needs to be trained, on what, and when. This impacts the scope of the project, scope of work by implementation partners, internal resource requirements, and the overall timeline.

As the new system (or systems) is (are) understood by the internal project team, and as the implementation partners and project team gain a better understanding of the business processes and system users, the Training Plan is revised and expanded to include the additional details until it is finalized prior to execution.

Waiting to create the plan may (I would argue that it will) lead to project scope changes and delays, similar to delaying the development of the Data Migration Plan or the Testing Plan.

Who creates: Project Manager in collaboration with the functional leads and implementation partner.

Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX have documents that are approved by the functional leads and Business Sponsor. Validated system (GxP) documents are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.

When: an initial draft is generated as part of the project planning and revised throughout the project as more is learned and the training specifics are fleshed out. If approvals are required, it is approved prior to execution.

What’s Included

General Information: this section provides a high level summary of the training to provide context for the team. It may include what training material will be generated, the environment/instance requirements, who will conduct the training, work instructions, when the training will occur, and how the training will be communicated / scheduled.

Logical Breakdown of Training and Specific Details: in these sections, the training is broken down by group or type of training depending on what makes sense for the project. It includes security access requirements, who will provide the training, length of training sessions, and when it will occur. It also captures the details on how the training will be provided and who and how people will be invited. It also includes how people will get access to the production system once they have been trained.

Approval(s) (if applicable: I recommend that despite the controlled status of the system (SOX, GxP), that there always be a document approver even if it’s just the Business System Owner. This section will have lines for the approver signature and date.

Other Things to Note

For GxP systems, if it’s not documented, it didn’t happen and there are requirements that users be trained prior to being granted access to a system. Creating and executing a solid training plan ensures this requirement is met and a summary of the executed training is one of the ways that satsifaction of the training requirement can be demonstrated.

Do not assume the implementation partner will train the end users prior to production cutover. Generally, they assume a train-the-trainer approach and expect the project team members will prepare for and provide the training. I highly recommend that the internal project team members own the training and not rely on the implementation partner. Poor (or no) training leads to data and system issues that the client (not the implementation partner) will be left to deal with.

Assuming there are users beyond the project team, the planning allows for communication to others within the organization who may not be familiar with the project and the impact it will have on them and their processes. This should be part of a broader change management initiative but sometimes smaller companies don’t take this into consideration. The last thing you want are surprised end users, especially at the executive / senior level.

How long is this document? Once again it depends on the complexity of the project and the types of training that are required by the team and the project. My last training plan was seven pages long and included four logical training sections.

Why Share This Now? Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.

I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!

Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.

Have Questions or Require Assistance?

Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.

About the Author

Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.