Another poke at ADDIE

Yesterday I outlined and critiqued the ADDIE approach to Instructional Systems Design, in particular pointing out the process management aspects that I believe are missing from ADDIE. Today I'm blogging about creative approaches to address some of ADDIE's other limitations.

ADDIE's similarity to the traditional waterfall software development process suggests the possibility of applying other development methods e.g.: 

• Rapid Application Development is a cluster of methods mostly based around the concept of reducing the cycle time, delivering a rapid succession of relatively small changes or 'iterations' rather than the usual step-release approach with distinct new versions released every few months or years. In the ISD context, this might mean delivering training courses and awareness sessions that are maybe not as polished as they might have been, but are bang up to date with current thinking - trading spit-n-polish for cutting-edge thinking. In a sense this is what we are doing through the awareness service, replacing the once-a-year massive awareness event with a series of smaller, bite-sized training and awareness sessions.
• Modular development breaks a system into pieces that can be prepared then assembled into the finished product. It is handy if the modules are discrete and independent, but more likely they are designed to interface to and support each other, for example 'plugging in' to some sort of backplane providing a suite of common functions plus the internal communications and coordination needed to make the whole system play. Again, our approach  is modular with a fresh batch of content delivered every month, where the backplane comprises the core concepts underpinning information risk and security as a whole - things such as threats, vulnerabilities, impacts, governance, control, resilience, assurance, trustworthiness and more. 'Authentication', for instance, is a control concept that applies and hence gets mentioned in a variety of topics, ranging from system/network login and phishing to physical access.
• End user computing or desktop development is about giving workers the tools and skills to create their own software - although it is not usually expressed in those terms. Common examples are spreadsheets and macros. In the security awareness context, this involves providing ready access to relevant information, such as a 'corporate university' or, at least, an intranet website with security policies, procedures and supporting information that workers can peruse at their leisure. We stress the social side of security awareness, putting people in learning situations where they establish relationships with each other and with the trainer/leader of a session (hopefully having a good laugh in the process!), and then extend that further by encouraging staff, managers and professionals to interact in other business situations around the same monthly topics.
• Test-first development involves first clarifying the acceptance test specifications, in detail, before designing and building an IT system with the obvious intention that it will pass its tests and hence be accepted. In the awareness and training context, that might equate to clarifying the objectives of awareness and training first, being crystal clear about the expected outcomes and then designing, developing and delivering the awareness and training to achieve them. In both cases things are seldom as straightforward as the method implies but I admit to being intrigued by this approach - specifically because it gets directly to the nitty-gritty of "What are we trying to achieve here? Why are we doing this? What would success look like?", all excellent questions. Test-first tries to make those rhetorical questions more concrete, an admirable aim but still tough. I like the fact that test-first enables the design/selection of better metrics, which in turn help drive maximum value from the process.
• DevOps vaguely resembles a souped-up heavily-automated version of RAD. For security awareness and training, tools are certainly helpful to facilitate and speed up the development of new materials, although I would argue that the people wielding the tools are more important than the tools themselves. I've seen fancy Learning Management Systems with all the bells and whistles serving up poor quality, outdated and badly conceived content - a real waste of potential and timewaster for the poor audience.

I could go on but that's enough blabber for today. Along with yesterday's piece about ADDIE, I hope I've set you thinking about different ways to design and develop security awareness and training content. If you like I'll explore the delivery aspects too at some point. Comment below or email me. Go ahead, twist my arm.