There's much to be learned from IT processes to improve ADDIE's effectiveness in workplace learning and performance projects.
Gone are the days of hand-written overhead transparencies and typewriters. If you are involved in the creation of today's learning and performance solutions, you are using software. Also, chances are that the outputs of the efforts to create those solutions are pieces of software, such as computer-based training modules in a SCORM format for an LMS, bite-sized how-to YouTube podcasts, or printed materials created with word-processing, graphics, and presentation software. As elsewhere in our world, software is ubiquitous in the domain of workplace learning and performance.
So why not bring software development practices to the creation of our learning solutions? We should—and I will provide an overview on how to augment the well-known ADDIE instructional systems design approach with proven practices from the information technology (IT) industry. I call that approach ADDIE+. It's a method to improve learning and performance improvement projects by just thinking of them as if they were software projects.
Every workplace learning and performance professional is familiar with ADDIE (analysis, design, development, implementation, and evaluation). It has been the instructional systems design approach of choice for many years and is part of the ASTD Competency Model, crossing over into multiple areas of expertise, including designing learning, delivering training, human performance improvement (HPI), and measuring and evaluating.
Workplace learning and performance initiatives take many forms besides classical instructor-led training, from coaching to job aids, and on to large blended learning programs consisting of online computer-based training, virtual instructor-led training, and classic instructor-led training approaches. Is ADDIE the best instructional systems design approach for every initiative? It's a pretty good start, and there is much to be learned from the IT industry to improve ADDIE's effectiveness in workplace learning and performance projects.
The table on page 60 shows the obvious parallels between HPI development initiatives and software production. As you'll notice, there are a few 1:1 correlations and enough other similarities to pursue the augmentation of the traditional ADDIE.
Core pieces are missing
Traditional ADDIE is a generic, five-phase process model. It does not differentiate between the needs of small instructional design projects such as a one-time, small, team building workshop and a multiyear effort to design and implement a blended learning program for a sales organization in the tens of thousands, supported by a new LMS. Although the use of rapid prototyping to help provide ongoing feedback to the evaluation portion of the process is a huge improvement, it still leaves ADDIE lacking core pieces of a scalable framework for managing performance improvement projects.
There are five proven practices from the IT world that can transform ADDIE into ADDIE+: a set of guiding principles; a team model; modifications to the traditional ADDIE process; a risk management discipline; and version control.
A set of guiding principles
Sometimes under the umbrella of a "manifesto," guiding principles provide the underlying vision and define the values that will affect making tradeoff decisions. An example of such a guiding principle for a learning solution project would be "Every ADDIE+ project should have a vision statement, agreed upon by all team members, that captures the desired to-be state of the solution." This addition of guiding principles is relevant for any size project.
A team model should clearly define the core functions and the roles and responsibilities of all the parties involved. This includes individuals involved directly or as extended stakeholders who might be affected by the implementation of an HPI initiative.
Such a model determines not only the responsibilities, but also lines of communication among team members. It should show how each team member or stakeholder interacts with others beyond the RASCI (responsible, accountable, supporting, consulted, and informed) table. (RASCI is a standard project management approach to mapping the involvement of project stakeholder roles to the various artifacts and outputs created during the project.)
The core team model proposed here has six major functions, sometimes known as advocacy groups (see figure).
Project management is responsible for managing resources, schedules, specifications, and risks, with the ultimate objective of delivering the solution within the constraints. The project management function will interface with the customer or client and also with stakeholders in the organization who represent other learning programs within which a solution must reside.
Business analysis (often called product management in IT) seeks to determine the requirements for the solution. This group learns these requirements from both the client, who ultimately pays for the solution and gleans the benefits, and the people who will participate in or will be the recipients of a learning solution.
User experience advocates for the end user to help ensure that the solution is right for the participants or recipients, based on descriptions of user profiles and user stories. In addition to working with this audience, the user experience group works with the organization's learning management team to ensure that the solution is marketed, scheduled, and delivered in alignment with existing standards and processes.
Production management (often known in the IT industry as release management) coordinates the merging of the many pieces of the learning solution into multiple versions for review and testing. This function typically coordinates its efforts with the organization's learning management team and with its IT operations (for example, an LMS).
Testing is responsible for proving that the solution does (or does not) meet the documented requirements for functionality, usability, and integration with other systems. Testing will work primarily with the organization's operations staff. In contrast to the traditional ADDIE process model, testing is active during all phases of ADDIE+, building test plans and cases before development begins in earnest.
Development is a somewhat special case, in that this function is isolated from the organization's stakeholders and also from the core team's testing group. Development is responsible for delivering pieces of the solution based on the design or specification, and will work most closely with the core team's user experience, production management, and project management functions.
Not every learning and performance project needs six functions or even six people. In a small project, one person might take on multiple roles, as long as the functions that person represents are not at odds with each other. Perhaps the most important point here is the isolation of development and testing functions. Developers should be doing their own basic ("unit") testing, but testers, should be trying to "break" the solution put together by the developers, reflecting the results back to them for resolution.
Modifications to the traditional ADDIE process cycle
This includes regular, internal releases of the solution to the core team and key stakeholders and an explicitly scheduled stabilize phase at the conclusion of development. The internal releases keep the project moving and on track, allowing others on the extended team to see the progress, make comments, or flag issues. When the functionality of the solution is complete, stabilization begins and the development function works only to fix issues in the solution, in preparation for implementation.
Risk management discipline
A risk management discipline tracks the potential issues that might affect project success. Risks come in all sizes and shapes: unreasonable client expectations, organizational change, sudden budgetary constraints, use of new technology, or team resources who are approaching an unfamiliar project.
A risk management discipline helps to identify and mitigate potential issues, and creates contingency plans for situations in which the consequences of a risk cannot be avoided. Although this is most applicable to large projects, it's helpful to consider risk even for small ones. Risk management is a continuous process in ADDIE+.
Version control of the learning solution's raw components should be implemented to avoid the confusion and rework that could result from a team's inability to identify and organize the right set of files needed to produce and deliver the solution. This can start with something as simple as a standard file-naming convention, one that includes the type of component, title, date, and initials that identify who last modified the file (for example, "Handout_Scenario1_04_12-2012_RMS").
Better yet is a centralized file repository that can lock a file for use by a single person ("check out") until completed ("check in") and that can revert to a previous version of a file ("roll back"). Such capabilities are provided by some LCMSs, by products such as Microsoft's SharePoint 2010 and to a lesser extent by some free cloud computing services such as Google Docs and Microsoft SkyDrive. Version control should be put in place no later than the conclusion of the design phase, when the number of files begins to grow quickly.
Along with the addition of these five core components to the ADDIE approach, workplace learning and performance professionals also can take advantage of some features of the newer software development environments and processes such as content libraries, reusable component repositories, and standard system interfaces.
Improving project outcomes
Today, the creation of learning and performance solutions is dependent on software tools and delivery mechanisms, and it bears too much similarity to the IT industry, especially software development, to ignore.
If you have friends, family members, or colleagues who work in these areas, ask them about their project management practices. Then, experiment with one or two of the ADDIE+ additions mentioned here. You might be surprised by how quickly you can improve the outcomes of a project by looking at the outputs as software and organizing the project as does a modern software development team.