In the world of eLearning development, one of the single most elusive concepts to understand and work around, is the question of how long will the development of any given piece of content take. Developers struggle to quantify it and Clients, Stakeholders and SME’s struggle to understand and support it. In this post we will pull apart the development life cycle and see if we can start to piece together a framework for how to better define your development time and also communicate that timeframe to your Clients/Colleagues/Stakeholders to make the journey a little smoother.
Many eLearning developers would be familiar with the concept of development or interactive levels, as a way of describing the overall complexity of course. These levels are usually described in an ascending scale of 1 to 3 or 4, with 1 being the most basic level of content based on interaction and 3 or 4 being the highest level.
It normally looks a little like this (I am using a three level system to simplify the image):
When using this model the idea is to ascertain the “level” of the content being built, then to multiply the time taken to develop and average screen at this level with the number of screens that are to be built.
This is all well and good but it does make a number of assumptions that can very easily and often do alter the parts of the development estimate equation.
Assumptions
The content levels are mutually exclusive. The biggest and most obvious issue with the content levels concept is that, even though in broad terms these provide a generic description of most content that gets built, the simple fact is that the line between levels is almost always blurred. You can build a course that contains 75% linear text based screens but for the remaining 25% you need to incorporate a large and complex simulation that requires branching logic normally siloed in level 3.The number of screens (or seat time) of the final piece is known from the start. This is the largest random element in determining your overall development timeframe. Purely because the content seems to always change with time. In all my years in the eLearning industry, I could count on both hands, possibly just one hand, the number of projects where the source information provided at the start of the project, the graphic look and feel and the requested interactive concepts have been exactly the same at the point of publishing the content. These changes are most often caused by external factors that are completely out of your control.You will be developing the content in a vacuum. When providing an estimate for development one of the first things forgotten is that we live in a dynamic and changing world/office. What is true today in terms of availability and capacity may well be completely out the window tomorrow, or even this afternoon.In reading the above assumptions, there are a couple more than this but I am focusing on the ones I see as the biggest, you might notice one similarity. Each one of the above is directly affected by external factors that you will have little or no control over. As such it might seem that we will be defeated even before we get started but this is not the case, since once you understand these issues you can communicate them to your stakeholders and effective communication is the foundation for any successful development project scoping.
Communication
“Every content development project is unique and even though you may have been involved in such projects in the past and even though I may have been the developer for some or all of those projects, let’s take some time to review and discuss what it takes to build a piece of eLearning in general, then we will talk about this piece of content” – This, more or less, is my opening line at every content scoping meeting.
The details following this statement will vary depending on who I am addressing. If it is a group of people I have worked with before then I still cover all of the steps to development at a high level and where possible reference pieces we have built together to illustrate key points or concepts. However if there is anyone present who I do not know or who I have not worked with before I will go into each concept in detail. It’s through this process that you are able to introduce the above assumptions, not to get answers on the spot, but more to have the stakeholders recognise and accept that scoping of a piece of content is not an exact science and the best way to do this is by showing examples. If you can get permission off your clients to show their content or develop your own examples for each of the assumptions above then show these to your stakeholders along with an explanation of factors that affected that particular piece of contents’ development, you will give your stakeholders a tangible point of reference for the rest of the scoping exercise.
A couple more tips for effective communication before we move on. Firstly, you DO NOT have to be a great public speaker to be able to communicate effectively. The key word here is “effectively”. To achieve this effective communication you must:
Know your message – simple but often over looked, if you know what you are talking about then you can make other people understand tooProvide relevant examples of key points – the tell me/Show me principleWatch and listen to your audience – you can tell almost immediately if someone does not understand from their body language or expression. And you can confirm this by asking that person questions related to the concept.Elicit feedback – by directly questioning the understanding of people in the group (In a polite passive way of course) you will ensure that A) they are paying attention and B) they are grasping the concepts and consequences of the points you are outlining.Breaking Down the Levels
Next we will tackle the central concept to the majority of content scoping, the levels of content and how they should be discussed and applied to the scoping of a new content build.
Using the concept of levels of content complexity, whether it’s three, four or seven levels, is an excellent way to describe the broad scope of what’s possible when building a piece of eLearning. However as mentioned earlier, it is often the case that lines between these levels become easily blurred as the types and numbers of interactions, graphic and media elements and navigation functions can vary across the course under development.
In this sense quoting the entire piece across only one level will give an unrealistic outcome. Similarly estimating the percentage of development at each level can also lead to unreliable timeframes as the mixture of interactivity is not always clear cut. For instance the on screen content may still be text and image based but the navigation could utilise intricate branching logic and navigation, so the screens may look like level 1 but behave like level 3.
The best method I have found for dealing with these inconsistencies is to use the levels only as an aid to understanding for the stakeholders but when It comes down to actually aligning the content with an estimate for development I use the scoping meeting to break down the whole piece into its component inclusions. In doing this you achieve a much more accurate view of what the build will look like and if you run through the inclusions with your stakeholders like a checklist, you are then able to advise them at each inclusion, which items will require more or less development time.
Continue to page 2. . .
About Ben Saunders:For the past 10 years Ben has been immersed in the world of learning and communication (and training and development), from planning and design to build and implementation, from both the client and vendor perspectives. His experience bridges the gaps between business expectation, technology and learning theory, importantly this allows Ben to translate and articulate business needs into defined learner outcomes. He has experience with various LMS implementations including Moodle, Docebo, Plateau, SABA, DOTS as well as bespoke solutions. Ben is an Articulate Trainer/Developer with B Online Learning.
