Building an eLearning Business Case

Engaging with the Project can be tricky.  The culture, politics and hierarchy have to be taken into account.  The eLearning Business Case for a Business As Usual (BAU) Team (generally comprising Learning and Development or Training personnel) is strong, but only once the Project has gone live.  From a BAU perspective the key is to engage with the Project team as early as possible, supporting what they need to achieve without adding huge costs.

When external partners are retained for large ERP Projects their focus is very much on getting the users trained ready for ‘go live’.  Often on a budget and with tight timelines, corners are cut just to ‘get over the line’ even though this is often the users’ first introduction to eLearning and the target application.

In many organisations there will be silos of different teams or projects that have already invested in eLearning tools to meet their own specific requirements.  It may be possible to wrap up all existing Content into a Learning Management System (LMS), providing there is some consistency throughout. In any case you will want to avoid telling four or five different teams that their Content is rubbish. It may therefore be necessary to identify the defacto enterprise tool and redevelop all of the existing Content.

Often a combination of the above will result in an organisation recognising the need to adopt an enterprise wide eLearning solution.  In many instances the need for action – a strategy of sorts – arrives in the inbox of someone in Training or Learning and Development.

Assessing the Requirements for an eLearning Business Case

The first step for any organisation developing an eLearning Business Case is to consider their business requirements.  The groundwork for an eLearning Business Case should include the Business Requirements Report but need not be overwhelming, although time and effort applied at this stage will reap rewards across the board.

Typical information to be investigated and recorded should include:

• Timelines – are you tied to a Project Plan or request from the Board? Does the year end (and spending of budget) have an implication?
• Application(s) – this should not just consider one application, the business will need something that suits all.
• Reporting – what are the drivers, i.e. compliance / governance, competency, talent management?
• Infrastructure / Environment – ensure that you bring IT on-board as soon as possible. eLearning tools do need technical support but it is important not to get the IT support requirement out of context; these tools do not require support of the scale required by an SAP or Oracle application, for example. Do not allow IT to over complicate the requirement. They do need to be consulted in terms of reviewing the technical specification, testing the tool and taking ownership in terms of the networking infrastructure, i.e. bandwidth, end user technology, other projects, potential upgrades, back-up and disaster recovery.
• Existing Tools – you need to consider what tools are already in the organisation, are they still current, who owns them, what was the experience, was any measurement of success taken, was there a pilot program, how were the Change messages communicated? Is there an existing Maintenance and Support Agreement?
• Budget – is this tied into a Project or does the budget sit with the Learning and Development team? What is the expectation? Do not forget Maintenance and Support.
• Sponsor – you need to identify who at Board / Senior Management Level is going to support this initiative. They will be your first attempt at Change and Communication, from the top. Initial findings and proposals need to be presented to the Sponsor to gain support and guidance when presenting to the group or Board.
• Security – you also need to consider the Security requirements within the business as this will impact your choice of tool.

Training Needs Analysis

Ultimately your eLearning Business Case is all about the users and therefore your choice of tool must take into account their needs and requirements. It is therefore essential to undertake a Training Needs Analysis (TNA). Typical information to be covered within a TNA will include:

• Application – process scope, generic roles, customisation and language requirements.
• Geography – where do the users reside and are there multiple time zones to consider?
• Technology – what are the technology constraints, i.e. bandwidth, end user technology, etc.?
• Logistics – can they travel? Are they IT savvy? Do they all have a desktop or laptop computer, or access to one
• Job Roles – identify current roles and responsibilities.
• Current System(s) – what systems are they using in their job role now? One system or several? How much do they do manually?
• Skills Gap – matrix the AS IS versus TO BE in terms of job role, responsibility and hierarchal reporting.
• Language – is language a consideration in terms of training and support (irrespective of application language)?
• Legal Considerations – HR law is different in each and every country, i.e. Sarbanes Oxley restrictions on finance projects, local QA restrictions, etc. This can also present technology restrictions, i.e. limited use of social network sites in certain countries and organisations.
• Culture / perceived learning style – have the users received training previously? How was this training delivered? Have they previously been trained via eLearning?
• Expectations – Do they have any? Is there a Change and Communication Plan in place?

The objective here is to record as much information as possible and use it as the basis for the development of a Training Strategy.

Product Analysis – the Tool Selection Process

Following the development of the Business Requirements Report and the TNA, you can now start to evaluate the various tools available. Start by building a list of features and functions for each of the tools you are evaluating. Once identified, these need to be weighted in terms of their value in the context of the Business Requirements and the TNA.

It is important to establish if each tool works with all of your applications and if only one Licence is required for use across all applications, i.e. you may have to purchase another Licence or even ‘extensions’ to obtain a tool that will meet all of your needs.  The Vendor’s Licence Model is important in terms of usability and cost.  Check the definition of the terms used within the Licence – one Vendor’s use of ‘Employee Licence’ is different to another.  Make sure they offer a Perpetual Licence, i.e. if you let Maintenance and Support lapse once you have purchased the tool, are you still able to use it?

