6.

Planning and Implementing Microlearning

As seasoned practitioners, we know all too well the calamities that befall poorly planned training initiatives. We also know that not all learning and development professionals come to their job roles the same way. That’s why the topic of planning and implementing microlearning initiatives is so vital. On one extreme, we have people with a blank slate who have never tried microlearning, although they may have had other experiences in managing, planning, or participating in a training project. On the other, are the folks who gave microlearning a shot but felt burned by the effort.

Somewhere in the middle resides the sweet spot all managers of learning initiatives strive for—low risk, few changes in project expectations, a committed team, and a well-estimated timeline. Oh, and a stable budget with a little padding. But until you can consistently get this unicorn and rainbows mix, you should take what you know and reflect on it with the considerations we raise in this chapter.

Although it should go without saying, we want to be clear that our perspective is based on:

• industry best practices

• our own years in the field and in performing research

• what we believe are unique aspects of microlearning that influence the planning and implementation of it.

Failco’s Unsuccessful Microlearning Implementation

We can learn a great deal from failure. So let’s look at a company that had a “not so successful” microlearning implementation. Names, locations, and other details have been changed, but the underlying reasons for failure and miscues by management are all too real.

This company (called Failco—an attempt at a cute name) is a manufacturing organization located somewhere in northwest United States. The company had been manufacturing furniture for decades and had a solid product. Unfortunately, sales were down and many in the company attributed the lack of sales to the new sales force who had not “grown up with the products.” Therefore, they needed more training.

In a desperate search for ideas, the assistant vice president of sales at Failco attended a short webinar on the virtues of microlearning. Upon hearing of some impressive sales increase percentages during the webinar, he decided immediately that microlearning was the solution to the sales department’s problem. His first step was to order the training department to “chop up” existing e-learning sales modules into smaller pieces, which were called “bite-sized learning.”

The problem was that the courses couldn’t just be “chopped up.” The one-person training department needed to apply some instructional design practices to the pieces or they wouldn’t make a great deal of sense. In addition, since the project was undertaken with such desperation and no planning, no one really knew what the budget was. So, with management’s full attention on microlearning, the one-person training department saw this sudden interest and the growing demand for instructional designers as a chance to hire more employees. Within a month, three new employees were added to the training department.

The head of quality heard about the microlearning initiative and decided to purchase an off-the-shelf microlearning library of Lean Six Sigma courses. She had always wanted to implement Lean Six Sigma but could never get buy in. However, she hoped that having the modules would help improve the organization and, perhaps, get momentum moving in her direction. Unfortunately, she hadn’t asked the IT department to vet the microlearning courses, which, it turned out, were optimized for mobile devices and not desktop stations. In fact, the presentation on a desktop looked rather anemic. The problem was that the people working on the floor did not have company mobile devices and were highly reluctant to download the software on their private phones. So they had to take a few minutes before or after their shifts to go to a desktop and take the Lean Six Sigma training. As you can imagine, morale was horrible because the training looked bad and the organization wasn’t even undertaking a Lean Six Sigma initiative. It seemed to most of the employees to be a colossal waste of time.

In the meantime, the AVP of sales didn’t bother to conduct a pilot program before he rolled out the sales-related microlearning to all 56 sales professionals. Once again there were technology issues—the program ran well on the iOS phones, but didn’t run well at all on the Android phones. The company had allowed sales reps to purchase whatever phone they wanted, and it was an almost even split. Half the sales force had no access to the microlearning.

Four months later the AVP of sales was fired along with the entire training staff because of their “out-of-control budgets,” “lack of results,” and poor estimates of how long the project would take. It was an unmitigated disaster.

Factors Influencing Planning and Implementation

The Failco microlearning disaster was a direct result of poor planning, no recognition of the many factors that influence the success of microlearning, and an out-of-control spending spree. Unfortunately, these types of microlearning implementation failures are more common than they should be.

One thing that leads to disaster is not accounting for the many variables that need to be considered when implementing microlearning, such as the organization’s work environment, culture, technology infrastructure, and experience launching learning programs. Yes, Failco saw the potential of microlearning, but the training department should have raised a red flag when it realized that it was simply being used as a way to quickly enhance training and increase sales. There was a complete lack of planning or coordination within the organization.

