"ISD - Instructional Systems Design and ADDIE - Analysis/ Design/ Development/ Implementation/ Evaluation" are common acronyms and phrases for many readers of this Blog, I suspect. For all others: "sorry."
Here we are focused on Performance Competence. By design. Which I define as: "The ability to perform Tasks, to produce Outputs, to Stakeholder Requriements. That involves ISD but also HPT and many other TLAs (three letter acronyms).
Video link of Guy providing his background in HPT - Human Performance Technology.
Not all Clients or our own upper level management appreciates the need to really focus on performance results of the learners/attendees in the training that they envision when they come to you with their request. And that ISD/Learning is only part of the Performance Equation.
Many of you may sympathize.
One of my clients sent me an email one day a few months back that I converted into a Blog Posting and a couple of graphics. Here is the first of Big Dog's (what his coaching of teen-ager sports teams moniker was) visuals:
Big Dog is also often forced into DevelopQuick-ImplementQuick-Get Your Head Ripped OffQuick.
There is no time for analysis or design - jump right into development, implement it and maybe evaluate it. Well, you can't help but hear the feedback, usually somewhat negative feedback - so we'll call that evaluation.
Analysis? Analysis paralysis? Not even close! There is not itme for that - just start creating!
Then he is often forced to "merge" existing, redundant sets of content - for which he generated a new acronym...
Of course EVERYONE hates (can I think of/write a stronger more appropriate sentiment that most Clients have?) anything more than "Analysis Paralysis" -
Most Clients have probably experienced some ISDers "analysis" efforts in their past. And many of them found the results of little value. Analysis data that takes a long time to generate and that doesn't really tell them anything new, or believable, is avoided in future opportunities to do analysis or not.
If it takes 90 days to come back to report out to the Client things that they already knew, or worse, exactly what they told you on day 1 - then they are pretty frustrated. If they don't see exactly how that analysis data then became useful in design/development - well, you've unsold them on analysis. From there on out....
End of the Preamble
OK - the overall goal of this post (others to follow) is to do a fly-by of MCD of the PACT Processes - analysis data informs (formally) the development/acquisition of content (instruction and/or information) where we "deliberately" convert the "analysis data" into "design specifications" - per the following graphic...
The PACT Processes and RADD Processes
In PACT the ADDIE (Analysis-Design-Development-Implementation-Evaluation) model is "operationalized" in 6 phases per the following model:
While the six phases, my adaptation on ADDIE, may look like a bunch of hoops to jump through that would slow any project down, the opposite is true.
As an organizer of activities leading to worthy outputs the six phases are adaptable. I often combine phases - which really means that I often combine activities to serve more than one purpose. I've run meetings with SMEs and Master Performers that addressed both analysis and then went straight into design.
After that the Analysis/Design Team members became Development Team members and started creating the content that we had just designed from their own analysis data.
When you really understand the PACT methods you can adapt them to the specific requirements/constraints of your Client's situation. And while that typically increases RISK, it can be mitigated by involving the right people AND employing a good enough process.
PACT itself is an acronym (an: FLA versus a TLA; 4 versus 3)
PACT is also "so fast" that we've created the RADD model and abbreviated" our quicker/managed risk version of PACT:
RADD is true to "full" PACT - and is a short-cutted process, abbreviated "by design" - where "development" is informed "by design" which itself is influenced "by analysis" - because it's still PACT.
I developed RADD to accommodate requirements for very quick turn-around ADDIE-level ISD projects. And because I was put off by many "Rapid" methods that are mostly about some "tool" and often jumped into development with maybe a passing attempt at defining Learning Objectives. If you are going to need to go fast, go smart as well.
My questions about Learning Objectives are: what informed them? and- what was the process used to insure that they are relevant to the learners performance?
Faster - It's Alright
Need to go fast, very fast? I can go very fast post-CAD.
A lot of work has already been done to segment and sequence the content (the T&D Path and Event/Module Specs), articulate terminal performance objectives (in the Performance Model), determine all of the enabling knowledge/skills (in the K/S Matrices).
I can even go faster if I am not building traditional training and I am building items that seem more Knowledge Management in nature. PACT addresses Training & Development - Learning - Knowledge Management - using 3 sets, 3 levels of instructional design methods...
The Learning Curve Ahead - The PACT Methods
PACT is 5 sets-of-ISD-methodologies...
PACT has three levels of ISD effort/project types: CAD and MCD and IAD.
MCD has three levels of design: Event-Lesson-Instructional Activity.
All design effort types and design outputs of PACT are fed by a common set of analysis data and are "planned for" and "managed to plan" using a common set of approaches and tools/templates.
So now we are transitioning from CAD to MCD - with this Blog Posting - many Blog Posting prior to this one focused on various aspects of the CAD level of ISD of the PACT Processes.
MCD can follow a CAD effort - or begin without a prior CAD effort.
MCD is the ADDIE-level of PACT...
It is accomplished in 6 Phases - or combinations of those 6 phases - and per 5 of the six phases - various outputs are produced - for review/management by the PST - Project Steering Team...
Project Documentation
First there should be a documented (versus mental/conceptual) Project Plan...
That should be reviewed and approved by the Client and all other Stakeholders. I have that group "hand pick" the Master Performers and Subject Matter Experts that I'll work with. Hopefully the project is to employ the "collaborative approach" versus the "traditional approach." Collaborative meaning we'll do much of our ISD work as a team effort. Otherwise, traditionally, I would work with people one at a time.
I prefer doing analysis (most of it anyway) in a group forum. In an Analysis Meeting with a structured rational agenda and processes. That's what PACT Analysis is all about.
Then using that analysis data as input to the design process...produces a design...
Which leads to development and pilot-testing...
Which leads to Revision-and-Release - the final phase of MCD of PACT - and the project is closed out - which leads less to "Lessons Learned" documents than to "lessons learned and applied" ----
The main focus of PACT as a process/methodology-set: is on performance-based content that enables PERFORMANCE COMPETENCE.
In MCD - the ADDIE level of PACT - produces 3 levels of design - informed by analysis data - that addresses "performance requirements" -
The Event Map
Event "Maps" pictorially display Lessons. It is intended to be visual - as in presenting the big picture. Then we peal back the onion, so to speak...
The Lesson Map
Lesson Maps "pictorially" display the next level down "object" in the design hierarchy of PACT: Instructional Activities.
Sometimes a Lesson map becomes a "cloner" - one that we use as a "master pattern" for content, such as for a series of product knowledge, tool knowledge, process knowledge, etc. Where a pattern used by the designers and then developers actually makes it much better for the learners and their performance.
It's the "Configuration of Content" issue - and issue usually because it is somwhat, but not totally, arbitrary. Many varied configurations of content would work (many more would not) - so it becomes a matter of personal preference - which makes it problematic to resolve.
A PACT MCD Designer is a facilitator who should be prepared to employ successful strategies and tactics to facilitate a group of high-ego Master Performers and Subject Matter Experts over rough terrain.
The Instructional Activity Specification
Instructional Activities are the lowest level, the third level of design (Event-Lesson-Instructional Activity) in PACT's MCD. Back in CAD the Lesson level was the Module level. When going from CAD to MCD I found it helpful to have a little wiggle room to change the configuration of content a bit or a lot once we were taking a deeper, serious dive - and now really intended to build/buy some content.
When we were doing CAD we were simply determining our total performance-based needs, and rationalizing all of the existing content into a sequence (Path) and identifying the gaps. CAD projects don't produce any new training/learning/knowledge management content. CAD projects give you a blue print for what you've got and what are gaps. For business-drive priority setting and resourcing as appropriate to the needs of the business.
But now we are deliberately intending to produce new content (or maintain existing content). And the Instructional Activity is my last object level - in an object oriented approach to instructional design.
In my collaborative approach using teams, the Instructional Activity Spec is produced in the back of the room by one MCD Designer (or level 2) while the MCD Designer (a level 3 or better) facilitates the creation of the Lesson Maps. As each "box" on the Lesson Map is placed and discussed, the eprson in the back of the room is capturing more of the words flying about the room than the facilitator in the front at the flip chart easel.
The Instructional Activity Specification...a.k.a.: the Activity Spec.
Notes on Maps and Specs
In PACT I use Maps and Specs. Maps are more visual - and Specs are more wordy, more detailed/the place for the details.
I would normally show a Client the Map first - and then the Spec. And I would ideally enable them to see them side-by-side - because in my experience THAT is powerful. Think of taking your reviewers from Event to Lessons and then to Instructional Activities, in an ability to get a look and feel for the design - before expensive development activities begin.
And it helps to show them prototypes of development phase outputs for approval before use - using storyboards and mock ups. Here having standard templates for outputs and guidance about level of detail, tone, tense are extremely important to the learners. It doesn't matter exactly which of many good-enough organization schemes you use, a long as you are consistent.
That's what the learners, the customers, need from you, their supplier. Consistency! Patterns of words and graphics that are used consistently and enable them to "find quicker" whatever it is that they needed - because they had the code - the decoder ring - the keys - because they eventually learned the scheme we used. That's why an 'architectural" scheme for the content configurations is critical as well as having and using a set of templates for all deliverables. But doing this involves a lot of arbitrary decision-making. For an individual or a group. Or it is shared.
In CAD level projects there are Event Specs which become Event Maps in MCD. A CAD's Module Specs become an MCD's Lesson Maps. These design patterns/templates (Maps and Specs) later facilitate creating the consistent patterns of content - and by consistent I mean 80-90 % consistency. Not 100%. Not perfect. Not even six sigma - which predicts 4 errors in one million opportunities for success or failure.
I could produce a Map for the Instructional Activity - but I've never found it useful.
I could and have done a Lesson Spec for every Lesson Map - where the Spec wording went into "course descriptions" in the course catalog - sometimes in booklet form and/or almost always in an electronic (LMS, etc.) form. So there is utility for a Lesson Spec. But in truth the content for a course description (or whatever end purpose) could always be easily derived/informed by the content of both the Lesson Maps and the Instrictional Activity Specs later. If you are definitely set up to use Lesson Spec data - then do them. If you aren't set up for suing them - don't.
Just because you can doesn't mean you should.
Resources
Here are three books that address some of my approaches and thinking on ISD...
Available from ISPI http://www.ispi.org/
My chapter in the Handbook of Human Performance Technology (Chapter 11) is focused on Analysis for ISD and Analysis for HPT (EPPI in my world). HPT is the umbrella to ISD in my view, and therefore my EPPI methodology-set is the umbrella to PACT. The book is from Wiley.
And of course the focus of lean-ISD is the PACT Processes for T&D/ Learning/ Knowledge Management. It is available as a hardbound book (via Amazon or me for $75.00) and as a Kindle book ($7.99) and for free as a PDF at http://www.eppic.biz/
The EPPIC web site contains over 100 references and resources on the PACT and EPPI methods, tools and techniques. Including 4 of my books as free PDFs.
This Blog Posting Series will continue with more about MCD in the PACT methodology-set. It will then lead to Program and Project Management and then to Portfolio Management and Governance/Advisory Systems.
# # #
0 comments:
Post a Comment