SyberWorks e-Learning Podcast #22: Interview with Guy Wallace about his e-Book, "T&D Systems View"

-from:
SyberWorks e-Learning Podcast #22: Interview with Guy Wallace about his e-Book, "T&D Systems View"
By Dave Boggs on SyberWorks e-Learning Podcast Series

Here is our latest press release and e-Learning Series podcast:



Press Release:
SyberWorks e-Learning Podcasts: Episode #22: Interview with Guy Wallace about his e-Book, "T&D Systems View"


Podcast:

Episode 22: Interview with Guy Wallace about his e-Book, "T&D Systems View"



Dave Boggs, CEO of SyberWorks, states, “Today’s podcast is an interview with Guy Wallace, Certified Performance Technologist and the President of EPPIC, Inc.

Guy has written an e-Book, ‘T&D Systems View,’ which presents a structured method for managing the learning/training function from a systems and process perspective."

SyberWorks e-Learning Podcast Transcript #22
















******************************
this is about my 2002 book:
T&D Systems View - which I made available in 2007 as a free PDF at http://www.eppic.biz/

# # #

PACT Project Planning Overview - for CAD Projects, MCD Projects and IAD Projetcs

The saying is: Necessity is the Mother of Invention.

My philosophy about, approach to, and tool-set for ISD Project Planning was borne of the necessity to insure that my team of consultants were planning and PRICING and conducting our Client/Customer project efforts to both insure that the Project Customers/Project Stakeholders were all very satisfied - and that our "project profit margin" (the differences between what we spent to jet the job done - and what we got paid) was within goals set to both carry the fixed costs of our business and generate money for raises, bonuses and other forms of recognition/rewards, etc.

So it was necessary to "get 'er done."

Iterative Versus Lean
I have a great deal of difficulty with those who write and speak of the necessity of looking at and practicing ISD - Instructional Systems Design - as "ITERATIVE." Yes it can be thought of and practiced that way - but who would want to?

Who would want to live in a "planned approach" to "LIVING IN REWORK CITY" endlessly reworking what you had previously reworked. Those are the earmarks of a project out of control because it is not in enough control. Here is an earlier Blog Posting on that.

I've been writing and presenting professionally on this aspect of ISD since the early 1980s - here is an earlier Blog Posting on that.

Common Systems/ Processes/ Tools & Templates
So I and my staff consultants and production specialists created, over the years, a uniform system, set of processes, tools/templates and maintained a library of examples of every tools/template put to real-world use.

I was the "chief architect" for all of that. It was my vision and my need for enough control - all due to my need for enough predictability. Due to my need for enough profitability.

I needed it to be "as rigorous as required and as flexible as feasible" to better meld with my varied Client's specific realities, their specific performance contexts.

We used standard labels and descriptions for our "service offerings." Those were CAD, MCD and IAD, plus other non-PACT services my consulting firms (1982-2007) offered and performed.

We used standard/common Phases for each type of service rendering project. CAD has 4 Phases and MCD and IAD each share the same 6-Phase model - that makes sense once you understand the nuanced nature of IAD and MCD as project-types.

We used a common set of terms and data-gathering templates and document/report templates all across the 3 types of ISD effort of CAD and MCD and IAD. We even had standard meeting invitation letters --- this all goes back much earlier than email - so later and now today someone would "cut and paste" from our invitation or confirmation or thank you for attending letter template to their email system - and would edit/personalize from there - before hitting "send."

PPM - PACT Project Manager
Here we will focus on the Project Planning set of methodologies within PACT. So this is really for the person/team with Project Planning and Project Management responsibilities. In PACT, that is the PPM - PACT Project Manager. That is one of 5 key "roles" on the PACT "Supply-side Team" who works with a PACT "Customer-side Team" with similarly defined project roles.

Note: one person may play all 5 roles, or they may be divided up across two to 20 individuals, project size/scope depending. Based on my experiences.

Typically the PACT Processes for T&D/ Learning/ Knowledge Management projects' efforts center around "reviewing data" and "generating data" and "reviewing data" and then repeating that cycle of effort through the Phases of the project; typically a new group takes on the next cycle before giving it back to some sort of "project management/client governance" group/individual.

So it's the goal of the Project Planner-side of the PPM role, to plan using that cycle, and reflect it in the tasks and timing of the plan.

And they get a lot of help in that I had in "The WELL" a set of toolkit-of-templates for a CAD project and an MCD project and an IAD project, etc. - that they would simply "copy over and paste" onto their desktop (or wherever) and rename that file by our Project numbering and naming conventions. Now they had a project file ready to go.

One of the first, but certainly not the first tool in the tool kit is the CAD Project Plan. Before that came an Interview Guide and "Client Collateral" - leave behinds - marketing/communications tools.

Some of these could be edited to be more project specific, others did not need to be edited. The balance is probably that 80% of the tools in the tool kit would need purposeful editing - and that's a good thing! To flex to the specifics of your Client's situation and stay the course of the process to maintain enough control and predictability.



















Click on any graphic to enlarge/copy/etc.

Standard Tools/Templates for Use "As Is" or "After Modification"
We had standard covers, t-o-c's (Tables of Content) that organized all of the contents. And we had the "starter set" of content for each Project Plan template. One each for CAD, MCD and IAD.





















So the template Project Plan offers a lot of boilerplate text and graphics. Some of that text needs to be edited to be specific to THIS/YOUR project - while others are germane to this project due to it being a CAD or MCD or IAD effort.

Sometimes, rarely but still a "need" of the system put into place - standard graphics within the Project Plan might need to be adjusted/adapted.

My staff would then go to "The WELL" - an online repository of all of our piece parts of content - organized in a logical scheme that everyone could soon learn to use - and they would grab the original PowerPoint source of the original graphic - and create a derivative - whatever was needed - and then turn that into a j-peg file (or whatever) and then use the new graphic in place of the old.

The WELL now contains the original and all of the derivatives - all located in the same general space in cyberspace - which means having an inventory system/menu of links of all of your combined "stuff" that is logical and sustainable/robust to future growth and evolution of both its content topics and types.

Tasks/Roles/Schedules
Here is an example page from "section 8" of the detailed tasks/roles/schedules for the project. Normally in a CAD project there might be 7-8 pages of these charts for the full 4-Phases of CAD.
















A set of these "task/roles/schedule" charts for an MCD project might number 10-12. If your task plan is to have all of the tasks that will actually be performed (and take someones time and attention) this will help you get there.

The appendices of "lean-ISD" include: a-Tasks for a CAD Project, and b: Tasks for an MCD/IAD Project. This is the detailed list of tasks that can be edited down for a specific project effort. One needs to edit that down, reword, embellish, to reflect the specific situation and needs for this specific project.

This all leads me, in this "Overview" Posting on Project Planning, to Development Ratios.

Development Ratios
You know, the 40:1 or 36:1 or 400:1 "ratios" that help folks "ball park" the costs for producing an instructional product in the early stages of project conception - before a detailed plan is created.

I've always had a skeptical view of Development Ratios - as I'm pretty sure from the conversations I've had with many Clients who used them - sometimes against their own better judgement - that they are inconsistent in terms of who's effort they capture/project - who's do they not capture, when did the meter start and stop running on counting time, and did it capture other costs beside "time" of a certain group of individuals.

So I think it is important to have a set of your own "development ration's" that serve your purpose - but don't compare your apples to others' walnuts. Use your apples to serve your process needs and let others' walnuts serve their needs - but just because they are "kinda-alike" doesn't make any comparison meaningful.

















The tool above is one that guided my data tracking efforts for many, many years for many, many projects, for many, many PPMs - PACT Project Managers doing their Project Planning and then Project Management thing.