Now you might not be in the same situation as Failco, and we recognize that our readers are coming from different starting points. You could be updating an existing training program or launching a new product or teaching college seniors about game design. Not all situations are the same, but the basic process is and following it will help you avoid many mistakes.

For example, a new initiative would require a longer runway for implementation. Not only because there will be unforeseen circumstances, but other factors, like resistance to change by stakeholders, will add risk. This in turn would create a need to plan additional activities in preparation for implementation, such as a marketing campaign or informational sessions to answer questions.

Meanwhile, in a company where microlearning has been part of the corporate culture for many years, implementing a new “flavor” of microlearning, such as a gamified approach or adding videos, won’t be as big a shock to the organization.

Of course, different microlearning types, modalities, and use cases will also factor into your implementation process. We’ve outlined a process here that will likely require some modifications, but the basic framework is solid and can be used in virtually any type of microlearning implementation. Your job is to take the information from the other chapters in this book, combine it with the framework presented here, and make an effective plan.

But to paraphrase an old military saying, “No plan survives contact with the reality of implementing microlearning.”

Getting Started With Planning and Implementation

With that thought in mind, where should you start? Great question. We will approach planning and implementation based on a training development process that looks at the three stages of production: pre-production, production, and post-production.

Before moving forward, we need to define what we mean by the training development process. To us, it encompasses the activities and respective methods used to create a learning product. This process includes the initial planning to the kick-off meeting to the implementation or launch of the product for use by the learning audience, all the way through executing the evaluation plan.

Pre-Production

Pre-production is considered the planning phase for developing and implementing the learning product, which, in this case, is microlearning. Activities to undertake at this stage should include, but are not limited to:

• defining the project scope with the client (who can be internal or external to your organization); for example, expectations, budget, timeline, resources, and assumed risks

• analyzing the learners, the learning environment, technical specifications, tasks, and instructional goals

• assessing any previously developed learning materials

• gathering content and other subject matter–based materials

• defining a creative direction

• determining resources (such as equipment and talent) and methods of acquisition.

Use your best judgement to decide which activities are of the most value and resonate within your organization. However, don’t spend so much time in pre-production that you never reach production—be intelligent about how deep and how much analyzing, planning, and defining you need to perform. You need to do some, but you don’t need to write a tome either.

Production

Production is the actual creation and development of all the learning assets. During this phase, the main goal is to keep to the agreed timeline, gain approval from the client (internal or external), and mitigate risk. An undercurrent that runs parallel to creating the microlearning product is the implementation tasks.

Implementation activities can even commence in pre-production if necessary. For example, to test a new microlearning product on the organization’s intranet, the IT department would want to ensure an appropriate environment is set up and ready for testing. This might mean something simple, like creating a new folder structure, or it could be something more complex, like upgrading the intranet platform, adjusting settings on the server to play back different file types, or ensuring appropriate plug-ins are in place.

Pilot testing may even need to start months before actual training development of the microlearning (production phase). This can happen if you’re trying a complex solution, like a mobile app, or coordinating the timing to other types of learning events. For example, we cannot imagine sending out 52 educational email messages as a microlearning initiative without first creating some type of prioritization process to determine when you would distribute them. You certainly would not want to release them all at once! You would also need to work with IT to distribute the messages to the appropriate audiences and to manage the distribution lists. And, depending on the content and your organization, each message may need to be approved by the legal department.

Even aspects that occur post-implementation can require more time than just what you would have during production. For example, part of implementation may be gaining usage data (such as open rates and click through counts) from those 52 emails. If your current email software does not offer these types of analytics, the organization may also need to research, request bids, purchase, test, and pilot an analytics tool.

Post-Production

The post-production phase starts when you have scheduled the microlearning objects (if there is more than one) to deploy. The phase ends with implementation of the entire initiative, which includes, but is not limited to:

• testing or piloting the training

• marketing the new training as necessary (such as for compliance)

• training helpdesk and technical staff (as applicable)

• rolling out the finalized product to the target audience

• evaluating the deployed training.

With respect to evaluation, microlearning creates a lot of buzz around how effective it can be. In chapter 4 we explored research that shared compelling evidence of its ability to influence performance outcomes when designed and deployed in an effective manner. With that in mind, we believe that those interested in investing time in microlearning will evaluate the effectiveness of not only the products, but also the processes used to create the microlearning products. We take a deeper dive into evaluation on both fronts in chapter 8.

