Best practices for deploying the UPK
I like to keep things simple, so here are three things that will make your UPK deployment easy.
- Remember, it’s all about the Plan!
- Create a common, shared set of training development guidelines and standards.
- Test the material and prepare logistics.
It’s all about the Plan
One of the most common questions in managing the instructional design component for enterprise application development projects is, “When should I start developing the training content?” To answer this question correctly, it is important to understand that training development is part of the change strategy in IT projects.
Change management and training development
Change management is often perceived as that 10% tax at the end of IT projects. This is sad, because change management should instead be one of the triggers of an IT project. Figure 1 shows how change management should be positioned in projects, almost as a consulting group.
Figure 1 Change management is a consulting function in project management.
As part of the change strategy, training development should therefore begin when the project begins. In deploying UPK, the training curriculum should be designed when blueprinting the project deliverables. It is at this point that you will identify the elements that UPK calls Modules and create a library. The library will be your Modules repository. Then, when alpha and beta development commence, training developers should start drilling down the curriculum, creating Sections and Topics within the Modules, or simpler sub-Modules.
During the beta phase of implementation, the training developers should start playing around with the various functions of the enterprise application, in order to get familiar with it. We have even seen projects where training developers were reporting almost 50% of the bugs!
Subject Matter Expert strategies
A very important task in this phase will be to decide the Subject Matter Expert (SME) role that best fits the project. There are two cases:
- The SME can show the training developer how the software works, including all the transactions. The developer records (captures) the transactions and creates the explanatory frames, the bubble texts, and other details needed to support user learning and performance. The SME reviews and approves the content after development, so that both the developer and the SME review the content, or
- The SME can develop all the content.
I don’t recommend the latter approach, for various reasons. One reason is that in most cases the SME will be overwhelmed with project activities and will push training development until the last minute. Another reason is that the SME doesn’t necessarily have the skills or the knowledge of pedagogy required to develop training material (whether e-Learning or not).
Actual training development
Development of the actual content – Modules, Sections, and Topics – should begin when stable versions of the software move into testing environments. By waiting to do this until actual working software is in testing, if changes occur to the application, they are usually minor and there will be fewer content items to change. One can easily make the changes, either by using UPK to capture the modifications, or by using Paintbrush and editing the screen shots manually. The latter method is faster.
Resources: How many developers will I need?
This is the question on every project manager’s mind. One hour of final training content requires about 40 hours of development work. A fairly large ERP implementation will require about 400 instructional topics, which means over eight weeks of actual training development. (Remember, “Topics” in UPK are the actual content containers: screen captures and text.) For this amount of work, the recommended UPK development team will be composed of a lead and around five developers. These figures will scale, depending on the size of your project. The time-estimate figures include review, editing, QA, sign-off, and publishing stages.
Managing the development lab: Versioning issues
In order to avoid conflicts, two versioning strategies are possible.
The first strategy, which is by far the best, is to assign topics to people. This way, one person is accountable for one topic. The accountable individual can interact with the appropriate SME, and there are no possible versioning issues.
In some cases this is not possible, and that is when the second strategy should come into play. Use the Oracle document check-in and check-out feature. This feature is offered on the Enterprise version of UPK. If you are using a stand-alone version of UPK, my recommendation is to set clear file naming conventions, using dates, initials, and transaction names, combined with a strict follow-up (an Excel spreadsheet will do the job) to know who has what, who owes what, and by when.
Create a common, shared set of training development guidelines and standards
At the heart of UPK is the trainee, and when you don’t want to lose a trainee, you have to be coherent. UPK development standards should be one of the blueprint deliverables if you don’t want your content to be completely heterogeneous.
I use this checklist when a UPK project starts.
- IT requirements
- (a) Hardware is very important for UPK. The Development Tool consumes a lot of memory. In addition, we have noticed that some SAP Web-enabled applications also consume a lot of memory. Therefore both developer and user computer specs have to be clearly defined and tested up front.
- (b) Screen resolution is also very important. In most cases I recommend using 800x600 so that the finished product will fit every screen. Even though today most displays are running in 1024x768 and up, having the full screen application in 800x600 will put a blue border around the simulator. I really like this because you know you are not missing any part of the screen. This is not always possible; I saw a traffic control simulation that was working on 1680x1050 screens, using every possible bit of the screen. When trainees would play it back, they had to scroll every frame horizontally. This was not convenient, but it was the only option because trainee desktops were 1024x768. Once you set up the proper screen resolution, don’t forget to switch before you start capturing!
- Graphic design standards
It is a fact that people use their eyes to learn. If you want your training content to be coherent, set clear standards regarding graphic design, and don’t be afraid to set them down to the very lowest level. I personally like to use a table to organize the specifications. (See Table 1 for format.)
- Wording principles
- Advanced UPK features usage
- Player Package – This format will publish the various playback modes associated with UPK (See It!, Try It!, Know It!, and Do It!).
- HTML Web Site – This format will publish a series of static Web-based HTML files.
- LMS Package – This format will publish SCORM-compliant content grouped as a package to be distributed by a Learning Management System.
- System Process – This format will publish a business process Word or PDF document.
- Job Aid – This format will publish a step-by-step aid in Word, or as a PDF document.
- Training Guide – This format will publish Module, Section, and/or Topic overviews created as Web pages in UPK, a step-by-step guide with screen shots, and a Table of Contents.
- Instructor Manual – This format will publish Module, Section, and/or Topic overviews created as Web pages in UPK, any included instructor notes, a step-by-step guide with screen shots, and a Table of Contents. Each topic is a separate Word or PDF document.
- Test Document – This format will publish a procedural guide for use in testing an application.
- HP Quality Center – This format will publish a document suitable for exporting into HP Quality Center.
|
|
Static Graphics |
Video |
Sound |
Title Font |
Title Text |
Etc. … |
|
Modules |
|
|
|
|
|
|
|
Sections |
|
|
|
|
|
|
|
Topics |
|
|
|
|
|
|
What you will say is also very important. Titles should clearly communicate the content of the Modules, Sections, and Topics. Since UPK allows long titles (63 characters), the Titles should describe the element as completely as possible. I also like to start the Topic Titles with the names of the transactions, for example, “MM01” (in SAP).
The Concept gives the user the information that is needed to complete the procedure. The developer enters this text in the “Concept” area of the UPK property sheet mentioned earlier. Document any prerequisite topics in the Concept, too. This description should also contain a link to the Job Aid document generated by the application. The text that the developer enters in the Introduction area of the property sheet will appear in the Introduction frame.
You should always standardize the wording of the Concept area and the Introduction area. Always start the paragraphs the same way. For example: “In this module you will learn how to … this will be achieved through doing … and … The key learning points are …“
UPK offers a lot of advanced options. Choose the ones you need, and set standards for them. Always use the glossary when introducing a technical term. Limit the use of alternate paths and decision frames; this feature is really cool but impossible to maintain – make just one change to the application and you have to re-capture two paths. Finally, set the outputs you want to generate; they should completely align with the change strategy (e.g.: do you want to test users, do you want to give them one-page job aids or full user guides, and so on).
UPK offers these outputs:
Test the material and prepare logistics
We can never say it too much – practice makes perfect. Other users should test the training material (or, as we say, QA it). These should be users that have little knowledge about the project, not just the Subject Matter Experts. In addition to providing you with good feedback about your content, it will also create a buzz around the project.
At this point, you will tweak your content. You will also specify the grade required to pass the test in Know It! mode. The grade required can vary from application to application. However, remember this one bit of advice about testing: the more text the user has to type, the more chances you will have that every trainee’s text will be different, and the lower the passing grade should be. On the other hand, if the transaction is only based on mouse clicks, the passing grade should be 100%. And, of course, you have to combine that with the chosen user-adoption requirements included in the change strategy.
A second important point that people tend to underestimate is the logistics. When preparing your change strategy, think of the training rooms, the format (instructor-led or self-paced), printing, burning CDs, and possibly shipping if the company has several locations.
Summary
UPK is a wonderful tool. When implemented well, it provides powerful training and knowledge-sharing tools. On the other hand, without good planning and simple governance, UPK can quickly create disruption, confusion, and duplication. In my work experience, I have seen both sides of UPK. I wish I had more space and time to explain about maintaining and updating the training material, as well as training development and testing strategy integration, and many other UPK issues you might be facing. I hope to address these in a future article!