After 25 years of tracking actuals-to-plan on almost 500 projects at my 3 consulting firms (1982-2007), I feel that I have a pretty good feel - shaped over many years - of how to think about both "touch time" and "cycle time" in projects - IF I get a good sense of the culture/style of the people that I or my staff consultants will be working with.

When in doubt - recognize that as "Murphy" and plan accordingly - meaning: add time to the task and cycle time estimates. Not to "pad" - but to "get real."

Murphy as in: "Murphy's Law" - as in: "if anything can go wrong it probably will" - is real. Plan accordingly!

Many other tools/templates exist in the full PACT Practitioner Toolkit. See the mention below of a wiki for PACT that is your source for such tools/templates.

Much of this, but not all, is covered in my book: lean-ISD...





















lean-ISD is available as a hardbound book ($75 at Amazon), a free 404-page PDF at http://www.eppic.biz/ , and a Kindle book ($7.99 at Amazon).

Plus a complete set of tools for CAD efforts are now available for free at the...

The PACT Wiki

From the PACT Wiki...

The PACT Wiki - Home Page - Welcome visitors! This Wiki is under "continuous construction" by the author and owner of the PACT Processes, Guy W. Wallace, CPT and President of EPPIC Inc.

This Wiki was first published on October 26, 2007 - It is intended as a resource and resource guide for all PACT Practitioners adopting and adapting the "starter-set" of PACT concepts, models, methods, tools and techniques - as well as those of RADD = Rapid Analysis Design Development, plus the related T&D Systems View and Management Areas of Performance, and EPPI - Enterprise Process Performance Improvement.

Check here for What has yet to be initially addressed in this Wiki.The intent of this Wiki is to enable and empower PACT Practitioners globally. Additional PACT Wiki "authors" may be added over time. See the Pursuing Performance Blog for related Posts. Please attribute appropriately - even the derivatives!!!

And - while this Wiki is generally not open to anyone and everyone to author and edit - The PACT Wiki 2 is!!! Except for the Home Page which is locked - PACT Wiki 2 is for all to author/edit - to share! This entire Wiki is locked to all but the designated authors/editors.

# # #

Rapid PACT? Even Faster? And Still True to PACT?

I've written in a prior Post on this Blog extensively about RADD -my PACT Processes done even more rapidly...

Wednesday, November 28, 2007

A RADDical Approach - Avoid Development without Design and Analysis

# # #

MCD - The Long and The Short Of It

MCD is the ADDIE-level of the PACT Processes for T&D/ Learning/ Knowledge Management. MCD = Modular Curriculum Development/Acquisition.

The MCD "Process" is modified to fit the situational requirements/constraints of each effort. One size does not fit all!!! Or- at least not too many in a row. Sometimes you do get lucky - and have two or more projects precede in a similar, common, logical manner!

MCD Projects Background
MCD has been applied to little and large projects in my own personal experience. I have 50 MCD projects under my belt (and 74 CAD projects), 1982-2007.

Before MCD (it was in 1991 that I created the ISD process that later became labeled MCD on a Labor Relations Project for Illinois Bell New Supervisors Program) I had done dozens and dozens of ISD projects for Wickes Lumber (1979-1981), Motorola (1981-1982), each using a Performance Model chart format to gather data mostly via "traditional" one-on-one interview and performer observations.

But in 1980 I began to use a "collaborative" approach with teams of carefully selected people whom I would take down a process path to logically get from where we were staring from to wherever we had planned to get, discussion and data generation-wise that is. Then I got to do more and more projects using that approach because of the shortened cycle time and the Client control aspects, even if it did shift more time/effort burden to the Master Performers and Subject Matter Experts - but even that was under pretty tight control so that it could get done in the alloted time frames.

Bigger MCD Project
I did the MCD Designer Role for a larger ISD project that produced 9 months of content to be delivered over 18 months: one week in class and the next on-the-job. Many "labs" and "guided tours" interspersed with "classroom lectures and videos/etc." We had done a CAD project prior and because of that went right from Phase 4 of CAD where the Project Plan for MCD was created - to Phase 3 of the MCD project. And the effort was planned from day 1 (in Phase 1 of the CAD) to go like that. CAD: P1-P2-P3-P4-MCD: P3-P4-P5-P6.

That was for General Motors and their Metal Fabrication Division's program for new supervisors of UAW workers. Other GM contractors being taught the PACT Processes (there known as MC/MI) took the designs I produced with the assembled Design Team and ran off (figuratively most of the time) to start producing the content as designers/developers. We were 2-3 weeks ahead of the delivery when we started the project. And by the time we got to design leading to development we had half that time.

We did an analysis with a designated Analysis Team and produced AoPs and Performance Model charts data - and enabling K/S data on the K/S Matrices. In the analysis portion (CAD) we had used my Management AoPs (Areas of Performance) framework to initially frame our analysis efforts and provide an advanced organizer to all involved how we were going to do a WBS - Work Breakdown Structure (a concept familiar to all in engineering and manufacturing circles).

Then we began the design series in the MCD portion. There I was demonstrating to those GM ISD Contractors already through my MCD Designer 5-Day Workshop with me or another facilitator - on how I really did a real project in real time. So I showed them how I took groups of K/S Items from one category of the K/S Categories listed on the K/S Matrices and with the observation and guidance from my assembled Design Team, created "one design pattern" for a group of K/S Items - for adapting further with specific content immediately afterwards. We raced through an incredible amount of micro-designing of many enabling K/S Items due to our use of the "patterns" - or what I now refer to as "Content Configurations" or "Configurations of Content."

They, the ISDers eventually "got it." What surprised me at first was how quickly my Design Team members - who critiqued my designing out loud and in full view of them - as we went as they should. So we could make instant corrections of my ISD ideas and thinking. Or they would question rather than challenge what I was doing in front of them, explaining my thinking out loud to them. I was always doing feasibility and reality testing with my DT members. A little different experience for them from their role in the AT - Analysis Team meeting of the CAD effort.

Of course, my Design Team members, being Master Performers and Supervisors and Union Stewards quickly got my references to patterns and templates. They were tool and die folks. Where patterns and templates may have originally come from for all I know. These are the folks who turned plow shares into swords and vice versa back in the day thousands of years ago, local politics depending.

The 18 Month New-Hire Program was a great success per satisfaction surveys done (L1), retention rates, performance ratings (L3?), etc. The project won a Chairman's Quality Award for and because of our team - and, I believe - because of the process we employed.

MCD Templates
These are the 3 key MCD pattern creating templates from a design perspective - versus analysis, development, pilot-testing perspectives.

The Event Map of Lessons...














And just a a map of any country is really a map of the next layer down - for the US it is states - for Canada it is provinces, etc.

Then comes the next map...the Lesson Map of Instructional Activities...




















Then the third template is not a map, but is spec - for Specification - the Instructional Activity Spec...




















MCD Smaller Project
My experience with MCD, always as an external consultant, has been mostly for very critical, high risk, high reward situations for my clients. Not for low hanging fruit type projects/deliverables. Not small courses/modules. Nothing shorter than 3 days, or the CBT/WBT equivalent of 3 days - lots of WBT Modules!

So a small project for me may be a larger project for others who now-a-days are use to working on bite-sized chunks of content, small modules, which use to be defined as 2 hour modules. I have never been in to work on anything close to a 2-hour Module. I've been brought in to help with dozens and dozens of 2-Hour Modules in a project that took on many modules versus one.

But if that is how my client situation was...then I still know what I'd do...I'd do some heavy skipping of the formality of PACT's MCD processes, short-cutting all over the place IF I could mitigate the many risks that I was now causing by my skipping important steps.

I can do that because I see it less that the step is important as the quality of the data that was going to be produced by that step. That step was one of many means to the end: the data.

