From the SWI Pursuing Performance Newsletter – Spring 1994
Phase 4 – Training Development/Acquisition
This article is the sixth in a series describing the SWI PACT Process for training
design. We include under “training” all methods of deploying awareness, knowledge,
and skills to target audiences. Training methods may include orientation,
education, training, on-the-job development, cross-training, and so forth. The
PACT Process covers both our approach to Curriculum Architecture design and to
custom course development.
In previous articles in this series, we’ve covered the analysis and design that precedes
the development of training courses. We’ve also covered the project planning
and organization involved in such an effort. In this article we cover:
• Make/buy considerations for “filling the blanks” in the curriculum design
• The “standard” approach to acquiring training modules
• A shortcut method for acquisition
• Considerations for training module development.
The ideal approach, in our opinion, is to always go through the full-blown PACT
Process Analysis (Phase 2) and Design (Phase 3) even if we think up front that we
may “buy” modules instead of “make” them. Phases 2 and 3 give us the data we
need to either develop or acquire the training modules in the curriculum. The
output of Phase 3 of the PACT Process includes a Lesson Flow Diagram, Lesson
Specs, and Activity Specs for each of the modules in the Curriculum Architecture
design (see the last issue of Pursuing Performance). The approved design document
describes in detail exactly what is to be developed or acquired, including the ideal
lesson configuration and lesson activities for information, demonstrations, and
exercises. The design should have been thoroughly reviewed by the project’s Steering
Team, of course. Used correctly, this detailed and approved document can be
very effective during Development/Acquisition, and can allow developers to move
into Phase 4 with great confidence.
Training Modules: Make or Buy? Whether to buy or make is really an issue of
balancing the impacts of having a training program that might be just “okay” versus
a program that’s more on target.
For example, filling a need for presentation skills training might seem like an
opportunity to take advantage of the courses available through the packaged training
marketplace. You could check out a number of courses and simply buy the best one.
But if you’ve done the homework dictated by a complete analysis and design, you’ll
be able to assess make/purchase issues such as:
• Your learners’ applications of presentation skills
• What the training must do to help meet presentation performance objectives.
Whether you decide to buy that “okay” course or build a more optimal course will
depend on the answers to a number of questions:
• How many people in the organization will be affected by your decision? The
more people affected, the stronger the case may be for custom development.
• How big an investment are you considering for the purchase? The higher the
investment, the more you might want to think about custom development.
• Is the content to be delivered of strategic importance to your organization? If so,
the negative impact of a course slightly off target will be magnified.
• How different are the situations in which the skills are to be applied? Presentation
skills for a team meeting are different than those for a television interview,
a corporate board meeting, or a Senate hearing.
• Do different stakeholders have strong vendor preferences for packaged training
solutions? In this case, perhaps a custom version integrating elements of several
different approaches is the best way to go.
Even a simple example like presentation skills training demonstrates that the
decision to purchase rather than develop may not be a “no-brainer.”
Acquiring Training Modules. If you have done a full analysis and design for the
modules you intend to buy, you will have the ideal set of shopping criteria. Simply
compare and contrast the features of each potential purchase to your design. You
cannot expect to find a course configured exactly like your design; however, for
your desired modules you should be able to effectively evaluate:
• Content items (information)
• Example items (demonstrations)
• Practice items (exercises).
What if you don’t find anything close enough? You’ll easily change paths from
“acquire” to “develop.” You don’t have to start all over; simply get approval from
the Steering Team, amend your project plan, and begin development.
The Shortcut Method of Acquisition. There are situations when it’s appropriate to
simply buy the best program available and when the purchase may not need to be
done following the full-blown analysis and design we usually recommend. You may
have seen some of these situations.
For example: Was the needs analysis done politically rather than professionally?
Has a high-level manager uncovered a need to be addressed by a preselected training
solution, and is the manager intractable enough so that no one will challenge
his or her solution? If that’s the case, go directly to “Purchase” without passing
“Go,” especially if:
• Not that many people will be affected by the decision.
• The investment is moderate.
• The impact of the content to be delivered is not of strategic value and lacks a
high-enough potential return on investment.
• You have a great training evaluation system in place (giving you more than just
“smile sheet” data), and you will be able to later judge the purchase choice
based on data and not opinion.
In this case, you have an opportunity to skip a battle and get back to dealing with
higher-impact training issues. Buy a program.
If you can’t do a full and detailed analysis and design, there are shortcuts for coming
up with the criteria you’ll use to shop for the training you’re going to purchase.
Talk to members of your target audiences to find out what they want and don’t want
in their training. Capture:
• Their preferred delivery method (CBT, classroom, readings, video, etc.)
• Minimum and maximum length of training tolerated
• The preferred amount of interaction
• Applications and situations in which the skills will be used
• Preferences for specific content, case studies, and exercises (we once had a
client R&D group object to the “simple” examples used in a prospective packaged
course on quality tools).
The insights you gain via these conversations will help you narrow the range of
options you find in the packaged training marketplace.
Data Gathering for Development (More Analysis?!). If you’ll be developing the
courses in your Curriculum Architecture, the data you’ve gathered during analysis
and design provides most of what you’ll need. The Performance Model will be
especially useful. However, during development you’ll gather more targeted information
from subject matter experts (SMEs) and master performers (MPs) on topics
relevant to particular training modules. The Performance Model will be the vehicle
for doing more targeted analysis; you won’t have to start from square one.
Most of the time, data gathering is done through interviews with subject matter
experts or master performers for specific tasks or knowledge/skill items. The purposes
of the data gathering step are to:
• Get specific “how-to” techniques for relevant situations
• Find real-life examples to use in the training
• Discover significant “variations” on the target task. For example, if the target
task is to develop a budget, variations might include dealing with cross-department
projects, currency exchange rates for international projects, a lack of
available forecast data, ambiguity – whatever barriers to performance exist.
One of the Phase 4 ground rules is that only minor changes to the design are allowable.
The Steering Team is told up front that minor tweaking might have to occur
after the design is approved. SMEs and MPs who know that the design they’re
seeing has been sanctioned by the Steering Team can (hopefully) be restrained in
their enthusiasm for redesign. You yourself will achieve insights during this phase
that will allow you to deliver a better product; and you should be allowed to do so,
but your goal at this point is to keep changes evolutionary rather than revolutionary.
To Test or Not to Test: Developmental Testing. We feel that training developers
should perform internal and informal developmental tests during this phase as they
see fit. For example, it’s usually worthwhile to tryout exercises to ensure that instructions are complete, that learners have enough information to answer questions,
that exercises are not too difficult and not too simple, and so forth.
However, much of the time the structure of the content – and the way it’s expressed
– is rather arbitrary; one approach will work just as well as another. Be
aware that if you ask for opinions on content and expression during a developmental
test, you will surely get those opinions, along with the consequent rework (and
potential schedule slippages). Unless you feel there are substantive issues on which
you’d like interim feedback, it may be better to let the pilot test in Phase 5 give you
the feedback you want and need.
We suggest that for Phase 4 you subscribe to the realistic notion that you will
deploy imperfection and then continuously improve rather than deferring deployment
for perfection. That continuous improvement is what Phase 5, Pilot Test, is all
We also have an opinion on whether to conduct those infamous, time-consuming,
unnecessary walk-throughs of each and every page (or screen, etc.) of the training
under development. These are a developer’s nightmare. A walk-through usually
degenerates into The Great Wordsmithing Contest of Arbitrary Choices and Developer
Dis-Empowerment. In our experience, very few meaningful changes occur
during Phase 4 walk-throughs. In fact, walk-throughs usually increase cycle times,
increase costs, detract value, and demean developers through the implied micromanagement of their work.
Lessons from Other Worlds. The work we’ve done over the years has given us a
good exposure to the product development process in a number of industries. We’ve
found that the world outside of training has learned a number of lessons that we can
apply to our own product development process if we’re not too proud. Indeed, the
PACT Process borrows concepts, precepts, tools, and techniques from both
product management and the quality movement. Some of the lessons we’ve learned
• Detailed planning is a must.
• Communicating to test understanding and manage expectations is critical.
• Front-end load your process with all the inputs from all of the stakeholders;
don’t rush into development before getting everyone’s “stakes” placed.
• Don’t add new players (SMEs) along the way unless absolutely necessary. They
disrupt the process and cause rework. If they must be brought on midproject,
spend a lot of time letting them know what’s gone on before, the decisions that
have been made, the tradeoffs for those decisions, and the rationales.
Conclusion. Whether you make or buy, develop or acquire, the work you do during
preceding phases of the PACT Process serves you well. And when you finish
Phase 4, the outputs you have are ready for Phase 5 – Pilot Testing. That’s the
subject of the next article on the PACT Process in the next issue of Pursuing
********** ********** **********
To see the full Spring 1994 Newsletter – please go – here.
# # #