4
Technical Training Development Strategies
What’s Inside This Chapter
This chapter defines the different development strategies you can choose for your technical training, focusing on:
• the importance of communication confidence
• choosing the best development strategy.
A worksheet is provided to help you analyze how to factor your SME communication confidence into a development strategy.
4
Technical Training Development Strategies
What development strategy should you use for your technical training? There are different strategies to choose, depending upon the dynamics of the project, the assigned SMEs, the training technology used, and so forth. SME communication is possibly the biggest factor to consider.
ADDIE Model
Let’s begin with a review of the traditional model of ADDIE (analyze, design, develop, implement, and evaluate) (Figure 4-1).
Figure 4-1. Traditional ADDIE Model
Analyze Stage
You, your SME, and your stakeholders identify the overall business purpose and the audience of the performance requirement. A variety of potential performance solutions are considered through a needs analysis.
Design Stage
During this stage, you and your SME identify solutions to your performance needs. For any learning or training-related solutions, you and your SME will create learning objectives along with the road map or storyboard for the course or learning object.
Development Stage
This is the “meat and potatoes” of the ADDIE process. Most of your work and communication with the SME will occur in this stage of the process. At this point, the direction of the project has been set. Within this stage, you and your SME work together to create content according to the specified design road map or storyboard.
Implementation Stage
In this step, the learning materials are tested out. This is your opportunity to see the efforts of the development stage come to life. For traditional training solutions, the crux of the implementation stage is the pilot course. The pilot course is the opportunity for you to see how the class flows, what works, and what doesn’t work. For other training methods, much of the implementation involves technology coordination and testing, along with ensuring the target audiences get a chance to experience the content.
Evaluation Stage
During the final stage, you are determining whether the course objectives were addressed and satisfied, and you will also be looking at the quality of the content, audience reaction and retention, and other ROI measures. You will identify any changes required. If everything checks out, the project is successfully complete.
Risks of ADDIE
While ADDIE allows for well-thought out training, there are substantial risks within this process. You could spend a lot of time in the design and development stage, thinking you were in alignment with your SME, only to find that when you deliver a draft or protype, you and your SME were not aligned and you need to make major time-consuming changes or even start over with the project. This is a big deal. It’s expensive, it often causes unproductive conflict, and it wastes time and energy.
If you hit ADDIE right, it can be cheaper because you are spending all your time and energy on the one draft of content that will be used. However, if you hit ADDIE wrong—and there is a good chance you might—the consequences are more drastic than if you incorrectly identified them during an early Agile iterative cycle—described in the next section.
Agile
Merriam-Webster defines agile as “marked by ready ability to move with quick easy grace.” From a training perspective, Agile involves creating solutions in a condensed, iterative way. Agile begins with an analysis, then each iterative stage is composed of design and development followed by implementation and evaluation to set up a series of minimum viable products (MVPs). An MVP is the simplest version of the learning deliverable that can be implemented and evaluated. Each MVP is tested by the target audience (implemented and evaluated), and the design of the solution evolves as you go through the process.
When thinking about Agile training development, these are common features (Torrance 2014):
• Solutions are created in an iterative fashion. There are multiple cycles of creating an MVP.
• There is less focus on drawn-out analysis and design steps, which are accomplished during the development process.
• Iterations are open-ended and can go wherever the stakeholders want to take them.
• Testing is earlier, with each MVP tested by the target audience. So if the performance solution is moving in the wrong direction, an earlier pivot to the correct solution is possible.
Risks of Agile
An interesting component of Agile is that there is not necessarily a signoff or commitment from SMEs or stakeholders at each iteration. This is ideal in the sense that it truly opens the lid on the potential for the learning solution. For the same reason, it also could be expensive. In practice, most Agile software companies will still require their customers to sign off and commit on a UX/UI mockup before going forward with development. Those companies require this as a way to stay within budget and time constraints. The idea of not having commitment or signoffs can also pose some significant issues in real-world training development. Determining deadlines and future project schedules can be difficult if you never know when a project is going to be finished. For example, if I never get commitment from stakeholders that this is the direction to go, how can I plan when this project will be finished and when I can estimate that I can begin the next project? As busy training teams and consultants know, drawing the line and ending a project, while sometimes difficult, is a realistic and necessary real-world truth.
Other risks of Agile:
• Endless cycles of iterations are possible, especially for MVPs that take relatively longer and may be more expensive to develop. For quick or low-cost solutions, Agile makes sense. But, for example, what if our first iteration was to create an e-learning module, only to find out that the real solution was simply an update to a data-entry process? That could potentially be an expensive waste of an iteration.
• If you skimp on analysis, you can have problems. A partial analysis can hide performance problems and prematurely point you to a training or knowledge solution. It can be difficult to break out of that mindset.
Reconciling ADDIE and Agile
ADDIE and Agile have their pros and cons. Based upon your situation, you can choose from an existing development model or you can create a mix of the two on your own, taking the best of both worlds and tailoring it to your organization.
Choosing a Strategy: Type of Project
There are different things to take into account when choosing if you need to swing more toward ADDIE or Agile—one being your confidence in your SME communication, another being what type of solution your analysis points to, and, finally, a third being organizational culture—that is, real-world limitations and implications you need to take into account. Each of these are discussed next.
Regardless of whether you choose more of an Agile or ADDIE process, each project should begin with an analysis step, which will point you toward a fit-for-purpose performance solution.
Noted
A full analysis step is critical. Don’t skimp here. Sometimes during our analysis we may find out our performance solution does not include a learning program. Instead, the solution may lead us to a change in job structure, business process, additional tools, and so forth. If we just jump ahead to the solution—it is automatically a “product,” and we will figure it out as we go—we could be missing this critical performance perspective.
Really, the only time you might see a shortened analysis would be if the business has done some of the analysis on its own, the data is readily available, or if identified competencies (knowledge, skills, and attitudes) already exist for the target audience and the performance task or tasks in question. In these cases, your time in the analysis phase may be fairly reduced. But you will need to make sure you verify and agree upon the analysis conclusions the business has made on its own.
Depending upon what is decided (or guessed), this may affect whether you want more of an ADDIE or Agile solution. Answer this question: How much does my MVP cost to create? If the MVP costs relatively little (such as a pathway from a content aggregator, for example), then perhaps go full-scale Agile. If the MVP cost is substantially higher (such as commissioning a multimillion-dollar brick and mortar simulator), you probably are going to want to spend a little more time trying to narrow down your requirements and potential iterations. That is, you may move more toward ADDIE. Think about the cost of an MVP. Factor that into your decision, even if it means rethinking your MVP. Weigh the risks.
Choosing a Strategy: Organizational Culture
The culture and needs of your organization is an important factor to consider when devising a development strategy. Can your organization handle Agile work processes? Do you need absolute budgets, deadlines, and a final project end? If so, you may need to move more toward ADDIE, or you may need to implement a version of Agile that utilizes signoffs and commitments. Do you have easy access to your target audience so that you can readily test your MVPs? If you don’t have easy access to your target audience, it’s probably not feasible to expect full-scale testing of your MVP. Instead, you may have to rely on modified testing, or even simply short conversations with your target audience about whether they think your solution looks like it would work.
Choosing a Strategy: Communication Confidence
The quality of your communication with your SME is another significant factor to consider when choosing an instructional development strategy. Your Communication Confidence (C2) refers to your level of confidence in the communication between you and your SMEs and stakeholders. To explain C2, let’s first look at some basic communication principles.
Communication at its core is defined as a message going from a sender to a receiver (Figure 4-2).
Figure 4-2. Basic Communication Principles
While this seems simple, often there are discrepancies between the message a sender intended to send versus the actual message the receiver understood (Figure 4-3).
Figure 4-3. Disruptions in the Sender’s and Receiver’s Perceptions
At its core, your C2 is your confidence that, between you and your SME, the messages intended to be sent will be the same messages received.
Low C2
A low C2 means that you do not have high confidence that what comes out of the design stage will be the final product. A low C2 doesn’t mean your SMEs are horrible people; this could just mean that you have an extremely technical topic that has lots of complexity, or any of these other factors are at play:
• You have never worked with this SME before.
• You have never worked with SMEs before.
• The SME has never designed a course before.
• Multiple SMEs or stakeholders are on the project.
• There could be rapidly changing software, product, services, or tools that affect your work.
• You are trying out a new training technology.
• While asking questions during needs analysis, you see the danger of scope creep in the project.
A low C2 may point you more toward an Agile development strategy.
Think About This
What would you do?
Lauren was assigned a project. During the kickoff, Ron and his manager explained to her that all the performance problems field personnel experienced were related to a lack of understanding of the theoretical principles behind the operation of the tool. The next day, Lauren had a follow-up conversation to ask Ron to explain more about the hydraulic principles used to operate the tool. Ron answered by talking about the history of the tool. This tool was invented in 1980, he said, and then substantial updates were made. “Actually,” says Ron, “there is another tool we should mention in this training because when I was in Brazil, I saw it being used wrongly in the workshop.”
Lauren paused. “But that tool is not in the scope of this project … what am I missing here?”
Ron continued. “Hmm, I’ll think about that. You know, really, the tools and the theories are not the focus we should care about. The focus for us should be maintenance and paperwork. But if you want to focus on theories, I guess we can.”
“OK,” Lauren says, thinking to herself: “I don’t have a lot of confidence at this point. Low C2 here for sure.”
High C2
If you have high confidence that you and your SME have the same detailed expectations of the deliverable and that you both will send and receive intended clear messages to each other, you have a high C2. A high C2 means you have less of a chance of a nuclear reset of the project.
Here are some examples that may point you towards a higher C2:
SME and developer are the same person. If you are a SME creating your own training, you have the highest C2, assuming you know what is happening in your own brain and what kind of final product you desire.
• Competencies are defined.
• Similar courses or products already exist. This is just another in a series. If all are following same script, there is probably less danger of nuclear resets.
• You’ve worked successfully with your SME before. Your SME knows what to expect. You both understand each other’s roles, terminologies, and project expectations.
• You (the developer) have sole and final power to define the outcome of the course.
A high C2 may point you more toward an ADDIE-type development (or at least one with fewer iterations).
Basic Rule 8
If you have a low C2, you may want to move more toward Agile. If your C2 is higher, you can use fewer cycles or (gulp) even just plain ADDIE. Your C2 will affect how many iterations you need.
Once you have analyzed your confidence in your SME communication, what type of solution your analysis points to, and your organization’s culture and readiness for Agile solutions, you can craft (or choose) a development strategy that meets your needs.
And that development strategy can be a combination of both Agile and ADDIE, as described in the iterative ADDIE example below.
Example: Iterative ADDIE
Iterative ADDIE features shorter initial design periods, more iterations, early feedback from the target audience (not just assigned SME), and a focus on creating an MVP versus every possible bell and whistle in the final product. What stays the same between traditional ADDIE and Iterative ADDIE is the analysis phase. We keep a robust analysis phase so we don’t automatically jump to the conclusion that training is always the solution.
The benefits of Iterative ADDIE are that it adds feedback from the target audience sooner, while still giving an actual end point to the project.
Iterative ADDIE Process
Here is an example of how an Iterative ADDIE process might work (Figure 4-4).
Figure 4-4. Iterative ADDIE
In this example, you begin with a full analysis. At this point any solutions are fair game. You are taking into account a full performance solution or organizational development perspective.
The first design and development cycle of the Iterative ADDIE process is very short. You are looking for the most basic wireframe and most important representative samples available. That is, you are looking for a quick prototype. This phase doesn’t go so far as to provide an entire MVP—it only requires enough examples in the wireframe to cultivate an increase in your communication confidence.
Once the basic prototype is delivered, it is time for some communicating. The product can still go in any direction at this point. You and your SME should collaborate to adjust the design. Then another round of development is completed. At this point, your project’s communication confidence should be higher.
The next prototype delivered should be very close to the MVP. The next iteration should be mostly development details. Major directions in design shouldn’t be opened again except in rare circumstances. Finally, the SME or stakeholders sign off on the class.
If you can get target audience feedback, do. (If not, you have to keep going. Unfortunately, in the real world projects can’t stay open in development forever.)
When the pilot course is provided, you should have a completely open mind. You are open to all changes. Next, perform a formal round of design (if necessary) and development edits of all proposed changes; then the project is delivered, signed off on, and officially finished.
Think About This
Create a library of prototype examples.
A shortcut in the rapid prototyping process can be accomplished by showing detailed examples from other courses. You should build a library of examples. This library is essentially a compilation of course components that can be easily referenced. For example, Lauren has a case study she used successfully for a packer course. She is now working on a sensor course. She can show her SME the packer course case study and say, “I want to create this for you.” Lauren is showing the prototype without doing any new work at this point. She can then work to meet expectations with her SME and can find out if this will work even before she lifts a finger for development.
You could even go so far as to build an entire faux class of similar components, get agreement on structure, then start the more in-depth content creation. Certain CCMS systems, or course-building software, that library or catalog different content types can make this quick to accomplish.
Getting It Done
Reconciling ADDIE and Agile is important. There are different strategies to choose, depending upon the dynamics of the project, the assigned SMEs, the training technology used, and your organization’s culture. SME communication is possibly the biggest factor to consider. The higher your C2, the more time you can spend in development using a traditional ADDIE format. The lower your C2, the more you need to rapid prototype. Your C2 will affect how many iterations you need. Use Worksheet 4-1 to estimate your C2.
Worksheet 4-1. SME Communication Confidence and Development Strategy
Answer the following questions to help you analyze your technical training project.
Think about your relationship with your SME. Do you think you have low Communication Confidence or high Communication Confidence? Why?
Based on your answer the previous question, how will you factor this into your development strategy? Sketch out a plan below.