If I walked into a Client's office and they switched gears on me from the intended agenda to describing a training need that they want our (my teams') help on...I would not "ask them how they know it's a training need" - a challenge to their smarts - I'd do what Joe Harless taught many to do - I'd say "sure we can help you!!! Let's do a little analysis first!" - and then I'd dive straight into some level of PACT data gathering, usually starting with data gathering in the order of the full PACT Process for Project Planning, Analysis and then heading into the design steps - right in front of their very eyes.

IF I was with a decision maker and a very knowledgeable person about the "performance context" for the learner or learners...

I'd ask them about the expected size, how it would be deployed, and what their deadline was for having it available. Then I'd clarify if this was intended to create Awareness, Knowledge, or Skills and actual job performance capabilities.

Then I'd ask about the Target Audience and what we can assume or not about them in terms of prior/existing knowledge and skills and capabilities. Then I try to create an AoP framework with that Client or Client reps. Then I ask about the outputs/measures for each AoP - and the tasks associated with every output. Then I ask about the enabling K/Ss. I use my familiarity with each of the 17 categories to systematically run my Client through each to tease out any needed enabling K/S to support the Performance goals (or Knowledge/or Awareness goals).

Then I'd take my notes on paper or notes on their whiteboard/flip chart and begin drawing out and discussing with them live an Event Map...then the Lesson Maps...and then the actual or equivalent of the Activity Specs - which is an output I might complete later - after this quick meeting covering Project Planning & Kick-Off, Analysis and Design. But I'd cover the fields of the more critical Lesson's Instructional Activities and get that straight.

Then it needs to be built - perhaps in the initially thought of Deployment means - perhaps not. Perhaps another means of Deployment was/were determined along the way to being better suited to the tasks and/or topics being addressed/taught/learned. And hopefully: applied with success back on the job!!!

Meeting Time Elapsed: 30 to 60 minutes.

Then On To Development/Pilot-Test/Revision & Release
Then on to Development - everyone armed with the game plan, the blueprint, the development output templates needed (available prior or created for this project) to speed development using whatever authoring tool/tools available, to an agreed upon, well understood DESIGN! That is also performance-based.

If I knew my Client/Clients were going to want to talk about that ISD project - I'd have brought a Developer from my staff with me to pick up the ball after that first meeting and to run to it. Now I have to have a "transition meeting" to hand this off to them - and that is where the first major risk occurs. To be managed carefully - unless the drill we've been through with this client was not for critical content - but just some favorite content.

But if that developer had been with me I'd have had our entire meeting continue and next shift into outlining the content futher and identifying/agreeing to whom shall be involved in which piece of this, identifying all of the resources available and prioritizing those. Discussing the review cycle and plan. Agreeing on more specific deliverables and their unique content specificity as well.

I proceed from this point adapting to what I believe about that assessment of the criticality of this effort - compared to all others ongoing or incoming - and trying to keep that assessment evergreen. My success and the success of my teams depend on that.

See lean-ISD for more on this topic...




















lean-ISD is available from me as a free PDF at http://www.eppic.biz/

# # #

The ADDIE Level of PACT: MCD: Modular Curriculum Development/Acquisition

"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 there should be an "Analysis Report" be produced...



















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.

Any one Instructional Activity can be "tagged" as either awareness, knowledge or skill - and - information, demonstration, or application. All Instructional Activities are eventually tagged this way per the Activity Spec, in PACT.





















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.

# # #

Getting Ready to Transition From CAD to MCD

We are now getting ready to transition...from CAD to MCD...per the rough outline on the whiteboard at my side, computer-at my front. I've been covering the CAD level of ISD in the PACT Processes...a set of 5 ISD Methodologies...for the past dozen Postings or so...















PACT - where our analysis efforts end up in the design details, so as not to waste any analysis time and effort and cost...and our designs and content are organized to minimize overlaps and gaps and to facilitate content sharing with other target audiences other than the Primary Target Audience...













PACT - where CADs lead to multiple MCD/IAD efforts over time...as architectural design leads to actual building construction and systems engineering leads to product development...as priorities and resourcing drive/allow.















Covered in this Blog and this book...




















lean-ISD is available as a free PDF at http://www.eppic.biz/

Any questions/ comments/ concerns any reader would like to have addressed before the transition???
Please use this forum versus sending me a personal email as many of you tend to do...or you'll need to agree to allow me to publish your email on this Blog - if I do answer/explain to your email request.

Cool? Agreed? Cool!!!


# # #

Around the Block on CAD Efforts Over the Years A Few Times

My first CAD effort was done during the summer of 1982. For Exxon. I came into the effort after the analysis had been completed. I had been doing mini-Currciulum Architectures, not yet for a whole job, on-boarding through on-going development. This was for two job titles operating in 7 differing environments. Challenging and successful.

I began writing a book on the methodology in 1983 when I did my first presentation of CAD at a Chicago Chapter of NSPI (now: ISPI). That book evolved over the years and came out in 1999 as "lean-ISD." I started giving it away as a free PDF in April of 2007.

My most recent CAD projects...you'll notice that I have not done any recently...nor do I expect to do any in the future...I now teach and coach it...so I'll retire on this at 74 formal projects on the record...here are projects from #48 to #74...in "most recent first" order...















Then earlier...#27 through #47...















Then earlier and back to the beginning...the first 26...















Those CAD efforts specifically targeted for Management/Leadership...
















Those CAD efforts for Sales...















This is my context - for my writing about CAD efforts and outputs - as a systems engineering level of Instruction/Information - targeted at improving and sustaining Performance Competence of individuals, processes, functions, and organizations - all for the greater good as well -hopefully!

One thing I learned in doing and managing others doing CAD and MCD and IAD efforts - many times them being done "solo" by one of my staff - or the staff of my clients - is that each Client situation requires some level of flexibility. It is unavoidable. So the ISD processes you employ must be flexible themselves.

Those are a few of the real world "acid tests" for ISD/ISD organization and management and Enterprise Leadership.

# # #

Six Sigma and CAD - Curriculum Architecture Design

One of my last personal CAD efforts, back in 2004, was to address the training & development needs for a global target audience of many job titles in many countries who were involved in a complicated and highly regulated process (by many governments) that had just been through a Six Sigma effort.

The swim-lane Process Maps (BTW- a tool invented by Geary A. Rummler long before it was cumputer enabled) portrayed the process - step by step, role by role - but it didn't detail the "enabling knowledge/skills" needed to do that process performance. Which is needed for instruction.

My client was someone whom I myself had trained/certified back in the early-mid 1990s for one firm; and then I had trained her own staff at another firm in the mid-to-late 1990swhere she was now a manager. She and her peers and then staff had learned the analysis methods and the CAD-level design efforts only. Her two firms had embraced the CAD methodology and then let each of their own staff ISDers do the ADDIE-level effort using whatever ISD approach they personally chose. They did not go for the structured MCD and IAD levels of PACT as a follow-up to CAD.

The only difference I employed on their CAD projects over the years (numbering over 20 projects across the two firms over 12+ years) was to include "Instructional Objectives" on each Mod Spec (T&D Module Specification in the CAD efforts). That was not typical.

My thinking has always been that if we asked the Client about getting most all of the non-Master Performers in the target audience (job title/job family) to the level of performance as documented in the Performance Model - would that do? Yes was ALWAYS their answer.

And so I knew I had already stated the "terminal learning objectives" in the Performance Model, configured a bit differently than the standard "3-part behavioral objective" (given x and y able to do z as measured by a, b and c).

But you could easily construct the objectives from the data right there on each and every page of the Performance Model. But why bother? It was already stated. It would be un-necessary work (rework perhaps?).

PACT is fast because we defer some task until they are really necessary. And if this Module Spec is in an Event Spec that is of low or zero priority - then we wouldn't want to waste our time. This will never be invested in or it will be off in the distance and things might have changed by then. Defer it is my method.

