Rapid eLearning means different things to different people – it’s critical we define this term when working together.
A few years ago, a major bank we worked with discussed us looking after their ‘rapid development’ requirements for eLearning. They had a well-resourced internal eLearning team who mostly developed their Rapid eLearning, but they had so much internal business that they approached us to handle their overflow. As a vendor, we were set up like most companies in this industry – we had a group of instructional designers, multimedia developers, two graphic designers and project managers.
So we started our first rapid project for them based on our idea of rapid development in online training; developing something quickly, with rock solid content and little interactivity i.e. instead of the usual two month development cycle, we should be turning a half hour to an hour’s training piece around in 3-4 weeks max. Rapid also meant we use an Authoring tool, like the main stayers – Lectora, Captivate or Articulate (in this case the client’s team used Lectora, so that’s what we used).
Once we got to storyboard reviews, our client was very disappointed with the level of interactivity we had included, and they had hoped to review the ‘storyboard’ in a Lectora shell, already laid out etc. We had provided them storyboards in a Word doc format which just described the interactivity we would build. This misalignment of expectation was based on their own internal processes for development, which is not dissimilar to a lot of companies’ internal teams where staff are designers AND developers ‘all-in-one’ – they often storyboard in PowerPoint ready for an Articulate output, or simply map the training out in Lectora itself.
In general, vendors that sell their online development capabilities for custom courseware are not set up for this. They have specific skill sets; instructional designers are writers and educators – NOT developers, and multimedia developers are coders and web developers – NOT educators. In this instance, we wanted to write the course in a storyboard for sign-off before development i.e. our writers write, our developers then develop. Commercially it makes sense as these sign-off points are critical to managing scope. But our client preferred a more iterative process to go straight to development (more of an Agile model rather than straight ADDIE). They can afford to do this internally and they have direct access to stakeholders to work that way.
Secondly, and which I found most odd at the time, our client’s definition of Rapid eLearning was not so much based on turnaround times in our project plan, but it described for them any online training under half an hour… High, low or in the middle – if it’s under half an hour, it’s rapid eLearning! They used the word rapid to just describe the learning experience.
Of course there were expectation issues we should have better covered at kick-off, whilst aligning our own development process more to theirs. We went on to design and develop many ‘Rapid’ pieces for this client, which was a testament to getting things right once we uncovered this major difference in understanding.
This post is already too long (the Learning Hook will be posting more on this over coming weeks – we’ll try to keep it shorter too!) but I love this story as it raises so many points on the difference between vendors and internal teams within business. With experience working in both areas, I see how important it is for clients to gauge the skill sets of those they’re working with and then exploit those skills in the solution required i.e. don’t force a vendor to work to your own methodologies. Get an honest answer from them as to their skills sets and work flow – the best person to talk with is the head of production (Danger: a BDM has all the expertise in the world ready to go for you tomorrow). Project plans are very flexible things, and we can still meet the right outcome, whilst capitalising on true internal expertise.
For more eLearning, visit www.learninghook.com.au