Risk and Change Management

Why is it that risk comes first when change is to blame? It’s like when you know you have to invite an acquaintance to your party—not because you want to, but because they will inevitably find out about it. That’s change. But when that acquaintance decides to bring an uninvited guest? That’s risk.

In new initiatives, change is typically the front runner to the issue of risk. Key factors are:

• unforeseen issues—we don’t know what we don’t know

• budget—we underestimate projected hours for each or all phases

• implementation—we didn’t give ourselves enough time to flesh out the infrastructure or technology

• lack of buy-in from project stakeholders.

Granted, risk can happen aside change. For example, your SME just got promoted and is leaving for a month to begin an intense management program. Sure, there will be change, but this is less an anticipated change and more so a common factor for general project risk. Again, organizational culture may factor into whether it is a perceived risk. If the organization’s culture is big on employees moving into other roles and promoting from within, this is an acceptable and anticipated change. It would be seen as low risk given that it’s commonplace.

The same goes for our previous discussion points on implementation—a well thought out implementation plan provides low risk, but the more change necessary for successful implementation, the higher the risk. Common challenges with microlearning implementation revolve around resources and the ability to sustain the solution—especially if the microlearning initiative is a scheduled event. You will need to plan all microlearning initiatives for distribution based on the flow and timing of the overarching learning initiative (Figure 6-1).

Figure 6-1. The Balance Between Low and High Risk

Let’s take a look at an onboarding program that has undergone an evaluation to reduce turnover and increase job performance in the first three months. Part of the augmented program leverages microlearning through a combination of scheduled emails, videos, podcasts, and (micro-)e-learning courses. Given the new hire’s job role, some of the videos and e-learning modules will be different, whereas the emails and podcasts will be the same for everyone.

As part of planning, you recognize that you will need more involvement from marketing to assist in crafting the emails and podcasts. You will also need more support from IT to help define the user groups and align the content to those user groups to push the correct content at the right time. IT is also concerned about video playback and needs to perform tests for load and bandwidth, because previous training sessions did not include video or podcasts.

Next, you realize you need to adjust and expand your efforts in tracking and monitoring the release of the training program. Additionally, you need to devise a development schedule that maximizes the creation of the new learning components because the internal training department’s bandwidth was tapped and a vendor is being contracted. Selecting the contractor will also take time because you’ll need to go through the appropriate channels for procurement.

We could keep going, but we hope you get the picture: A little (micro) change can have a big impact on resources.

Sustainment and Maintenance

Even with pre-production, production, and post-production considerations, your microlearning planning process should include other considerations. A particularly important aspect of microlearning to consider is how you plan to maintain the content. Often microlearning is served in small pieces over a long period of time and you need a maintenance plan to avoid repetition and obsolescence of content, and to keep up with changes. At the very least, you should know ahead of time when you are planning to “retire” the microlearning and implement other content.

We would be remiss if we didn’t highlight this need to consider the maintenance aspects of your microlearning initiative. Our research and experience with clients show that while implementation is addressed in project planning, it is only to the point of getting the training to its new digital home and making sure the door is unlocked for learners. These plans commonly leave out any instructions for the maintenance or sustainment of a training solution.

Returning to the onboarding program example: It clearly has a maintenance element that is more than just plug-and-play. Company polices may change, company logos may change, the information you want to tell new employees may change. You need to have a plan for how to update the content and maybe even the technology. In fact, while you are planning to maintain and sustain the microlearning modules over time, it also might be a good time to think about how you are going to evaluate your microlearning program. We’ll talk more about that in chapter 8, but that doesn’t mean you shouldn’t start thinking about evaluation early.

At this point, you might be asking if evaluation planning fits under sustainment or maintenance. Or is it implementation? Well, it’s kind of all three. If you don’t think about evaluation at the implementation stage or determine how you are going to deliver and update the microlearning content, then it might be too late to set up your evaluation process later on. You might not have the right protocols or links set up to collect the data you want to ensure the microlearning efforts are hitting the mark.