And I also knew that I had the enabling objectives in the tasks statements plus in the lists of enabling K/S Matrices, per the 17 K/S Categories of PACT. So I could accommodate this Clients desire to include the objectives - and it was probably appropriate as they were not going to follow up a CAD with an MCD effort.

Their versions of MCD - Modular Curriculum Development - the ADDIE-level if the PACT Processes for T&D/ Learning/ Knowledge Management - were going to be whatever/however/whenever the individual ISD staff member typically did their ISD efforts for their internal Clients. At least they had a blue print/ T&D Path to follow for "divide and conquer" efforts.

My Client and her team of peers from within her function and her Client's function, wanted to "prove-in" or "prove-out" the use of CAD post-Six Sigma effort. So we followed the 4 Phase approach without any modification (atypical).

After the key activities of Analysis Phase had been completed it was obvious to me that this should have, could have been an MCD - Modular Curriculum Development effort. The body of content and the performance itself was just not that complicated - compared to most CAD efforts.

So a Lesson Learned was that uncovering the scope of the effort better up front could lead to skipping CAD and going straight to MCD - especially as they already knew that they were going to build out all of the content specified due to the high risk/high reward context - the highly regulated by many countries context.

That was the basis for the "R" in their ROI.

I had just accepted their RFP for this CAD effort knowing that this was a very experienced Client - who although promoted several times since first learning, mastering, coaching PACT's CAD analysis, design and project planning methods - and then leading others to do the same with the initial "training" falling to me and my firm's consultants who I also had trained, coached and certified before unleashing them into our firms' Clients' projects.

She, my Client and fellow PACT practitioner of many years, knew her context - and as this was a proof of concept/proof of approach experiment (plus getting real work done) - I accepted her scoping of the effort and produced a Project Plan and Proposal (PP/P) for a CAD effort. To speed the process and keep costs low. I did this for fixed fee - as a CAD effort is very predicatable in terms of tasks and time - my tasks and time - as well as my Clients.

The effort took 8 weeks...two weeks per each of the 4 Phases of CAD. Mostly to accomodate everyone's schedules - the other efforts of their indivdual jobs - the project could have been conducted in 8-to-10 consecutive days if real speed was the ultimate driver.

But most CAD efforts take 3-4 months. And that again is usually the result of finding common time across all of our PST members - or as often happens - they rearrange other meetings to acoomodate the team scheduling needs of this effort - because they see value in it. As you'll see - they decide as a group to continue the effort or to kill the effort.

Phase 1 - Project Planning & Kick-Off
After initial interviews, a draft PP/P was produced and then reviewed at the 1st of 4 Project Steering Team Gate Review Meetings. That's 4 PST GRMs in PACT-speak. Check out the lead graphic. Click on it to enlarge and/or copy for your files.

The PST is told up front in GRM #1 that at the end of the meeting - which is a briefing on the PP - that they will do two things - they will kill, defer, modify or approve the PP - and then after that if the project isn't killed, they identify/handpick the Master Performers (MPs) and other Subject Matter Experts (SMEs) for the Analysis Team for Phase two.

Then a third, fourth, fifth, etc., thing we do is schedule all of the remaining 3 PST GRMs. Synchronize with everyone's calendars...discuss if this is the right group to be on the PST and decide whom to invite and/or dis-invite.

Also there is usually conversation about the R in ROI as the I is now better understood (my PP always call out the time/task burden for my Clients as well as for my organization). They are able to come to a consensus about the ROI without me or my Client needing to build a complicated and easy-to-pick-at ROI algorithm. We adjourn the meeting and get ready for the transition to the next phase.


Phase 2 - Analysis
Each Phase in PACT (CAD-MCD-IAD) has 4 sub-phases - with the exception of MCD/IAD where their Phase 5 has 5 sub-Phases.

The 4 sub-Phases otherwise are: .1= Plan & Prep. .2= Do it and Document it (the key activity/activities). .3= Review it and Update it. .4= Transition to the next Phase.

In CAD Phase 2 this involves coordination to get people and facilities scheduled, including communication with the Analysis Team (AT) members who have been volunteered by a PST member for this assignment and we try to give the an "advanced organizer" of what their role is, how to prepare (do nothing to prepare!), when and where, etc. And a forewarning that as an AT member they might also become DT members as in Design Team for Phase 3.

So that was done. Then I facilitated the AT meeting for 3 days at the Client's HQ. Then I went to my office and had the flip chart pages' data entered into our Access database that we had first created back in the early 1990s, while I wrote/edited the Analysis Report template in my project file. I then edited the template for PST GRM #2. And then printed out copies for everyone.

Then per the PP and our schedule the PST came together for a 6 hour meeting to review the Analysis Report and data - AND - to hear from me about what I thought I would be doing, as a facilitator driving to some end-goals - with the Design Team (DT). I put it something like: I'm going to be "deliberately declarative" here - this is what I am going to attempt to convince the DT to do.

Of course they can at this point decide: they will kill, defer, modify or approve the continuation of this project.

If this effort is to continue - then I tell them what and tell them why I think that contunation would be appropriate. Present the learners/Performers' context. Both the learners'/Performers' working context and their learning context - and what in the Target Audience data drives me to think like that - to wish to approach the design and elivery in a certain way/manner.

And then we all discuss/Q&A/debate/disagree, or they just might agree outright. After all, my opionions of what we should next had been tested against the very real world blade of Master Performers. It was more theirs than mine but me presenting at that might be seen as me weaseling out for any responsibility of the quality of the outputs for the effort expended thus far.

If they are engaged they minimally ask clarifying questions more than challenging type questions. But I encourage a healthy skepticim, tests of the completeness, accuaracy, approrpaiteness of our view of PERFORMANCE COMPETENCE and the feasibility of our approach to informing and instructing the learners/Performers to achieve -PERFORMANCE COMPETENCE - which is what all motivated learners/Performers want - and most are willing to even have to work a little bit at it to get there.

Phase 3 - Design
Next we prepareed for and coordinated and then conducted/documented a 3-day Design Team meeting effort.

We produced a T&D Path, Event Definitions for the existing T&D to be reused "as is" and Event and Mod Specs for all of the gaps from an ideal/future state set of curricula. We also created a T&D Individual Planning Guide, More on that key device in a moment.

We took that back to the PST in GRM #3 in a Design Document and PST GRM #3 Presentation - edited in the prior sub-Phase of the Design Phase of CAD. We walked through the presentation diving in and out of the Design Document per our plan and in reaction to any comment/question/concern by a PST member.

As part of getting a PST member to really know the CAD, the T&D Path and all of the content I employee a little exercise with the PST. It some times takes a bit of convincing on my part when these higher level executives are hesitant to do an exercise with their peers. But I have convince them 99% of the time (I don't think I ahve ever not done it since I started doing this after about two dozen CAD projects going way back to #1 in 1982. I must have started this in the early 90's.).

This Is A Test - A Full Destructive Test!
I ask them to take the T&D Individual Planning Guide, which reflects the T&D Path, normally 3' by 4' poster and taped to a close-by wall for our "big picture" walk-by review - to read the titles, the lengths, the deployment method, the M-HR-E ratings: Mandatory-Highly Recommended-Elective. To enable the first scan in the series of acid tests that we are deliberately putting the design to at this point.

Now it's time to get real and develop a "real or simulation" T&D Plan for a real person. It can be for themselves from "back in the day" when they had this job - or for someone in that job now that they know about. A Plan for someone real with a real (or perceived) set of performance requirements and a unique set of incoming K/S and education/experiences.

We are to test the accuracy/completeness/appropriateness/ flexibility of the T&D Path and Planning Guide - to test the configuration and content of the Events/Modules on that Path.

It is an "acid test" I tell them. A full-destructive test. If they can break it - let's do it right now.

