As eLearning professionals, we have found that modifying someone else’s work is one of the hardest things clients ask us to do. If you’ve had to modify other people’s work a few times, you know what we mean.
This is the first in a series of four articles in which we offer some tips about picking up other people’s eLearning projects.
We’re going to offer these articles in a first-to-last sequence:
- Ten questions to ask before you start
- Opening the files: what to review
- Finishing an eLearning project: what to document
- eLearning standards: making it easier to change each other’s work
It’s always best to start with some basic questions!
Do you smell smoke?
Often when managers or clients ask us to modify an eLearning course, they have an urgent issue and are anxious to put out a fire. These requests are full of landmines that could put a dent in our otherwise shining reputations. It’s so much easier (and more rewarding) to build stuff than to fix it. But sometimes someone has to make fixes, so we’re writing this series for all the good eLearning professionals out there who want to solve the problem and keep their good names at the same time.
When an assignment involves modifying someone else’s eLearning project, the most important thing you can do is ask the right questions before you start. This is a list that we compiled by putting our heads together and discussing the situations we’ve both gotten ourselves into over the years.
- Course overview— Tell me a little about the course. Who is the target audience? What is the purpose of the course? What modifications do you want me to make and why?
It’s always helpful to know what you’re working with and who uses it. - Original developer— Who developed this course? Why not ask the original developer to do the modifications? Is it possible for me to contact the original developer?
In nearly every situation where we’ve been asked to revise someone else’s course, the original developer cannot do it. If the developer were available, typically the client would return to the original developer. Perhaps the developer is now too busy, but you should nudge the requestor in this direction. Avoid the fire, if possible. If the client is very critical of the original developer, it’s possible the developer did a bad job, in which case you may be looking at an even bigger headache to fix the course than to re-author it from scratch. On the other hand, the original developer may be good and there is an ulterior reason that things didn’t work out: Watch out for this situation, because it could indicate underlying issues, such as poor work quality, poor communication, or unrealistic client expectations.
- Source and published code — Do you have the source (editable) files and the published (LMS/SCO) files for this course? Can I look at them?
- Storyboards or other documentation— Is there any documentation on how the course is assembled and published? Are there storyboards for the course? Did someone update them as changes were made to the course after initial production? Can I look at the documentation you have?
The course documentation can tell you a lot about how the instructional designer envisioned the course, but be aware that designers often do not update the documentation when they update the course files. So if the course and the documentation are different, ask about it or go with the course files as being the most up-to-date. If the latter, you may want to ensure that you build in time (and cost) to update the documentation, especially if the client will base the evaluation of your work on how it compares to the storyboards or other documentation.
- Development tools and versions — What tool(s) and version(s) did the developer(s) use for this course?
When you look at a course, you can often determine which development tool the producer used by looking at the interface and file structure. But determining which version of the tool a developer used is more difficult. If the requestor can’t answer the version question, ask when it was developed or look at the dates on the files themselves. The date may give you a clue as to the version of the development tool. If at all possible, use the same version of the tool as the original developer. Upgrading the course to a new version of the tool can cause its own set of issues, so try to avoid these added issues. - Course delivery — What LMS or website are you using to deliver the course? Do you know if the course is published in SCORM or AICC? If they use SCORM, ask which version (1.2 or 2004)?
You will need to know this when you republish the revised course.
- Evaluation — How is course completion measured? What reports do you typically look at from the LMS? Are you getting the data you need about course usage and completion?
We have had situations where a course we were asked to revise was never communicating properly with the LMS. After making a simple revision, we loaded and tested the course in the LMS and found out that the reporting didn’t work. At that point, this major problem that existed in the original course became our problem. To avoid being blamed for breaking something that was already broken, make sure that the original course is working properly in the LMS before you start.
- Voiceover — If the course has voiceover and they want to change the script, ask if they know who the voice is. If not, will they accept two voices or will they want to re-record everything?
- Number of lessons/SCOs — How many SCOs/lessons are there? Can users take them in any order, or is there a forced sequence?
This could seem obvious by the file structure, but we actually had a situation where a client gave us 13 sets of files for a 15-lesson course, then they wondered why we didn’t revise two of the lessons. It doesn’t hurt to ask, but this item can cause a “backdraft” if you don’t have the right information. - Any issues? — Is everything functioning properly for the users who take this course, other than what you are asking us to fix?
We’ve had situations where we revised multiple lessons, published the SCOs, loaded them in the LMS, and tested them and ensured they were working properly, after which the client gave us more changes to make. It would have been much easier (and less costly) if we had made all the changes when we had the files open and were making the first set of changes.
If you can’t get the source files, then this isn’t a revision job, it’s a do-over. If you can get the source files, you need to plan what you will review. Joe’s article “Opening the Files: What to Review,” which is next in the series, will give you tips about this.
Sometimes clients don’t understand the concept of source code and will deliver the published files to you, assuming you can work with them. You need to be very specific about the file extensions of the files you need.
What’s next?
We hope that this article gives you a solid checklist of questions to ask when you’re tasked with revising someone else’s work. Asking and discussing these questions will help you formulate a logical plan of action with the person who requested the changes. This honest and open communication can help you set realistic expectations.
In the Comments below, please share your situations and any additional questions that you have learned to ask.