Click on image to enlarge and then copy, etc.
Like a Zombie refusing to go away – the discussion of ADDIE’s viability, validity, utility has again risen. It seems that whenever a big conference occurs, participants get together and talk about the(ir) failures with ADDIE. Or their inability to convince/sell their clients on the value of Analysis – something Joe Harless bemoaned over 30 years ago.
Most practitioners have plenty of ISD methods to use within an ADDIE “project planning framework” – what they lack is a way to put them together in a lean, smooth and quick effort.
The PACT Processes for T&D/ Learning/ Knowledge Management are scalable from the focus on some small task-set, to an entire enterprise or value chain. And as a “common process” more people can be involved in some divide-and-conquer approach to speed/accelerate the “process” or “processes” to produce performance enabling training, development, learning, and knowledge management content. At the smallest level – PACT becomes RADD – an abbreviated version of PACT – when the needs scale is small and not enormous.
Not everything needed by a performer is training, or learning. Sometime the need “in the moment of need” is to look something up and then forgetaboutit.
Your analysis and design methods in your version of ADDIE (or not) and data produced – should make all of that clear in terms of needs and the appropriate means to address that to enable performance.
# # #
30 years ago we were all taught to document our captured analysis insights from our observations and interviews in “certain ways.”
One of those “ways” included using “Noun Verb patterns” to describe tasks – the results of “typical” task analysis methods. Not my in approach/ methods/ process. But in many others.
Examples of this pattern include:
- Analysis Planned
- Analysis Interviews Scheduled
- Interviews Conducted
- Observations Conducted
- Analysis Report Published
I stopped using this for a couple of reasons…
1- I never liked having to explain “what these phrases” meant to our clients. That seemed absurd. Why wouldn’t they recognize our description of their performance requirements? It always hung us up on getting them to sign off on the completeness, accuracy and appropriateness of our “task analysis.” They could not see what “boundary conditions” we meant by this strange language – so they couldn’t tell if there were holes or overlaps in “our view.”
2- Early on in my career (in 1980 after less than a year on-the-job) I started to minimize my analysis efforts involving interviews and observations – and started to maximize my use of a “group process” to gather the data that I needed for my downstream design efforts – which I had “systematized” in my PACT Processes for the Curriculum Architecture Design level of ISD, and my Modular Curriculum Development level of ISD (known as ADDIE most other places).
And the groups of Master Performers and sometimes (as needed) other Subject Matter Experts, Supervisors/Management representatives, and Novice Performers (when appropriate) did not “call their work out” in those Noun-Verb patterns.
Any facilitator worth their salt could see that “going there” would be a big mistake. I did.
And so I never attempted to sell a room full of Master Performers on my conversions of their language – when it was darn difficult enough to get “concurrence on some of their language” between the assembled – which I often found was “varied” across the organization from the starting points of the facilitated analysis sessions.
Our building of a “Performance Model” with the handpicked Master Performers was perhaps a first step to commonizing the language – depending on how my client’s seized that opportunity. Many did – as that new language, conceded to by the Master Performers themselves, most often made it straight to the language in the titling of content downstream – in the PACT Processes “design steps” where the analysis data is processed – for both CAD and MCD.
# # #
Balancing Conflicting Stakeholder Requirements-
by Guy W. Wallace, CPT
Originally authored in 1994, published in 1995, and updated here in 2010
Now available at here as a 16 page PDF.
I had titled it “The Customer is King – Not” – but they had the editorial prerogative.
The article was written after a discussion with a client about “the customer is king” and my resistance to including that in a 6-day “performance-based” training course for project leaders in leading multi-million dollar projects (hundreds of millions really) – when I had strong feelings about “the customer is king” sloganeering I had encountered at many of my client organizations in the 1980s and early 1990s.
So I wrote the article that created “the graphics” below – for illustrative purposes only – yours will definitely look different!
There are many other potential stakeholders not represented in the graphic/model.
Once you have the somewhat simple model – you can tease out and build a matrix for all stakeholder requirements. Some might see the last graphic as a QFD output – and they would be thinking along similar lines. QFD being Quality Function Deployment.
And the sad truth is that there might be many “conflicts” between all of those REQUIREMENTS and WANTS.
And that success will “almost always” depend on the enterprise being able to “navigate in these waters” that constantly churn.
The only constant is constant change.
Can your efforts keep up?
# # #
You can follow my quarterly columns at PROVEN at:
The older content is viewable – but the latest issue isn’t – for some reason that I don’t understand – unless they are only providing the past issues of PROVEN. So, at least you can catch up! My quarterly series is in all but one of the issues – volume# 2 issue #4. There are 11 columns submitted to the editors at PROVEN – so far.
The columns present my models, methods and approach to implementing HPT – Human Performance Technology via EPPI – Enterprise Process Performance Improvement.
The EPPI methods, etc., is an extension of the PACT Processes for T&D/ Learning/ Knowledge Management – especially for the analyst and somewhat for the Project Planner/Manager. Less so for the distinctly ISD roles in PACT.
# # #
Some of us focus on Learning and Training in an Enterprise setting.
There the objective is clear:
protect and improve the enterprise
Focus on improving performance in small, simple processes and in large, complex processes based on the value of addressing that need. Use the business metrics of the processes you are addressing to measure your impact.
Respond to the issue (problem and/or opportunity) in the least expensive manner – from a life cycle perspective, not from a first-costs perspective – without reducing results. Know what the value of the PIP – Potential for Improved Performance is. That PIP is the same as the R in ROI – Return on Investment. And the PIP is the same as the CoNC – Cost of Non-Conformance.
Performance Competence is defined by the STAKEHOLDERS and not just the customer or the customer’s customer.
Performance Competence is the ability to perform tasks to produce outputs to stakeholder requirements – at the individual, process, enterprise and society levels.
Those “levels” have more recently been tagged as: the worker, the work, the workplace and the world. That works too.
So if your formal or informal learning/ training/ knowledge management “solution” is targeted at enabling people to perform – then you are on the right track. If it targets some content for “in the moment of need” and some for “before the moment of need” (with more reinforcers & reminders for recall) – then you are on the right track. If your solution cost is much lower than the varied types of returns the enterprise will get back – then you are on the right track.
Then you will be on the track to Performance Competence. A worthy goal for those of us in Learning and Training. And Knowledge Management.
# # #