Authoring tools and development software that specialize in eLearning and instructional design have been around for a very long time. During this time, thousands of people, hundreds of thousands of man hours, and countless millions of dollars has been spent on refining the best methods available to accomplish certain tasks. Literally decades of innovation, investment, and refinement have taken place. Why reinvent the wheel?
One of the most common issues I come across when I work with a new team of instructional systems designers, developers, and project managers, is finding that multiple people are trying to invent and test new processes that don’t work.
Ignoring Established Time-Tested Processes
“Reinventing the wheel” is a term I use often. Let’s say you have an entry level developer, basically trying to reinvent the wheel. Maybe they are trying to figure out the best way to convert a lot of .PNG files to .JPG, .WEBP, or even a vector format. Regardless of what it is, they are trying to reinvent the wheel.
Why would I allow them to invent the wheel from scratch if I’ve been building world class wheels for 15 years? The best thing for them to do is to do it right the first time. Whether they need to ask someone the best way to do it, or someone already told them what to do, it needs to be managed and mitigated to avoid spending 80 development hours on a simple batch action or other process, depending on what they are trying to do.
Change is Challenging
Believe it or not, this behavior can be a very difficult thing to change. People get stuck in their ways of doing things and change can be hard for them. I’m not talking about one single item like the batch conversion example above. I’m talking about it happening again with something else.
So even if you are able to save 80 hours of development time in one single instance, the next time that person comes across a problem or new task, they are likely to be doing it wrong again. This can start happening in everything.
I once saw a team that was doing this in almost everything they do. Apparently this is very common. The issue extended into Storyboarding, Audio Recording, Graphics, File Structure, Creating Backups, and everything else you can imagine.
A Common Story of Missed Deadlines
Would you believe…
They were recording audio AFTER they completed all of the development? They were also Storyboarding the entire course after it was developed. It was bad. Their graphic designers were coding and their programmers were Storyboarding. When I first came on board, I met someone that was using Photoshop to edit a graphic… He was a technical writer that had never worked with graphics before. So he was trying to learn as he went. I asked one of the graphic designers why she didn’t do the graphics for him. She was busy editing an audio transcript.
What?!
These are just a few examples of a few instances where things were going in the wrong direction. I was brought onto that team because they had missed their deadline. The team pushed their deadline back two weeks because they thought it would be long enough to finish. In the end, it took several months to finish. All of this could have been prevented.
They hadn’t even begun Quality Control or Debugging their project. This project was massive. An 8 week web-based eLearning course that was entirely online. The project manager had one of the graphic designers do an analysis and decide how long to push the deadline back. Just one graphic designer had made that decision for a team of 8 people.
Embrace Efficiency – Embrace the Wheel
The moral of this story is, Do Not Reinvent the Wheel. The best way to do this is to work as a team and let people do their jobs.
Allow the programmers to decide how the code should be written. Let the Graphic Designers do the graphics. The technical writers should do the writing and document editing.
For any project managers or multimedia developers out there that think you should record the audio after you animate and develop your eLearning or Animations. That is wrong. You should also do quality control on your audio script and Storyboard before you develop to avoid propagating error.
I will have another blog post regarding Propagation of Error soon. It will give you insight as to why I once made the decision to scrap an entire project “halfway finished” and start over when I was brought on.
Recent Comments