If you wish to use the tool to edit existing Content, check with each Vendor that your Content is compatible. You could provide them with some sample Content and ask them to demonstrate this at the Proof of Concept, discussed later.  You also need assurance that when there is a product upgrade, your Content is upwards compatible.

Vendor price lists and discounted rates can vary by up to 90 per cent.  Find out how the Vendor’s financial year runs – you may be able to leverage substantial advantage if you understand the pressures of quarter and year end.  Make sure you receive written confirmation of any agreed pricing and how this is broken down so you know exactly what you will get.

The cost of Maintenance and Support Agreements generally vary from around 18 to 22 per cent of the purchase price.  Establish with the Vendor what you get for your money, i.e. all product upgrades. Also find out from the Vendor how often you will get a product upgrade and if you can review upcoming features and functions – they may be able to share their Roadmap with you.

Consider what might happen when your application upgrades – can the Vendor provide any assurance that the tool will still work?  Will you have to buy an extension?  Will your Content migrate?  Find out what type of Support is offered and from what time zones. The Vendor should be able to provide you with their Service Level Agreements (SLAs) and Key Performance Indicators (KPIs).

Ask for at least three references from each Vendor and arrange a visit to their premises if you can.  Find out as much information about each Vendor as possible – who they are, their history, financial stability, etc.  Also establish the history of the tool, i.e. who developed it, did the current Vendor buy someone else’s tool and rebadge it?

Proof of Concept

This stage, also known as the ‘shoot out’, is where you invite each Vendor to deliver a presentation and demonstration of their tool.  Ideally, you should have at least two, if not three, different tools to compare.  Ensure that each Vendor is given a formal invitation detailing all of your expectations for the session. Make sure that you are comparing like-for-like products. For example, do not compare Assima Training Suite with Adobe Captivate – two very different approaches to content development and deployment.

The objective of the Proof of Concept (POC) is to ensure that each of the tools can deliver ‘what it says on the tin’.  Each Vendor should provide a technical resource to install their product in your environment so that you can test it against the applications you are running.  Make sure you know all of the applications you need the tool to work with. This should be listed in the invitation to the Vendor and in any subsequent paperwork.  Ensure that an instance of the application is available for testing in the POC.

Your IT team need to be involved before each POC takes place, to discuss what technology and security is required.  They should also attend at least part of the POC to discuss the technical specification – you need reassurance that the tool you finally choose is supported by IT because it will work in your environment.  It may be that your IT infrastructure will restrict what deliverables from the tool can be supported.  Your IT team will help you to understand the risks and the implication for BAU and disaster recovery, etc.

Consider all of the deliverables you need from your eLearning tool – these will tie in with the features and functions identified in your product analysis:

• Change and Communication
• Process Mapping
• Application Design Workshops
• Classroom Training
• Quick Reference Cards
• eLearning
• Offline / Mobile Learning
• Knowledge Checks
• Pre and Post Course Assessments
• Prescriptive Learning
• Third Party Content
• Hierarchal Reporting – customisable
• Learning Management Systems
• SCORM / AICC

The format of the POC typically follows the scenario below:

1. Install and configure the tool in your infrastructure.

2. Test against your applications.

3. Provide two or three typical processes to be recorded – time the recording and include items such as:

• Storyboard and application
• Logos, colours, fonts, etc. to represent your brand
• External documents including process maps, standard operating procedures, links to web sites, media, etc.

4. Request that the Content be edited so you can see how easy this is and if changes filter through to all of the deliverables?

5. Create a process incorporating multiple applications.

6. The Vendor should be pleased to leave the recordings with you. Some Vendors will leave the tool on an evaluation basis (perhaps two to four weeks).

Total Cost of Ownership

At this stage it is important to consider all of the costs associated with ownership of each tool.

Licences – you should receive a Proposal from the Vendor including all of the Licence costs. Make sure the validity date ties up and that Maintenance and Support is fixed for at least three years.

IT Costs – these will include any additional hardware, such as a server or servers, which may be required. It should also encompass the cost of managing and implementing on-going updates including the operating system, hardware, IT testing of service packs, load testing, user acceptance testing, application testing, support costs, back-up and disaster recovery.

Services – these may be provided by the Vendor or another third party with expertise in the eLearning tool. Costs could include installation of the tool, training and support, as well as consultancy services around development of standards and best practice.

Develop / Edit / Translate / Publish – these are the hidden costs not always considered when looking at the total cost of ownership of an eLearning tool. You need to consider how long it takes to develop Content, from start to publish – think in terms of processes by job role. End to end it can take between two and 22.5 hours to develop one process – same process, different tool.

Training Strategy

The Training Strategy should reflect your findings within each of the previous sections as well as dependencies and risks. It should also include a Project Plan which would provide a clear indication of the chronological order of what is required and the budgeted costs at each stage, encompassing software, technology and services as well as predicted deliverables, etc.

The importance of assessing the business needs when developing an eLearning Business Case is paramount, in order to ensure risks are reduced and the business selects the right tool that will deliver a return on investment. Different organisations will have varying business requirements and needs but the considerations I have outlined here can provide the bones of a working document in order for you to develop your eLearning Business Case.

Visit our services page for more information on how Larmer Brown can help with your eLearning Business Case