I'm often asked by clients if they should develop their own content, or pay a developer to make it.

The answer to this question basically comes down to skills and time.

Background 

There are two ways to develop content for eLearning. One is to use a desktop application like Articulate Storyline, Xyleme, Captivate or Lectora. The other way is within a Learning Management System (LMS). Some LMS's, like Moodle and the Janison CLS, have a content authoring system built into them. You can add pages and content to modules and then build those modules into courses.

Then there are also two types of teams who can develop the content. One is an internal team of SMEs and other technical people within your organisation. The other type is to contract one of the many content development companies out there to do it for you. I call these two approaches internal and external. If your organisation has a range of Subject Matter Experts (SMEs) who've been teaching the content for years, it's tempting to think that you can simply plonk them in front of a screen, give them a login to the software and let them loose.

However, allow me to lay my cards on the table. Our company, Canopi, develops content on behalf of clients, but we do also train clients up to develop their own content. In other words, I don't have a bias one way or the other. It just comes down to some pragmatic choices by the client.

The skills required to develop content

If you're contemplating developing your own content then, to be fair to those involved, you do need to conduct a skills audit on the team to see if they have the skills to complete the task to your and their satisfaction. You then need to give them a reasonable amount of time to do it.

A content development team

A content development team has the following skills which may be spread over one or more people. The important thing to keep in mind is what sort of content you want to develop, and then making sure you have the skills in the team to execute the plan.

If you're considering building content internally then you can use the above table as an express skills audit.  If you do, then be brutally honest as there is nothing worse than thinking that you have the skills in place, starting a project and then finding out that things aren't as they seem.

Upskilling

If you do your audit and find out that there are some skill gaps then you will need to consider how you will overcome this. You may choose to acquire these skills externally or undertake a skills development program and/or some sort of mentoring while the team gets up to speed. Getting up to speed takes time and you need to allow your team the time and resources to develop. As an example, if I put on an Instructional Designer it normally takes between 2 - 3 months for them to come up to speed on the system capabilities and our process.  After about three months they can generally work unsupervised in a productive manner.

Developers can take a bit longer, but generally, if someone has done a Cert 4 in Multimedia or similar, it will take them about 3 - 4 months to come up to speed on the system and our processes. This doesn't mean they aren't doing work in that time, it's just that it takes that long to get fast and deliver to the quality we expect with minimal supervision.

SMEs as Instructional Designers

Welcome to one of the biggest deliberations of eLearning. To create a good quality course someone has to write the storyboards.  To do this requires an understanding of both how people learn online and a high level understanding of what tools they have available in the authoring system. 

How would they know about using a hotspot if they didn't know the system has hotspots, what options are available on hotspots, what does it costs to create one hotspot (they can be very labour intensive to build).

So then, do you teach your SME's how to write for the online space and about what tools are available in the system, or do you teach an instructional designer about the subject material.  Well I've tried both approaches over the years and I believe the best quality results come from having the SME work with the ID to create the finished storyboard. Yes, it costs a little more but the end result is much better, and the process is a lot faster.

Getting started

My advice? Never start with the first product you really want to launch.  Upskilling a development team (or person) takes time and if your first course is supposed to be the one that changes the world then the quality of the first modules will be lower (because it's their first) and then get better as the course goes on. That's no good because the learner will initially see your first bit of work since they start at the beginning.

Far better to do some training, and then do a short, low impact (disposable) course, like Staff induction or Member Welfare Policy, to hone your skills. By starting with a small course like this you can assess the team's ability, not make it feel like an overwhelming process, and have the team achieve an outcome within a reasonable time frame.

During this skills development phase it's a good idea to try and arrange some mentoring from experienced developers.  You can use mentors to review specification, storyboards and the beta products.  They can also be useful if you just want to ask "What if" or "how to" questions.  

Time? "Time is an illusion", Albert Einstein

It might be an illusion but we are driven by timelines and you will have expectations of when your course will be released. In my experience this is where things get tough. Too often I see a Subject Matter Expert sat down in front of some software and told "build me a course". Years ago in the TAFE sector teachers where given 40 hour reductions in teaching loads to build one course. It was brutal, and everyone got disheartened because you just can't build a new course from scratch with unskilled staff in 40 hours.

Your first course will take a long time to build while people skill up. The next one will be quicker, the one after that even faster still. However, unless you want to crush your staff, you must ensure you give them adequate time to develop. A big (Level 3) course we did recently took 18 months from start to finish. An express, short (Level 1) course would normally take an experienced team like mine about 3 months, and involve about 120 hours of work.

If you move staff onto eLearning development then make sure they don't still have 100% of there old job to do.  It's pretty common but we often 'Add' eLearning development to the existing duties of staff without reducing or modifying their responsibilities. This is cruel, dishonest and doomed to fail, you just can't add this on. The project will fail and it won't be the staff members fault (even though they will feel like a failure), it will be yours. I've seen this happen too many times to use soft language on this point. Give them the skills and give them the time.

Skills Redundancy

A final point to consider with internal development is how you manage the diversification of the skills in the team. There is no point developing a whole lot of expertise in a person to see them walk out the door to get a higher paying job in the banking or finance sector. I've got a client at the moment where this has happened three times. In the end they just asked us to take care of the whole thing for them.

This is not to say you shouldn't invest in your people or do content development internally, but you need to seriously consider that 2 or more people should be partially skilled across the different disciplines. This will help ensure that if they do leave then you can keep operating. You should also insist on very tight documentation standards as these will ensure that if a person does leave then at least you can trawl through the folders to find key bits of information.

External Development

So you might be wondering at this stage why you didn't always do your own development, it sounds so good. Well, let me come in from the developers side (which we are one) and put forward our case.

A developer will be very good at making the most of the platforms they use, Lectora or the Janison CLS for example.  Our stuff are guns and can churn out development at very fast speeds because they do it every day. They get really good at all those little short cuts and the longer they are with us the better they get at it.

Our instructional designers are also very familiar with what the systems are capable of so they, too, get very good at making the most of the systems capabilities to design the best learning they can within the client's budget.

I think the final point to be made on the side of external development, is that if you work with an external developer then you often get forced through some key steps like contracts, vision and scoping, storyboard review etc.  These steps tend to improve the quality of the final product. You can do this if you go down the internal development path as well, but the temptation is always there to cut corners and not do storyboard reviews etc. All of these processes do come at a cost and can slow progress, but they absolutely improve the quality of the final product.

Summary

So, to conclude my thinking on this, internal development gives you total control over the end product and reduces the risks of trying to find a vendor that you don't know if you can work with, but it does come at a cost. This cost is time, it will take you a considerable period of time to get the team up to speed and working at the quality that you might aspire to.

External development has its advantages as well.  An external developer will have highly specialised skills in the publishing software that they work in which, in our case, is the Janison CLS. They will be able to milk the very best out of the system and generally will force you through some well considered steps to ensure a quality end product, but it comes at the expense of cash out the door.

Either way can give you great outcomes. I wish you all the best with your development.

 [Comments and questions welcome, just register to contribute]