You customized an ERP module with 15 new fields, 4 new screens, 5 significantly changed screens, a significantly different workflow, and an updated graphics ‘theme’. It takes you about 30 min just to walk a co-worker through all of the new features and methods. Now, you’re tasked to deliver end-user documentation and training materials ASAP. Your options are:
Open Snagit, grab lots of screen shots and start writing a Word manual – you should have it ready in a week or so.
Give it to the tech writers – they’ll pester you with questions, but they might have it done in a couple of weeks
Write a quickie memo and email it to end-users and let them figure it out for themselves – eventually.
Spend 1 or 2 hours on the problem and deploy it in multiple, professional formats a week from now.
There’s an old management maxim: You must manage around your scarcest resource. For many (probably most) technology-intensive companies, the on-task time of their critical experts is a perennial “scarcest resource”. Despite that, companies routinely assign high-value talents to routine, mundane work – because they are the only people that can do the task. Nowhere is this waste more evident than in the production of “knowledge assets” like presentations, courseware, technical manuals, and operator guides. High-priced engineers work long hours with high-priced technical writers in one of the most inefficient processes in all of business. Worse, everyone hates doing it. If there is an engineer that loves writing manuals, no one at iPOV has ever met him or her. Yet they must do it because end-users need what they know. Under the best scenario, the task described above might go as well as is shown in this calendar:
If the participants are typical, however, the task will take much longer. The developer will be pulled onto other problems and won’t be able to write in a continuous effort. It may be a couple of weeks before the developer can finish the first draft. Then it will take time to schedule the reviews. Then more time to schedule an independent tester to verify that the procedures will work as written. Then the material has to be formatted and integrated into a document that meets the standards and is suitable for deployment. A task that might optimally be done in a week or two can easily stretch out for months. Finally, you could dump it all on a tech writer or outsource service. Let someone else figure things out from the finished application. Someone will still need to manage, review and validate their work. Hopefully they won’t pester the developer with too many questions.
What if there were a solution to this problem that was inherently fast, efficient and accurate? What if that solution made almost no demands on the developer’s time? What if the outputs were easily packaged in a wide range of deliverable forms: eLearning, manuals, class presentation materials, reference guides? What if the solution was less expensive than any method currently in use – even competitive with outsourcing to low-wage countries? What if the process was simple and incredibly easy to follow? What if that process was intelligent, culturally savvy and adaptable and would make the developer look really smart and competent? What if the developer could do everything he or she needed to do in a few hours after lunch, on a plane, in their hotel room on the road, or at home?
In other words, what if Option (4) really exists?
The Lean Knowledge Asset Life Cycle
iPOV has found a way to achieve the impossible. It just takes a total rethinking of the methodology – and a critical insight: The easiest way to write a software manual is to ask the developer to demonstrate the software and record the demonstration on video. With a thorough video demonstration, the developer can be excused from most of the subsequent documentation production process. The demonstration needn’t be smooth or professional. It can have gaffes and minor mistakes (if they are immediately corrected). The sound can be poor. A co-worker can knock on the door and interrupt the session. All of that is OK. There are only two things that are absolutely essential:
A clear recording of the entire computer desktop and the developer’s commentary
A thorough explanation of the topic details.
The first requirement is easy to meet with the latest generation of screencasting software (also see this blog article summary). Programs like camtasia and BBFlashback make this process simple and nearly foolproof. Install a standard Windows program and let it run in the background. The second requirement is met if the developer plugs a microphone into the PC and gives a running commentary to the video recording. The audio quality or the speech clarity is largely irrelevant. It’s purpose is just to record the developer’s thoughts. Flubs and gaffes and misstatements are not important. When these two requirements are met, the scenario in the problem statement can be satisfied with the following process:
In this process, the software developer’s only job is to share their knowledge on the video/audio recording. With no need to worry about minor mistakes, most people can learn to produce useful video in one or two takes. iPOV will take the recording and apply several transformations, most likely the construction, restatement, and possibly the extraction transformations. With these, iPOV can generate polished, professional eLearning and documentation materials that closely reflect the developer’s original intent. After the initial planning and recording sessions, the developer will only need to be involved in a review process about halfway through the process. At this point, the developer can edit the draft script to reflect what they would really like to have said.
Developer involvement is mostly independent of the content. The only exception is for recordings that rely on PowerPoint presentations or other forms of graphical documentation (e.g, UML diagrams). Preparation takes time – but that is true regardless of the recording method. At each stage, iPOV’s process generates interim deliverables that have an intrinsic value. In a crisis, the original developer recordings can be sent immediately. Whatever their faults, they are better than nothing. The review draft will have a script that has undergone significant grammar review and improvement. The final output is generally a SCORM-compliant learning object that is suitable for referencing in an online document or inclusion in courseware in an LMS. Other materials can be derived from this, including foreign language and print versions.
Bottom Line
In over 350 projects, iPOV has proven that this new method really works. iPOV has taken 5 hours of developer recordings and turned them into 5 hours of finished, validated eLearning materials in less than 3 weeks – start to finish. The developer’s time commitment was about 3 days! The rest of the time, the developers were busy getting the software system ready for deployment.
Why waste the time of the organization’s scarcest resource. Why put corporate initiatives in jeopardy by sidetracking your experts on mundane documentation? Why put projects in jeopardy by failing to distribute the documentation that end-users need? It simply is unnecessary.
Engineers Love Writing Manuals! – Really!
Problem Statement
You customized an ERP module with 15 new fields, 4 new screens, 5 significantly changed screens, a significantly different workflow, and an updated graphics ‘theme’. It takes you about 30 min just to walk a co-worker through all of the new features and methods. Now, you’re tasked to deliver end-user documentation and training materials ASAP. Your options are:
The Typical Knowledge Asset Life Cycle
There’s an old management maxim: You must manage around your scarcest resource. For many (probably most) technology-intensive companies, the on-task time of their critical experts is a perennial “scarcest resource”. Despite that, companies routinely assign high-value talents to routine, mundane work – because they are the only people that can do the task. Nowhere is this waste more evident than in the production of “knowledge assets” like presentations, courseware, technical manuals, and operator guides. High-priced engineers work long hours with high-priced technical writers in one of the most inefficient processes in all of business. Worse, everyone hates doing it. If there is an engineer that loves writing manuals, no one at iPOV has ever met him or her. Yet they must do it because end-users need what they know. Under the best scenario, the task described above might go as well as is shown in this calendar:
If the participants are typical, however, the task will take much longer. The developer will be pulled onto other problems and won’t be able to write in a continuous effort. It may be a couple of weeks before the developer can finish the first draft. Then it will take time to schedule the reviews. Then more time to schedule an independent tester to verify that the procedures will work as written. Then the material has to be formatted and integrated into a document that meets the standards and is suitable for deployment. A task that might optimally be done in a week or two can easily stretch out for months. Finally, you could dump it all on a tech writer or outsource service. Let someone else figure things out from the finished application. Someone will still need to manage, review and validate their work. Hopefully they won’t pester the developer with too many questions.
What if there were a solution to this problem that was inherently fast, efficient and accurate? What if that solution made almost no demands on the developer’s time? What if the outputs were easily packaged in a wide range of deliverable forms: eLearning, manuals, class presentation materials, reference guides? What if the solution was less expensive than any method currently in use – even competitive with outsourcing to low-wage countries? What if the process was simple and incredibly easy to follow? What if that process was intelligent, culturally savvy and adaptable and would make the developer look really smart and competent? What if the developer could do everything he or she needed to do in a few hours after lunch, on a plane, in their hotel room on the road, or at home?
The Lean Knowledge Asset Life Cycle
iPOV has found a way to achieve the impossible. It just takes a total rethinking of the methodology – and a critical insight: The easiest way to write a software manual is to ask the developer to demonstrate the software and record the demonstration on video. With a thorough video demonstration, the developer can be excused from most of the subsequent documentation production process. The demonstration needn’t be smooth or professional. It can have gaffes and minor mistakes (if they are immediately corrected). The sound can be poor. A co-worker can knock on the door and interrupt the session. All of that is OK. There are only two things that are absolutely essential:
The first requirement is easy to meet with the latest generation of screencasting software (also see this blog article summary). Programs like camtasia and BBFlashback make this process simple and nearly foolproof. Install a standard Windows program and let it run in the background. The second requirement is met if the developer plugs a microphone into the PC and gives a running commentary to the video recording. The audio quality or the speech clarity is largely irrelevant. It’s purpose is just to record the developer’s thoughts. Flubs and gaffes and misstatements are not important. When these two requirements are met, the scenario in the problem statement can be satisfied with the following process:
In this process, the software developer’s only job is to share their knowledge on the video/audio recording. With no need to worry about minor mistakes, most people can learn to produce useful video in one or two takes. iPOV will take the recording and apply several transformations, most likely the construction, restatement, and possibly the extraction transformations. With these, iPOV can generate polished, professional eLearning and documentation materials that closely reflect the developer’s original intent. After the initial planning and recording sessions, the developer will only need to be involved in a review process about halfway through the process. At this point, the developer can edit the draft script to reflect what they would really like to have said.
Developer involvement is mostly independent of the content. The only exception is for recordings that rely on PowerPoint presentations or other forms of graphical documentation (e.g, UML diagrams). Preparation takes time – but that is true regardless of the recording method. At each stage, iPOV’s process generates interim deliverables that have an intrinsic value. In a crisis, the original developer recordings can be sent immediately. Whatever their faults, they are better than nothing. The review draft will have a script that has undergone significant grammar review and improvement. The final output is generally a SCORM-compliant learning object that is suitable for referencing in an online document or inclusion in courseware in an LMS. Other materials can be derived from this, including foreign language and print versions.
Bottom Line
In over 350 projects, iPOV has proven that this new method really works. iPOV has taken 5 hours of developer recordings and turned them into 5 hours of finished, validated eLearning materials in less than 3 weeks – start to finish. The developer’s time commitment was about 3 days! The rest of the time, the developers were busy getting the software system ready for deployment.
Why waste the time of the organization’s scarcest resource. Why put corporate initiatives in jeopardy by sidetracking your experts on mundane documentation? Why put projects in jeopardy by failing to distribute the documentation that end-users need? It simply is unnecessary.
Post a comment or leave a trackback: Trackback URL.