Have you ever had to create a training program strategy document as part of a formal project?
I've found that this type of document is often required during an IT project that is following strict adherence to a formal Project Management Life Cycle. It is required for the project to exit the "planning" phase of the life cycle.
Have you been faced with this before? What types of things would you list as "Guiding Principles"? Would you organize the document following ADDIE with guidance for executing each phase? Do you have any samples?
No samples handy right now, sorry. But I can tell you a few things I've included in the past on those sorts of projects that were expected...
Super-User Training - Many IT projects designate super users and educating, or at least partnering with them to be your expert base for the masses is often a key piece. Ask (or decide) how they will get up to speed, by when, and how they will help with either rollout or support to the broader audience and document it.
Audiences / User Roles - Depending on the project, often there are different audiences for the training effort. Do senior leaders need to know how to execute tasks in the software? Do functional roles need to know how to pull reporting? One of your key deliverables is a training strategy that identifies what the different roles (if any), and offers a very brief description of the types of things they will need to be trained on (high level bullets such as "reporting", not paragraphs of detail)
Roll-Out Training(s) - "The" training itself most people think of. As you know this can be done several ways including blended approaches. Detail your recommended approach and include at least a general schedule or window during which this will happen. If complex logistics, simply document window and projected number/locations and keep full details of schedule in separate documentation. Tip: Remember to use the words "roll out" or "initial" or the like to indicate that this is not the ONLY way people will learn.
Job Aids / OJT References - Again this can take the form of quick start guides, reference docs, context sensitive integrated help messages, etc. But don't leave the creation of any of these exclusively to the techie pros or super-users. You are the master of translating geek to speak and knowing what the average person really needs. Further, you have the vision gained during your analysis to know what functions are going to be the common tasks (learned in roll out and practiced daily) and what are the things that are rare/situational and thus are best served with reference docs users can tap when they occur.
Follow-on Training - Not always done, but in large or complex rollouts it sometimes makes sense to phase things in. If your project needs this, you will need to detail it.
Help Desk / Live Support - Not your gig per se, but depending on the project this can sometimes fall to the training lead to help coordinate, or at least document the plan. This is another place your super-users can come in..... especially during the initial rollout phase. In any case, as the training lead you will want to reference the on going support plan as part of the education available.
Success Measures - There is typically no gray area here. They want them and that's that, or they aren't asked for at all other than to report that X users are officially "trained". You may want to ask.... or not.... but in any case it's typically important to put some metric in place to close the training phase of the project.
Generally speaking, most IT projects I've worked are not all that concerned with the ID model you will employ. They may (rarely) ask about an analysis phase where you can document things like User Roles vs Tasks = Learning Needs. But that's about it. After that, they typically want to know deliverables and timelines. Which brings me to the last point...
Training Timeline - If it's a formal project the timeline is king.... or at least prime minister behind the budget. You will want to put all of this down in a timeline. They may or may not have a specific format/tool but they will certainly want a chronology with milestones including of course and end date of the "roll out period" and when "follow on training" or "on going support" tools kick in.
1 Reply
Hi Owen,
No samples handy right now, sorry. But I can tell you a few things I've included in the past on those sorts of projects that were expected...
Super-User Training - Many IT projects designate super users and educating, or at least partnering with them to be your expert base for the masses is often a key piece. Ask (or decide) how they will get up to speed, by when, and how they will help with either rollout or support to the broader audience and document it.
Audiences / User Roles - Depending on the project, often there are different audiences for the training effort. Do senior leaders need to know how to execute tasks in the software? Do functional roles need to know how to pull reporting? One of your key deliverables is a training strategy that identifies what the different roles (if any), and offers a very brief description of the types of things they will need to be trained on (high level bullets such as "reporting", not paragraphs of detail)
Roll-Out Training(s) - "The" training itself most people think of. As you know this can be done several ways including blended approaches. Detail your recommended approach and include at least a general schedule or window during which this will happen. If complex logistics, simply document window and projected number/locations and keep full details of schedule in separate documentation. Tip: Remember to use the words "roll out" or "initial" or the like to indicate that this is not the ONLY way people will learn.
Job Aids / OJT References - Again this can take the form of quick start guides, reference docs, context sensitive integrated help messages, etc. But don't leave the creation of any of these exclusively to the techie pros or super-users. You are the master of translating geek to speak and knowing what the average person really needs. Further, you have the vision gained during your analysis to know what functions are going to be the common tasks (learned in roll out and practiced daily) and what are the things that are rare/situational and thus are best served with reference docs users can tap when they occur.
Follow-on Training - Not always done, but in large or complex rollouts it sometimes makes sense to phase things in. If your project needs this, you will need to detail it.
Help Desk / Live Support - Not your gig per se, but depending on the project this can sometimes fall to the training lead to help coordinate, or at least document the plan. This is another place your super-users can come in..... especially during the initial rollout phase. In any case, as the training lead you will want to reference the on going support plan as part of the education available.
Success Measures - There is typically no gray area here. They want them and that's that, or they aren't asked for at all other than to report that X users are officially "trained". You may want to ask.... or not.... but in any case it's typically important to put some metric in place to close the training phase of the project.
Generally speaking, most IT projects I've worked are not all that concerned with the ID model you will employ. They may (rarely) ask about an analysis phase where you can document things like User Roles vs Tasks = Learning Needs. But that's about it. After that, they typically want to know deliverables and timelines. Which brings me to the last point...
Training Timeline - If it's a formal project the timeline is king.... or at least prime minister behind the budget. You will want to put all of this down in a timeline. They may or may not have a specific format/tool but they will certainly want a chronology with milestones including of course and end date of the "roll out period" and when "follow on training" or "on going support" tools kick in.
Hope this helps and good luck!
This discussion is closed. You can start a new discussion or contact Articulate Support.