Courting Disaster in an Online Learning Project

I was involved with a technical online learning program. The idea was to take technical content and create short modules so that sales representatives would be more versed in all the company’s products. That way sales reps would be more attuned to possible solutions to customer problems that were outside their scope of expertise. The process was as follows:

1. The instructional designer interviewed the SMEs with a set of predefined questions. The phone interviews were recorded for easy transcription to ensure all answers were captured completely.
2. The instructional designer synthesized the answers to the questions and created a high level design.
3. The SME reviewed the high level design and adjusted the content as needed.
4. The instructional designer created a storyboard based on the high level design.
5. The SME reviewed the storyboard and once again changes were made as needed.
6. The approved the storyboard.
7. The storyboard was sent to the programmers who built a course using Articulate Storyboard.
8. The course was sent to the instructional designer for review, changes, and approval.
9. Once the instructional designer approved the course, it was sent to the SME for approval.
10. Once the SME approved the course, it was considered complete.

This process worked well until the co-project manager stepped in and decided to use offshore programmers. This project manager was not familiar with online learning and he initiated new rules which prohibited creativity and made programming easier for his offshore group. I would send my storyboard to the programmers and I would get a module that looked nothing like my storyboard. The programmers obviously had no instructional design experience. They completely changed my screens. They had redundant wording and audio; the narrator was essentially reading the screen. These modules were supposed to be considered nearly completed except for a few adjustments.

I had to send feedback to the programmers that they must follow the storyboard. They would make minor changes and essentially send me the same module. I was so frustrated. I went to the other project manager and asked why I was even bothering to create a storyboard since the programmers didn’t follow it. The programmers were told to follow the storyboard. They had used up their allotted hours and wanted to charge for adjusting the modules. They were told they would not be paid for the incorrect modules. The situation was a mess. The modules were due and there was no time to find new programmers.

I spent twice as much time as I should have in reviewing the modules. I was one of six instructional designers. They, too, spent extra time reviewing their modules. The others faced the same programmer issues that I did. The scope didn’t just creep, the amount of work almost doubled because the programmers would not follow the storyboards and work had to be redone. The project was way over budget, the instructional designers were frustrated and the customer was not happy with the delay.

What could have been done differently? We had a good process and good programmers; why change? I would not have given the co-project manager so much leverage. Even though the current programmers were stretched, the work was getting done and quality modules were produced. I would not have added new programmers in the middle of a project. I would not have initiated new rules in the middle of a project. It would have been better to give the new programmers a trail period; if they didn’t work out, find other programmers. When so many variables are changed in the middle of a running project, nothing but problems ensue. There was no reason to change other than the co-project manager wanted to use his programmers. Perhaps there were politics going on of which I was unaware; regardless, it was a disaster.