Evaluative measures need to be determined early so data input opportunities can be identified. This will inform you of where and when to implement evaluation. However, once implemented the evaluative approach will also need sustained. With the onboarding example, your team will be pushing emails and other microlearning to the learners. As a result, from the training side, data would be pushed to you at identified times as part of evaluative approach. If systems or APIs change, then changes need to be made to the process for pushing data.

Estimating Microlearning Hours

Now, once you’ve nailed down planning factors such as production, risk, and maintenance, it’s time to think about developing the microlearning. The big question then becomes: How long does it take to develop microlearning? How much time do you need to plan for the design and development? The standard and not very satisfying answer is, it depends.

This answer is based on research we have published every few years since 2003, focused on how long it takes to develop an hour of training. Our latest update to the research was in 2017. Now, we won’t say that estimating development hours for microlearning or any learning is our favorite task, but we have gained a number of insights into what affects the time requirements for development.

To start, you want to consider your level of experience in training development, the use of the ADDIE model (analyze, design, develop, implement, and evaluate), if you’ve got a contracted resource or an internal department, and whether you’re using templates and style guides. If that wasn’t enough, you should also look at what influences the developmental hours. Several of those factors also align with risk and change management. Our work has shown that the most critical influences on estimating hours are:

• a clear plan that is understood equally by all project stakeholders

• buy-in from all project stakeholders

• comprehension of the expected outcomes, responsibilities, and tasks by both project stakeholders and supporting staff

• established development processes including standard development and review cycles, templates, and style standards

• consistent and timely communications

• an agreed-upon plan for managing project scope changes and modifications.

These broad areas cover much of what causes problems with a project that’s underway; however, we are not claiming that these are the only variables. Use them as guiding principles and evaluate each against the knowns of your organization to factor their weight upon project planning.

If you want to get more precise about estimating the exact amount of time it might take to develop microlearning, you’ll need to roll up your sleeves and create an hours estimate. To create an estimate, there are four basic methods: similar projects, formulas, bottom up, and industry standards.

One thing to keep in mind with estimating—it almost always takes longer to develop microlearning than you anticipate. Don’t be lulled by the term “micro.”

Similar Projects

Think about projects you’ve already done that are similar to the current microlearning you need to develop. Consider this scenario: Have you ever done microlearning before? No. Are you trying to create a video? Yes. Have you done video for other learning initiatives? Yes. Well then, same rules apply. Just because it’s micro doesn’t mean that the process will be any different to develop video. Use what you know to help estimate.

A word of caution: Don’t fall into the following logic. You know that it takes 100 hours of time to develop one hour of e-learning in your company. The microlearning module is only six minutes, which is a tenth of an hour, so you think you’ll only need 10 hours of development time. Not true! The shorter learning time does not necessarily equate to a shorter development time. For example, it takes just as long to set up a shoot to capture one hour of live action video as it does to capture six minutes; the set-up time doesn’t change even if the recording time does. Also, it’s often more difficult and time consuming to create a short, highly focused learning piece than a rambling one-hour module of a SME’s mind dump. In fact, when Karl’s grandmother sent him long letters in college, she would apologize by quoting Mark Twain: “I didn’t have time to send you a short letter, so I wrote you a long one.”

The underlying premise is that this project is analogous to that project. This type of estimating is used when you don’t have a lot of information about the current project or when two projects appear to be similar. Of course, if they appear to be similar but aren’t actually, the estimate will not be accurate. This method tends to be better for creating a ballpark estimate rather than an actual estimate.

Formulas

Another estimation technique is approximating the number of hours it might take based on experience and then applying weights for different factors. This is a process similar to the one described by Lou Russell in Project Management for Trainers (2015). A weighted factor is used to compensate for things like expertise. Obviously, an expert instructional designer might take a little less time than a novice, so it makes sense that you’d want to factor that into the equation.

The fancy term for this type of estimation is called Parametric modeling (Kapp 2003). The design and development variables are assigned a weight based on a number of factors including:

• expertise—your or your team’s familiarity with instructional design and content

• project-related work—the amount of time added to an activity to account for the number of people working on the activity (it always takes more time when you have more people on a project)

• level of interactivity within the microlearning product

• environment—factors that are not direct production hours, like checking email or attending client meetings.

If you are interested in more details on this method of estimating time, we strongly recommend tracking down Russell’s book on project management for trainers or Karl’s book Winning E-Learning Proposals, which contains a chapter on the subject.

