e-Learning Guru Logo

home | site map 
Send us a note 

Dashboard elearning tab Events Calendar


Subscribe FREE to the monthly
e-Learning Guru
newsletter!

Your work e-mail:




Sample Issue #1
Sample Issue #2

I value your privacy. I will never rent or sell your e-mail address. You can always unsubscribe with one-click.

Google Search

WWW
e-LearningGuru


Beginner Basics
Presenting the Business Case for e-Learning
     by Kevin Kruse

There will be a time when you need to "sell" your plans for the development of an e-learning program, or for infrastructure that will be used to support e-learning efforts. Whether you are trying to get a budget approved by your supervisor, or trying to gain support from another department, the guidelines presented here should help you to achieve your goals.

Focus on Business Problem and Solution

In all of your communications, whether a written project plan or a casual conversation with a stakeholder, make sure to focus on the business problem at hand and how your e-learning program will help to solve it. If, instead, you focus on the features of e-learning or delve into the jargon of technology, you risk losing your audience when they become confused or uninterested in the details. You should be prepared to discuss how the program will improve communication; increase performance, quality, or service; and ultimately impact sales, costs, or productivity.

Emphasize Return on Investment

You will get the most support when you can project real, quantifiable results using the financial terms important to top management. You should estimate your program's cost-benefit ratio, break-even point, and return on investment. Discuss in detail how you plan to control the costs and risks associated with program development, and how you will measure the results over time.

Present a Clear Plan of Action

Even if you convince your supervisors and peers that the business problem is real and your solution is viable, they may have concerns over your ability to implement the solution. Use a detailed project approach to overcome any objections about the development of the program. Make sure to include:

  • Description and experience of project team or vendor.

  • Total hardware and software budget.

  • Total course development budget.

  • Minimum hardware and software specifications.

  • Complete schedule and/or GANNT chart showing major milestones.

  • Alpha and beta testing process.

  • Methods for end-user support.

  • Plans for program evaluation.

Use Case Studies and Research Reports for Proof

There is always great reluctance to trying something new, especially if it will require a substantial investment. Senior executives, mindful of the relationship between expenses and profitability, tend to be conservative in this regard. They will often ask, or be thinking, "Who else has done this?" Or even, "What other companies has the vendor done this for?" Your cause will be helped greatly if you can point to others who have gone before you and show the results they achieved.

Fortunately, training professionals have been generous in sharing their experiences with technology-based training. Finding case studies, examples, and references of TBT projects should not be difficult. Often these cases come complete with return-on-investment information. Internet Web sites and publications that frequently feature case studies include:

  • Brandon Hall Resources, headed by noted expert Brandon Hall, is the publisher of the Multimedia and Internet Training newsletter (www.multimediatraining.com).

  • Tim Kilby maintains the Web-Based Training Information Center, which is an independent Web site (www.webbasedtraining.com).

  • Training magazine has growing coverage of the field of TBT (Lakewood Publications; 800-328-4329).

 

Model Memo Describing New e-Learning Project

There are some general guidelines to use when presenting your technology-based training project, which apply to virtually any medium. This includes memos, slide-show presentations, and even one-on-one meetings. A common mistake is to lead with the capabilities of the development team, followed by the features of the project. Ideally, the process should be turned around so that the major emphasis is on measurable benefits, followed by features, and finally capabilities.

    Summary - Brief description of the project and its components. It is a good idea to lead with this, even if the primary reader is familiar with the details. You never know who else the memo might get distributed to. Remember to keep this section short and to the point, so the focus quickly turns to benefits.

    Benefits - Include all benefits, especially those held most dearly by the group you are presenting to. In this case, there are intangible benefits such as "Information is available faster" and many tangible benefits that impact the bottom line, such as "Saves printing costs."

    Costs - In the memo format, just provide bottom line costs. If someone is questioning the breakdown, he or she can ask for further analysis. This tactic prevents individuals with counter-agendas from focusing on the minute details and picking apart each piece of information.

    Financial Return - This is a vital piece of the internal sales pitch and is written in clear, direct language that speaks directly to the CEO, CFO, and others responsible for profit. The financial return projections are so positive they have been bulleted to make them jump off the document page.

    Development Schedule - Again, providing specific milestones in this type of document only provides more data to be debated. If your goal is to obtain project funding, try to leave inter-project milestone dates vague to reduce objections related to conflicts with other project roll-outs. Focus on major milestones like project kick-off, pilot tests and final launch times.

    Team Experience - The last item that should be included is the capability of the team. If the development team is internal, reference their prior experience on similar projects, academic credentials, and any other noteworthy items. If the team is an outside vendor, list previous experience, results from reference checks, and any awards or honors they have received.



© 2002 - 2004, Kevin Kruse