So they develop a Plan for someone real or real-enough for our full-destructive test of our design - I give them 15 minutes as part of the test.

And then I ask them to add up all of the time for each of the first 4 quarters and then year by year - and to read that out while I board it for all to see and compare.

Never fails. Done almost always in less than 15 minutes - taking away forever anyone's future complaint that this planning effort for each staff member is too much to ask.

I do give anyone needing a minute or two more to rush to completion. It has always been an exception to the general finding of the PST who each "self-discovers" more about the burden of the planning effort - and the value of that effort - that it cannot be done in 15 minutes. It can.

It now has become very real to them. And they can kick-the-tires and discuss this particular architecture of content - a T&D Path of modular Events - with anyone now. They get it!

These executives/managers on the PST aren't going to buy that anticipate-able comment/complaint that the planning effort is too much to expect for a manager to do for each direct report. Not at all.

"Been there and done that myself" they can tell others without sympathy/empathy. It took me xx minutes when I did one they can explain. (Tricky Step #27 as John Swinney might say).

BECAUSE until you do a plan - that task can look very daunting.

And the thought of slogging though a planning exercise on something that looks very complicated with all of the levels of detail produced in the analysis phase and now completely reflected in the design details.

Which is why I always use the T&D Path poster as the macro- big picture level. Post it on the wall immediately above the coffee and cookies so everyone scans it before we get started. The PST usually hovers right at that marketing poster. They are looking and talking about THAT poster - that T&D Path. Test #1 in process.

And then after kicking off the meeting formally - we use the Event Specs in the Design Document - in a walk through - page by page (on screen). Reviewing the Path at the Event Level and the Module Levels as quickly or as deliberately as the PST wishes. Answering questions as they come up.

Then the planning exercise after that "advanced organizer" communications step of this part of the PACT Process. A second pass at advanced organizer...a further organizer...

I always "gently force" resistant PSTs into playing along: "indulge me, it's only 15 minutes I plead, etc."

And when they read out the segmented and total time burden from "their plan" and it gets boarded - they see the variation of all of the plans compared to each other.

Their own experience now from reading about each of the Events - and decoding the titling convention (more on that later) and the details of media/mode, length, Mandatory-Highly Recommended-Elective, and mentally determining the fit to the need for their targeted audience individual - is a sales closer.

When we are done with this exercise they are full of questions about the next steps the next phase.

It's always a good signal when the group you are working with becomes impatient with the current step and want to move on. At least it is for me as I tend to wait 'em out - make sure we're all on board, make sure I uncover any/all "questions/ comments/ concerns" early (and often) before moving on. I call it "go slow to go fast" in my articles and training on these methods.

Phase 3 - Design: Continued
Next - when appropriate - I explain the next Phase and how we will bring the project to a close and what some likely next efforts might be. Including identification of the Implementation Planning Team members that we intend to use.

Then we close the meeting and I do whatever follow-up and transitioning is needed for the next phase of this CAD effort.


Phase 4 - Implementation Planning
We plan and prep and conduct and document an Implementation Planning Team (IPT) meeting where we did two things:

1- put a cost estimate to develop/acquire for each Event Spec (because that is a gap in the Curriculum Architecture).

2- prioritize all gaps.

Now we have priorities for the gaps that are either high, medium, low or zero - with zero being a signal captured that those Events should never be considered for development/acquisition. Decided initially by the IPT and then confirmed/changed by the PST - who will review the priorities and costs as documented in the Implementation Plan and the presentation.

The project is formally closed out - and documents archived - for use downstream from a CAD effort. Which is typically a series of MCD and IAD project efforts.

Post-CAD
Armed with a set of priorities and cost estimates, ADDIE-level (MCD or IAD in PACT) projects can be identified, resourced and begunmanaged to completion.

Rapid Development efforts are more appropriate now, guided by the architecture and specifications - to minimize gaps and overlaps - avoiding a future state of having a "Collection of Courses" versus having a "Curriculum Architecture" of content - content that is performance-oriented and works as a system of instruction and information to help the learner/Performer achieve PERFORMANCE COMPETENCE.

Fast!

See my free books at http://www.eppic.biz/ for more on these methods and examples of them applied to a T&D function, any management role, and for qualification/certification efforts!

And now...as promised above...

More About PACT Titling Conventions
I have never been a fan of "cute titles" for T&D. Not at all. I want descriptive titles. Informative titles. Titles that help me or anyone else scan and select (at least an initial downselect).

And so in developing PACT (since 1979/1982 depending on when I learned/developed some of the early approaches and tools/templates) it was important to me personally to create a process that can be used by many - that results in "more-uniformity than not" in creating titles based on rationale titling conventions (at least for tentative titles - for these temporary titles from a CAD effort can/should be revisted and perhaps revised later - later in MCD or IAD projects where the "gaps" of the CAD are built/bought - or both.

Retitle there - and then maybe use the tentative title of the CAD effort as a sub-title. A telling sub-title. (Never give up I say: Truth in Titling!).

There are 3 "tags" in the tiling convention:

1- The title begins with O&O. As in: "O&O: Six Sigma" - as in Orientation and Overview - de-code-able by those with the secret decoding ring as: this covers that task or topic at an orientation and overview level thus creating Awareness (at best). The target audience will be made aware - and given what they are presumed to already know - this may be all that is needed - even to affect the skill/application/task-set/process/workflow - capability of the learner/Performer.

2- The title contains no "preface phrase/word" and would read: "Six Sigma" - clarifying for all who "get the code" that this cover the task/topic to the Knowledge level. The target audience now knows something - and hopefully that is all that is needed - to affect even the skill/application/task-set/process/workflow - capability of the learner/Performer.

3- The title contains the "preface phrase" of HT - for How To - and would read to those in the know: "HT: Six Sigma" - clarifying for all who "get the code" that this covers the task/topic to the Skill and/or Application level. The target audience now knows how to do something new or different - something clear: tasks to produce outputs to stakeholder requirements - to affect even the most complicated of skills/applications/task-sets/processes/workflows - all of the capability requirements of the learner/Performer in the target audiences.

More power to: Truth in Titling!

Which informs and empowers the learner/Performer!

# # #

When You Set Learning Goals - What Perspectives Do You Take?

Behavoirs and Tasks - are simply the means to an end. Or the means to multiple ends.

That end or ends is the output/outputs of a process or processes, that either meets or does not meet the various stakeholders' various requirements for the output - and/or for the process/tasks/behaviors.

# # #

The 7 Design Steps of CAD - Curriculum Architecture Design

The secret to success in the design of the "ideal" T&D Path is having 1-the right data, and 2- the right data processors, and 3- the right process. Data processors process analysis data and make design decisions in a predictable process. Predictable in terms of touch time and cycle time and quality of the output.


In PACT's Curriculum Architecture Design (CAD) methodology...I teach designers at the CAD level to trust the process - just as I taught analysts learning to run Analysis Team Meetings - and trust the process. I then teach them how to facilitate the analysis steps and the design steps - PACT processes - in such a way so as to anchor the design to performance - and to provide "as much flexibility as feasible" and "as much rigor as required." And to have the Design Team assembled be the "owners" of the design - and not the designer.


The 7 Design Steps of CAD are framed in the following steps:


1- Establish the Path
Talk with the Design Team about T&D Paths - will there be one, two, seven different Paths? What does the Target Audience data suggest? How many definable populations in the Target Audience - where each might need a slight variation here and there to address the true differences in requirements, processes, environmental materials, tools that exist; or varied/flexible to account for the incoming knowledge/skill profiles being hired.

What does the front end look like?

I suggest that we think Modular...and initially see the T&D Path as having three segments: Beginning - Middle - End. As a device for sorting our analysis data. I ask them to trust me, trust the process.













And then we start discussing the Beginning of the Beginning of the Path - that will have content that orients one to the entire Enterprise, and then it's sub-component organizational entities - be they Divisions, Business Units, Segments, etc., answering:

• What are they, what products/services do they render and to/for which customers? Who are our customers' customers and what are their requirements? Who are our competitors? What are our processes, locations, partners/value chain members? Who are all the other stakeholders beside our customers? And other "typical" Company Orientation content.
  

Then the "B of the B" continues orientating the learner/Performer to the function (Sales, HR, Finance, etc.) that they work in (and "for" and "with" too -- depending on the sophistication/richness of the T&D Path's content). Then the Path's content orients the learner/Performer to their own job and it's processes, it's AoPs and the high level output/tasks of each AoP.














In the Middle of the Beginning I see deeper orientations to the specifics of "My Job", those "advanced organizers" that I have reflect the AoPs (Areas of Performance) structure - because IF it worked as an organizing framework for the analysis data gathering and review efforts - it should work to organize the content - both Instructional and Informational - need to enable Performance Competence development - as framed by the analysis' framework of AoPs.

Then in the End of the Beginning of the T&D Path I tell them, I see all of the Immediate Survival knowledge and skills being addressed - addressed to the "how to" level. Deployed in a blended manner.

And here in "establishing the T&D Path" with the Design Team, is where I introduce the first decision point for them - a decision that they make later - this is just their Advanced Organizer for that later step - that they will have to decide what content goes before the "End of the Beginning ends" and where the T&D Path "Beginning of the Middle begins."

In other words, what are the "lines of demarcation" of the Path's Beginning, Middle and End? And what time frames do they represent? We may guess right now - but as we shape the T&D Path with content and decide how to deploy the content we'll see how our guesses at timing of the progress a learner/Performer and how long it might actually take - might change once we see what is truly practical/realistic?

I am not afraid to talk "ahead of ourselves" with the Design Team - so that they see how we're going to approach this task, the design of a performance-based T&D Path - in logical steps - so that they see that there is a process (a method to the madness). I talk our way through the 7 steps and bring up what we as a team will be doing...and what I the designer will be doing as a both a Facilitator and as an Instructional Designer - and what they as a Design Team will be doing as the "facilitated."

I tell them we are going to sort all of the analysis data "that you generated in the Analysis Team meeting" - sort the Outputs/Tasks and then sort all of those enabling knowledge/skill items - all (tell them the number of enabling K/Ss from the analysis effort here), as well as the assessment data for Existing T&D that we might use "as is" as well as 'after modification."

Then I ask them how that modular front-end (the beginning/ middle/ end of the Beginning) of the T&D Path accommodates the sub-types in the Target Audience. We review the TAD (Target Audience Data) together. I talk about the flexibility requirements of the "front-end" of a T&D Path. So - if "new target audience" members come from inside the Enterprise - they should be able to skip content and target new content unique to their incoming K/Ss (Knowledge/Skills).

We need to create a design of information and instruction that is "robust" to all of the variants - to work within all of the constraints and meet the requirements - which should be to assist all motivated learner/Performers in becoming Performance Competent. Performance Competent = ability to perform tasks to produce outputs to stakeholder requirements.

I get large flip chart paper and lay that out on a long conference table and mark off the Beginning and the Middle and the End on the T&D Path - which is now three or more flip chart pages taped one-to-another, end-to-end on the table. And I mark off the Beginning/Middle/End of the Path's Beginning - to remind them of what we've discussed will go into each of those sub-segments of the T&D Path. To make this much more visual for them.

Then we discuss what is safe to assume and what is not safe to assume about the Target Audience. I usually let them talk this out until they are off topic. Once we have gotten a pretty shared understanding of the target audience or audiences by discussing what was captured during the analysis phase about them in the Target Audience Data, we can begin to process our other types of analysis data.


2- Sort the AoP Data
This is where the "Output/Tasks/Roles&Responsibility/Gap Analysis Data" gets sorted, gets processed.

This analysis data - the "Output/Task Cluster" as I typically refer to the whole data-set - gets sorted into the End of the Beginning of the T&D Path, or into the Middle of the Path, or into the End of the Path. I had the analysis data printed off into what I call AoP Slip Sheets: which contain a "row" off of the Performance Model charts. It is these Slip Sheets, usually a 1/4 to a 1/2 page (but sometimes a whole page).

These different sized pages make the design process very visual, we can see the tasks of the job being taught in some logical order - as they are placed on the tabletop T&D Path marked B-M-E.. The placement logic comes from the Design Team - and the designer, who through control of the process can help the Design Team be more efficient with their time.

Once all AoP Slip Sheets are initially sorted they are reviewed for sequencing needs or clustering into little menus on the path - all temporary! - I remind the Design Team members.

We have a lot more data to process.

But here I ask the first "acid test" question for them. As I try to close out this step with them...

IF we taught the learner/Performer population "how to" do all of these Output/Task clusters of data - would we be finished with the T&D Path?

Does this "T&D Path" now anchor us into the real world's performance expectations? All of the expectations? Covering the total "job?" If not, then what are we missing - or is "it" a sub topic/task detail still in the AoP content that has been spread across the table, on the B-M-E segments of our evolving T&D Path?

3- Sort the ETA Data
I then walk over to the wall where I had posted the 7 steps (with check boxes as the bullets) and check off 1 and 2. I read off the 3rd step and then walk back to my assembled team and explain that this is where we accommodate all of the existing content that we uncovered and rationalize its use in the T&D Path that we are framing.

Each T&D Event (course, module, workshop. session - at the administrative level/tracking level) is represented on a T&D Definition Sheet when we intend to use it as is. Or the data comes to us on a T&D Source Sheet when we intend to use it after modification. It is these two types of "sheets" that is sorted.

T&D Definition Sheets, often printed on dark gold paper regular size (for the US that is 8.5 x 11 inch paper), are going to exist on the T&D Path as one of its Events. T&D Source Slip Sheets, often printed on 1/2 pages, are going to end up inside the definition of a Module - later after step 5.

So we talk our way through each T&D Definition and place it on the Path relative to all of the AoP Slip Sheets already there. If the content of that T&D Definition "enables" some task-set (on an AoP Slip Sheet) it must go in front of that AoP-Task-set. If it enables more than one AoP-Task-set then the T&D Definition Sheet must go in front of them all. It might push that T&D Definition into the Survival Skills segment of the Path (the end of the beginning of the T&D Path). If so - so be it!

4- Sort the EK/S Data
Next the Design Team must do the sometimes tedious task of sorting through huge numbers of Enabling K/S Slip Sheets. Maybe it's always tedious.

The K/S Slip Sheets are 1/2 to 1/4 size pages, and includes only "one K/S Item" - identifies its K/S Category and other analysis data from the K/S Matrices - finally - which AoP's the K/S Item enables. This last pice of information is critical - in that it guides the sorting on this data onto the T&D Path.

One by one, each K/S Slip Sheet is reviewed for its content, the category, the item, its criticality, difficulty to learn, volatility and depth (from the K/S Matrices data) and lastly - which AoPs this item enables.

Then the Path must be reviewed to find the earliest instance of an enabled AoP - for this K/S Slip Sheet must be placed in front of that first AoP. AoPs are no longer in their original sequence (from the analysis efforts). They are placed "however" on the Path - "however" with a logic. And - they are broken out further into Output/Task Clusters. But still the AoP Slip Sheets are identified by their AoP - so that is used to place each K/S Slip Sheet.

Once that is done, often for 400 to 1200 discreet K/S Items, the table top with the flip chart pages representing the T&D Path might include sequenced AoP Slip Sheets in one color, T&D Definitions Sheets in another color, T&D Sources Slip Sheets in another color, and K/S Slip Sheets on white paper (due to their number). By this time, in my experience, the members of the Design Team really know where the AoP data is, where the Existing T&D is going to be, and where all of the K/S items will be learned.

Time for another "acid test" to be administered: "Given what we as a Design Team have accomplished - are there any weak or missing areas from your perspectives? I ask the assembled." We talk that out and make new slip sheets or full size sheets and retro-fit new data onto the path, trying to get "it" identified and placed (sequence-wise).

I let the team really talk this out - get into all of the details, add words to the printed out forms and formats we are using. I need to get them comfortable that we've got a very complete set of data that truly cover the job requirements of our target audiences. And the next steps are going to bury all of this rich data into the layers of the CAD design.

5- Modularize the Data
Now it is time to define the Modules of our modular design. Module is a term that means chunk. Segment. Component. I appreciate that for many it has a very precise meaning -most likely different from how I use it. The term "Module" in PACT occurs only in the CAD level of design and it is a temporary design "devise" - later in PACT, in two other design levels - MCD and IAD - those "Modules" of a CAD become "Lessons."

But for now in CAD, Modules are the Chapters and the Event is a Book.

Starting at the very beginning of the Path, the first Slip Sheet is taken up and stapled (or "paper clipped") to a blank Module Specification (Mod Spec) that is white in color. Now the task is to see if any of the other nearby Slip Sheet should go into this first Module with that first Slip Sheet. We try to accumulate appropriate content into Modules, using "Rules/Guidelines of Modularity" that we share with the Design Team so that they can play appropriately.

If a Slip Sheet does not go into an existing Mod Spec, then a new Mod Spec must be created to "house" that latest Slip Sheet. This is a tedious process as well. When done the table top T&D Path should be covered in white Mod Specs and golden T&D Definitions. Check the sequence logic of the Modules as you do the next step.


6- Eventize the Modules
This is the final packaging step of CAD Design. All those Modules (think: Chapters) on the Path need to be put into Events (think: Books). Starting at the beginning o the Path the Modules are processed to go into a T&D Event - using yellow T&D Event Specification blank templates. A Module either goes into the first - and later into any existing T&D Event - or it starts a new one.

Modules are stapled or clipped to the Event Spec and placed back onto the T&D Path in an appropriate sequence. When done the table top version of the T&D Path is covered in gold pages for the existing T&D (T&D Definitions) that is going to be used "as is" - or it is in yellow pages for the T&D Events, the gaps in the current curriculum offerings for the Target Audience or Audiences.

7- Clean-Up and Finalize the Path
This final step of the design process addresses naming (using naming conventions) Modules and Events, estimating the deployment modes and lengths of the content of this modular design. This step is also where the Path segments might be adjusted/changed as needed: where the 3 segments of "Beginning - Middle - End" used as an initial sorting framework - might become 4 to 8 to 12 stages/phases/blocks (my clients over the years had some interesting labels for the T&D Path's segments). We re-estimate the cycle times, We re-evaluate the sequence of Events.

We go up and down the Path and make sure that we have a consensus from the Design Team on all of the data.















Some T&D Paths look more like a Menu than a Path...














After closing out the 7th step I like to debrief the entire Design Team.

1- I ask them to take a piece of paper and write down two numbers: the % of "everything under the sun" that we captured in our design - and the % of all critical items did we capture in our design? I collect those and board them on a flip chart easel. Someone does the math and we determine the average for each category.

Then, one at a time, and in order, I continue...

2- I ask them for their comments about the product we produced.

3- I ask them for their comments about the process we employed.

4- I ask them for their comments about any issues that they see for us going forward.

I capture all of their comments on flip chart pages at the front of the room. We thank them for their time and participation and send them on their way. We then begin the final room clean up step before ourselves heading out.

# # #

7 Steps of PACT CAD's Design of the T&D Path or Map or Menu

CAD - Curriculum Architecture Design is an ISD - Instructional Systems Design - process, but is not ADDIE - Analysis/ Design/ Development/ Implementation/ Evaluation ISD. That - is at the product level of design/development of ISD.

CAD is at the systems engineering level of "product line" design of instruction and information - to enable human performance - for targeted jobs - in targeted or all of their processes. Designing the flow and timing of content - enabling better timing of the participation in training/development - and the appropriate points in the process for evaluation of the progress being made.

CAD has 4 Phases to guide formal adaptations or informal adaptations/approaches, hybreds, adopting some methods/tools/techniques and adapting others.

If you have met all of the exist criteria of Phase 2 Analysis - you are ready for Phase 3 Design.

Design is where a Design Team using all of the analysis data - is facilitated through the 7 design steps. That typically happens in one multi-day meeting. Of course there are preparations done prior and documentations done post.











The 7 Design Steps of CAD are framed in the following 7 steps:

1- Establish the Path
2- Sort the AoP Data Sets: Output/Tasks/R&R/Gap Analysis Data
3- Sort the ETA Data
4- Sort the EKS Data
5- Modularize Data
6- Eventize Modules
7- Clean-Up and Finalize the Path















Note: This set of design steps works IF the analysis data needed - is available in the "configurations" of 1- Target Audience Data: demographics, etc. - 2- Analysis data organized by outputs-tasks-role/responsibilities/gaps - 3- Enabling Knowledge/Skill Data - 4- Existing Training & Development: for its reuse potential in this targeted effort.













This analysis data always ends up inside the design elements - in The PACT Processes. All of the design elements below the Event Level are "housed" in an inventory scheme of 5 Tiers...














Those 5 Tiers are:

Tier 1: Organizational Orientations
Tier 2: Performance Orientations
Tier 3: Enabling K/S
Tier 4: Shared Performance "How To's"
Tier 5: Unique Performance "How To's"

The 5 Tiers "inventory" both the designs of content - and the actual content - at the Instructional Activity level and Lesson levels (not addressed in a CAD effort) - and at the Module level of CAD projects - in that a T&D Path is composed of Events which are composed of Modules...a modular design of Events (Courses, Workshops, Sessions, WBTs, etc.).



















The logic of PACT - is a data logic.















Data is framed in the PACT Processes per the next diagram...
















Back to the 7 steps...


7 Design Steps of CAD

1- Establish the Path- This is how you can begin the team process with "the end in mind." A shared "end in mind" mental model of this T&D Path thing that you are here to design/create/build.

I always present a "build-up picture" of where we are going to produce and how, by first talking about the T&D Path of T&D Events - the terminal goal of our design process - as a tight, sequenced path of content when and where necessary - and a looser, menu of content - when appropriate. With a blend of all kinds of deployment means and mechanisms - currently available and practical for the learner/Performers, and hopefully, thereby appropriate.

Organized to help each learner/Performer and/or their managers downselect from the T&D Path to create a T&D Plan...unique given the performance expectations of each learner/Performer and their incoming education and experiences and knowledge/skills.

A T&D Path is a "learning continuum" in that it lays out a set of content in a structured and orderly manner - so that the learner/Performer and/or their manager - can sort through all of the content relevant to their jobs - and downselect the Events and arrange and time the order for participation/completion (unless a sequence and timing is mandated by the Enterprise to comply with external regulations or internally imposed requirements).

When designing one the designers and the Design Team needs to have a frame of reference that they share - otherwise this tends to become a swirl where little gets done. The process is not clear and/or adhered to.

That's why establishing the Path - establishing a shared frame of reference, is important. And basing that on a review of the Target Audience data. What is it about the "knowns" of the target audiences' incoming (for new hire) and/or current (incumbant) knowledge/skills levels compared to the needs of the processes that they perform within - that would suggest some deployment modes/methods over others? Which are feasible modes/methods given both the Performance Context and the Learning Context for that Target Audience?

Here is how I frame the T&D Path so we can attend to the remaining steps with a shared mental model of what we are going to develop over the course of the Design Team Meeting...

Every T&D Path has a beginning - and a middle - and an end.













The Beginning - Middle - End concept is simply a framing devise that we are going to use to sort our analysis data into to rough out a sequence of content for the target audience. If your project is addressing several target audiences then you should be attempting to produce multiple T&D Paths. Trickier - but doable.

So it helps a team to discuss this after they see the next bit...that Beginning and its Beginning-Middle-End as additional framing of everyone's mental models for a T&D Path.













Every T&D Path that I've ever produced for a Job (versus a Process) has this kind of front-end...subdivided into 3: The Beginning's beginning-middle-end.


Where the Beginning of the Beginning is all about: Orientations to the Organizations of the Enterprise. From top down the organizational chain - from My Enterprise, My Division/Business Unit, My Function, My Department, My Job, My Teams and My Team's Processes. Or something like that.

Where the Middle of the Beginning is all about: Orientations to the "My Areas of Performance" unique for My Job - this series of content that further details what was covered in the My Job "content." If a PACT analysis effort did not precede the design effort - then this portion of the design will be weak - and not performance targeted - and not necessarily gap free.

Where the End of the Beginning is all about: giving me the immediate survival knowledge and/or skills necessary for someone new to this job. This is where variation by design occurs, where a T&D Path becomes more Menu-like.













For some jobs, this is where this segment of the Path covers either "the whole job" or "part of the job to-get-you started" - as appropriate to the job. For an airline pilot - they need the whole job covered. For a part-time sales clerk in a clothing store where there will always be a seasoned sales clerk on duty as well - they need part of the job covered.

This is only important as that changes the remaining B-M-E segments of thee T&D Path.

The "BoftheB" orients the learner/Performer to their job context, from top of the house to the individual contributor role for critical roles. The content created for the most critical of target audiences is then available to others and might end before getting to their job level "advanced organizers." That is what the BofhteB is all about.



















The "MoftheB" is all about a deeper dive into "My Job" - addressing "My AoPs" - which are the Areas of Performance that framed the analysis prior to any CAD design steps.

As the ideal Design Team is a subset of or the whole Analysis Team (with "no new" players) they already understand and trust the AoP framework and the data details that it represents.



















If a detailed PACT analysis wasn't done - or the anlaysis effort gathered data in a different data configuration - then this is step is harder to do and define the result with great confidence. This portion of the T&D Path can be defined without a proper PACT analysis that correctly frames the Areas of Performance, but that may lead to risks. Risks which are either tolerable or not. Let that be your guide with your clients. They get to decide what is a tolerable risk and what is not.

The content objects defined here are merely advanced organizers - for the enxt series of training/learning about the job's performance expectations and when and how one will learn "how to do it" further down the path.

Next the "EoftheB" is framed, discussed - so that everyone knows where we are collectively headed.



















After the "B-M-Es" of the Beginning are described/discussed the Middle of the T&D Path and the End of the T&D Path are described and discussed. If possible - a lot of drawings may be needed on the flip chart paper or whiteboard. And depending on which "way" the End of the Beginning went - whole job or partial job - the Middle of the T&D Path - picks up at a very different spot. So it can be short or very long relative to the length of the entire Path.

Which is a good thing!

The final task is to estimate/guess - the cycle time for: 1- the Beginning, and 2- the Middle, and the 3- the End. And - are there more than 3 "phases/stages" of the path or map or menu that seem appropriate at this stage - some framing that links this to something in their real world? If so, use it.

The "segments/phases/stages" of the Path and their cycle times will be reviewed and adjusted at the end of each of the 7 design steps IF it seems appropriate to the Design Team to do so. Which we will now continue with...design step...


2- Sort the AoP Data Sets: Output/Tasks/R&R/Gap Analysis Data . I warn people that I train/certify to do this that some on the team might not like processing these decisions quickly and that is the goal: to quickly sort of "outputs/measures/tasks/roles responsibilities/gap data" into the B-M-E of the T&D Path framework - already "established" in the minds of those participating in the CAD design steps.

But if they were part of the Analysis Team - they might be able to be encouraged to let the team go full-steam-ahead on this and then step back and survey the results. That's the facilitator's role: to push the group to quickly process - and then step -back and examine - and tweak as needed.

I have print outs of the analysis data configured in a different format from how it was captured and reported out for review. It's often printed out on light Blue paper. And on 1/2 or 1/4 paper sized pages which we call Slip Sheets.

We also tape flip chart paper and paper a couple of conference tables end to end (sometimes 3 tables are used). We mark the top-sides: Beginning - Middle - End - and create a visual to go along with the shared mental model we attempted to develop across the team earlier.

Once all of the "Output/Task Clusters" - as I call this data-set - are sorted onto the Path - the Path is re-visited/re-examined for its logic and the timing of B-M-E. Update as necessary.


3- Sort the ETA Data: Now that the "Output/Task Cluster" data has anchored the T&D Path design in a performance orientation, it is time to see how the existing T&D that was assessed in the ETA - Existing T&D Assessment part of the analysis phase, is to be used "as is" or after modification" within the design.

If these existing T&D "products" indeed cover the Task Training then they replace (consume) the O/T Cluster data with them. I have pages with this information on it printed out onto a deep gold paper. I staple the light Blue pages of the O/T Cluster data onto the back of the Existing T&D Assessment Page which is in Gold.


4- Sort the EKS Data: K/S Item data are printed out on white paper - usually in 1/2 or 1/4 pages sizes - which we then refer to these too as Slip Sheets. These then sorted into a sequence per the AoPs that they enable. That means they precede the AoP data on the path - because they are an enabler. Sometimes they are deemed to be covered adequately in the ETA Sheets on the Path. They are then stapled/affixed to the ETA Sheet. Or they are left alone on the Path in a sequence deemed appropriate given the AoP Tasks that they enable.


5- Modularize Data: Mod Specs are printed on green paper - full size. Once all of the ETA Data is represented and the remaining AoP data and Enabling K/S data is visible on the table top (representing the T&D Path) on Gold paper - the first AoP data on the Path can be placed/stapled onto a Module Spec Sheet and then the next slip sheet of either AoP data or K/S data is examined to see if it goes into any of the Mod Specs produced so far - or does it get it's own Spec Sheet (destined PERHAPS to be a stand alone chunk of content someday - IF a priority).

The each and every slip sheet is examined in a similar manner. Until all slip sheet have found a home in 1 Mod Spec. These are now sequenced into a path or setsmenus on the path.

Mod Specs are like Book Chapters. Now that you have the chapters figured out - it's time to specify the Books - the Events in PACTerms.


6- Eventize Modules: Event Specs are printed out on yellow paper. All Modules are examined, starting with the first on the Path, and placed into an Event Spec. The first Module goes into the first Event Spec. All others go into an existing Event Spec of a new one is created just for it. These are placed on the Path in a sequence relative to all ETA Sheets and other Event Specs - continuously. To check the logic of it all!

7- Clean-Up and Finalize the Path: Whe everything has turned gold or yellow on your table top version of the T&D Path - you are in the home stretch (near the end). All that is left is fianl sequencing, truth-in-title changes (still just working titles), numbering on the Path, determining the mode of deployment for each Module within the Event, estimating the length of each Module and adding them up per Event - to sum total the estimated length etc.

The B-M-E of the Path might be changed to 2-3-4-5-6 segements. I've had up to 10 that made sense to the Design Team - and that number of segments of a T&D Path I always leave up to them. Who else would do something more approrpiate for that Target Audience?

The example T&D Path below has 4 segments...

















What are those boxes on the Path? They are the Events...some of which exist...














Some exist as use as a source/use after modification....














Some are currently complete gaps...














Here is the code section of the Path...












Here is another Path that is more Menu than Path...














For more get the free 404-page book PDF of "lean-ISD" at http://www.eppic.biz/ - plus the hundred or so other resources available there as well!



















Plus review the other Blog Postings in this current series.

# # #