Bottom Up

Another type of estimation is a bottom-up estimation, or what is sometimes referred to as a work breakdown structure (WBS). Bottom-up estimating is a process by which the major deliverables are broken down into smaller tasks until each task can be easily assigned a time value. The idea is that if you can break down each microlearning piece into a series of definable tasks and then assign an estimate, you can roll up all the tasks to determine how long it will take for the entire microlearning project. This is perhaps one of the most accurate methods for determining the amount of time to create microlearning, but the process itself is time consuming.

Also, keep in mind that while this method can be effective, it’s not perfect. If a task is forgotten or time is not included for communication among team members or someone severely over or underestimates a task, the estimation can be inaccurate.

Industry Standards

Using an industry benchmark can be helpful if you’ve never developed microlearning before or if you want to gain some understanding of whether your development times are above or below average. For example, if you know that most organizations take 50 hours to develop a 10-minute microlearning lesson, then you can gauge approximately how long that might take you. Unfortunately, since no universal standards have been sanctioned by a governing body, exact standards do not exist.

Phil Mayor, creative director at eLearning Laboratory, suggested it would take around three hours to develop (information gathering, design, authoring, and so on) any learning program under eight minutes. If the microlearning was longer than eight minutes, he said to add an additional hour of development time for each minute. As an example, if the e-learning seat time was nine minutes, you should estimate that it would take you four hours to develop. You would need three hours for initial development of the first eight minutes and an additional hour for the ninth minute (Westin 2017).

This formula accounts for the initial heavy lifting or “set up” of designing and developing instruction regardless of the ultimate instructional length. The setup cost is fairly consistent if you are shooting only two minutes of video, because you still need a camera, scripts, and lighting. All those elements have costs and time requirements that won’t change whether a shoot is eight minutes or eight hours—the duration of the instruction is simply the additional time and cost over and above the set up (which is accounted for in the first eight minutes).

Others have suggested that inputting content into a template-driven microlearning tool can take as little as two minutes. That’s great for inputting content, but it provides no information about the level of effort to gather the content, design the content, choose the right instructional strategies, and then write or otherwise create the content. As of this writing, there are no hard and fast industry guidelines specifically for microlearning development. So, estimating the exact hours it will take to develop a piece of microlearning is still as much an art as it is a science.

Short and Sweet

Properly implementing microlearning can be thought of as a multistep process involving pre-production, production, and post-production as well as considerations of risk and the long-term maintenance of microlearning content. One big part of the entire process is to determine the number of hours it will take a team to develop the necessary microlearning. There are many factors that influence the length of time; we’ve listed many in this chapter but there are always others. The important thing to note is that you should choose an estimation method and use that method consistently to develop a real sense of the numbers that work for your organization.

Following the steps in this chapter should help you have a smooth implementation with few surprises. The more you can anticipate factors that might negatively impact progress, the better you are able to mitigate that risk. Even if your estimate is not 100 percent accurate (and it won’t be), simply thinking through the factors and understanding the potential risks will better prepare you for the microlearning development process.

Key Takeaways

Based on the information from this chapter, the following actions will guide the planning and implementation of your microlearning initiative:

• A multitude of variables influence the project, and you should consider as many as possible when planning. For example, culture or organization, current work processes, and current technological infrastructure.

• Microlearning can seem like a quick and easy solution to implement, but it is also important to consider that most microlearning projects need more consideration around planning and implementation. Although all training initiatives should consider implementation up front, microlearning projects have a higher risk if implementation is not discussed for pilots and new initiatives.

• One method of breaking down a microlearning project into a workflow is to use a production mindset. Pre-production is used for planning; production is the actual process of creating and developing; and post-production is where implementation and evaluation reside.

• With any new initiative there is inherent risk and change to manage. Implementing and sustaining microlearning can create some of the greatest risks and changes to different departments, especially to workflow and human resources.

• There are too many variables to list when calculating development time, but they can usually be grouped by expertise of the training developer and expertise in the subject matter, number of people on the project, the administrative aspects of projects for purposes of management and moving work forward.

• There are several options for estimating project hours.

• Estimating the exact amount of time it takes to create microlearning is still as much of an art as it is a science.