Updating an e-course is always part of the project. I have been working on an on-line course about our new ERP-software. I took parts of the manual and converted them to course pages using Courselab and Moodle. I recorded short videos to demonstrate some of the less obvious workings of the software and built exercises around them to create an interactive course - the way I've done it in courses I collaborated on in the past.
And when I got a nice set of comprehensive topics covering most of the tasks my colleagues had ahead of them - it was an internal course- somebody decided to change the software lay-out. And not just colors, but the position of buttons as well as drop-down fields. So overnight, eighty percent of my work became obsolete.
Because it's one thing to alter a manual - basically a Word-file - and a different thing altogether to change an on-line course. They're just not the same thing. So the team decided to pull the on-line content and remake most of it to the new lay-out. As the live date was approaching fast, there were more urgent jobs that needed to be done.
It will be clear that updating wasn't part of the project scope and as I have now moved to other tasks, it remains to be seen if the on-line course will ever be revived. This is a lesson well learned when working with e-learning projects: planning ahead and making sure any updates are part of the scope of a project are an absolute must. It sounds obvious but unfortunately, it isn't to a lot of people involved in project work.
One last note about budgeting for these kinds of updates: where a typical on-line course will require updating every now and then, a software course is different. For a typical course, 15-25% of the available budget needs to be foreseen for updates. For a software course (which necessarily needs to be produced under a bigger time constraint) this may rise to 40 or 50 percent.
It's a valuable number to take into consideration when devising this sort of course. Development budget times two might keep your project out of trouble in the long run.
And when I got a nice set of comprehensive topics covering most of the tasks my colleagues had ahead of them - it was an internal course- somebody decided to change the software lay-out. And not just colors, but the position of buttons as well as drop-down fields. So overnight, eighty percent of my work became obsolete.
Because it's one thing to alter a manual - basically a Word-file - and a different thing altogether to change an on-line course. They're just not the same thing. So the team decided to pull the on-line content and remake most of it to the new lay-out. As the live date was approaching fast, there were more urgent jobs that needed to be done.
It will be clear that updating wasn't part of the project scope and as I have now moved to other tasks, it remains to be seen if the on-line course will ever be revived. This is a lesson well learned when working with e-learning projects: planning ahead and making sure any updates are part of the scope of a project are an absolute must. It sounds obvious but unfortunately, it isn't to a lot of people involved in project work.
One last note about budgeting for these kinds of updates: where a typical on-line course will require updating every now and then, a software course is different. For a typical course, 15-25% of the available budget needs to be foreseen for updates. For a software course (which necessarily needs to be produced under a bigger time constraint) this may rise to 40 or 50 percent.
It's a valuable number to take into consideration when devising this sort of course. Development budget times two might keep your project out of trouble in the long run.
