Teaming for Training & Development Efforts

During one of my first training projects in 1979 for a building materials retailer, I had to work with several window manufacturing companies and our internal merchandising product manager to develop a video script that would lead to a video-based employee training and customer education program.

The 15-minute video program, supported by a leader’s guide and supplemental product literature and instructions, would be presented in three short segments.

· Basic Product Knowledge
· Installation Procedures/Techniques
· Materials and Tools Required for an Installation

For this effort, the manufacturers would provide all of the funding. We in the training department would produce a training/sales piece that helped us sell their products by raising the knowledge levels of our employees and also softly selling the do-it-yourself customers on the need and use of the ancillary (and higher margin) items required to get the job done correctly.

After dozens of phone conversations and seven video script iterations, I became very frustrated. Each of my “customers” pulled the script in a different way. Each demanded that their favorite sales slogans be used and edited out each others’ marketing phrases. Each person had a different view and a different agenda.

I concluded that this was a no-win scenario, and the only way I would ever get through this endless recycling adventure was to get them all in the same room and organize a process to force them to make all key decisions and select wordings they all could live with, even if that meant a meeting full of conflict and acrimony.

It did, it was, but it worked; and I became a proponent from then on for organizing my project constituencies and processing them through the nontraining design (content) decision-making. I could only lose on content decisions if I attempted to make them myself. I did not know the content that well. But I did know training.


I did not recognize it at the time, but I had inadvertently created a team. I didn’t set out to create a team; I only wanted to end the pain of running the gauntlet over and over again. I wanted a group to take over the decision-making, and I wanted them to do it simultaneously. I empowered my team within boundaries; they owned the content decisions, and I owned the design decisions. I accepted even their poorer decisions because they were my “customers” (a.k.a. stakeholders) and it was really their program, not mine. I was just the hired gun to get the job done. I didn’t own the program. They did.

I have been using this team approach on most of my projects for more than 28 years. I fought hard for my turf—method versus content—and most teams willingly conceded. After a history of being right more often than wrong, after a while I earned my teams’ respect, for they knew I was on their side. When we disagreed, my posturing was almost never seen as self-serving. I stood up and took the bullets of wrath when things went wrong, even when they knew I had fought for something else. I willingly gave away credit, for it never really belonged to me singularly. It was always a collaborative effort. It was always a team effort.

My views on teams are the same if not stronger today. Projects where we have set up teams correctly in the beginning have proven to be much more successful, where success is measured in terms of better, quicker, less costly, and greater stakeholder satisfaction. These are the earmarks of quality.

If you’ve been in this training biz for any length of time, you have probably experienced the difficulty of doing the “best training” from a training purist’s viewpoint. You’ve had difficulty getting to the right people because of the “organizational gatekeepers.” No one will give you input or do their reviews in a timely fashion. People who confirmed their attendance on Friday for Monday don’t show up on Monday. No one gets assigned content authority in areas of controversy, and therefore your content gets bogged down in political wars.


The trouble is that your project probably never was “sanctioned” from on high. If you attempt to invoke the names of the powers that be, you are either lying or are mentioning someone’s name that is not in “my” chain of command, so go away. You cannot get your project moved up on everyone’s priority list—not that you should, because “this is training and it is important.” You may have no credibility with the important power brokers.

You are resigned to deal with the people I refer to as the “Friends of Training.” You know them. They always have time for you when no one else does. Their organizations always send them to the “nuisance” meetings, and training is sometimes viewed as a nuisance. Friends of Training never ask the tough questions. They are easy to work with. Friends of Training typically have no power base, little credibility, and if their names show up in your report or on the LCD presentations, you will suffer an immediate case of “lack of credibility” for what you are trying to do.

Avoid the Friends of Training like the plague!! At least in public. Go for the skeptics, the tough inquisitors, those who think about the business first and training second.

Sometimes, but not often, one team is all you need. But more often than not, in complex organizations where the trainees work in multiple locations and where the target audience is not so homogeneous, you’ll probably be better served by a multiple set of teams.

I won’t say that teaming makes things perfect or easier. But I do feel it moves most of the pain of projects to the front end, thereby reducing downstream sideswipes, excessive and predictable rework, and cycle time and cost. If you only need one team, you can roll all of the roles defined below into your one team. Call your team anything you like. Please don’t get hung up on your favorite label versus mine.

The typical teams involved in a complex training development project might include the following:

· Project Steering Team
· Analysis Team(s)
· Design Team
· Training Development Work Team
· Pilot-Test Team

The Project Steering Team is a group assembled for just this project, or a series of projects. It should include all of your stakeholders, at the highest level appropriate—people at the decision-making levels. Lower level folks who have been empowered will work as the Project Steering Team only if they truly have been empowered. This team is typically responsible for

· Owning the project
· Reviewing and critiquing the Project Plan and redirecting the project
· Selecting all project participants for the Analysis and Design Teams
· Reviewing and providing feedback for all project documents and outputs
· Establishing development/acquisition priorities
· Approving or redirecting the implementation plan

The Analysis Team(s) are composed of master performers, subject matter experts, supervisors/managers of the target audience, and possibly some strong new-hires (who won’t be intimidated by the experienced folks). This team is typically responsible for providing input related to

· Task, job, or process performance
· Knowledge and skill requirements
· Target audience demographic data
· Assessments of existing training

The Design Team is ideally composed of two or three members of the Analysis Team. This team is typically responsible for

· Creating design concepts and criteria
· Providing input and feedback for the preliminary design
· Reviewing the final design

The Training Development Work Team (ISD folks) is typically responsible for

· Preparing the Project Plan
· Selecting and recruiting the Project Steering Team
· Preparing for and conducting all project activities and meetings
· Facilitating the meetings of all other teams
· Creating the design
· Developing all training materials
· Preparing all other project documentation and reports
· Presenting all project intentions and results

The Pilot-Test Team members are the handpicked participants of the first run of the training program, the Pilot Test. The team should have a balance of target audience representatives and management representatives.

Target audience reps are members of the target audience and will help us measure whether learning does occur in the session. Management representatives are management’s spies, invited specifically to participate fully in the session as a trainee, experience the entire event, and help determine whether the learning that occurred was indeed appropriate learning. They can also report back to management whether this effort was good or bad. They are typically going to be there anyway, and I like to know who they are so I may segregate their feedback—they will evaluate a course differently than members of the target audience will.

The most important of these teams is the Project Steering Team. A Project Steering Team can make or break your project. They must be the representatives of all of your stakeholders. If you miss a key stakeholder when you attempt to set up this team, they will usually make their presence known to you later—much later and with significant negative impact on rework, cycle time, and costs. It’s so much better to front-end load your own efforts to get the stakeholders identified and on board as your Project Steering Team sooner than later. But a Project Steering Team with powerful individuals presents a double-edged sword. Many trainers will fall on this sword, never to dance again.

The most important reason you will want to form a Project Steering Team, as frightening as the prospect might be for the trainer weak of heart, is that once you get the Project Steering Team behind you, everything else (gaining commitments and cooperation from all other project participants) will become much easier. It can be frightening, because the high-level players you really want on this team are going to be the hardest group you’ve ever tried to work with and control.

You should probably use the word “guide” when you discuss this with your teams, but I will use the word “control” here, because that is what you are really trying to do—control the process (not the content), and it’s all for their benefit! It’s their course; it’s their performance improvement or lack of it that will result from the training. They should own the content decisions and you should own and control the process or method for getting the content identified. By content I mean selection of target audience(s), setting terminal objectives, scope of training, actual training information/demonstrations/exercises, etc.

The Project Steering Team needs to be composed of the highest level folks who may benefit from or be impacted by the results of the project and the conduct of the project. They will be hard to “guide.” They will have silo-hardened ideas/concepts/biases and demands. Only heavy, rational logic can sway them. Your best bet is to anticipate their view and “head it off at the pass.” Anticipate their views, identify the pros and cons, list all other alternatives, rank them, and be prepared to answer tough questions with crystal clear logic, poise, and determination.

Don’t be afraid to be confronted or yelled at. This is not a job for a training wimp. You must be a business professional. You must do your homework and do it well. We don’t do training for training’s sake, we do it because it makes good business sense. It has to have a return on the investment. Otherwise, don’t do it!

The key to the assembly of a powerful Project Steering Team may be to find a powerful agent of respect and power that you’ll need to recruit to become your project champion. Once you have identified this person, you must first sell them on or negotiate with them everything about your plan.

Here’s where a detailed “draft” Project Plan becomes critical! Be prepared to have changes made to your project concepts and plan details. Be prepared to defend your views with the logic of business versus the logic of training.

The Project Steering Team chairperson, the project champion, must be selected with great care. Organizational politics are like land mines. They will do more damage than just trip you up. You should navigate this killing field with great care. You may even need a mentor as a guide in selecting project champion candidates.

Once you have them identified, you must approach and sell them. You must demonstrate an understanding of the performance situation that the training project is to address, of its implications and the problem magnitude (again in the business terms of the “cost of nonconformance to quality standards” and not training terms—“they need training”), and what the payoff is for meeting the need. Most critically, you must demonstrate the return on investment (ROI) factors.

Few people in the upper ranks of the business enterprise are interested in learning all the ins and outs of training theory and practice. They don’t have the time, the desire, or the patience for it. They make business decisions based on the harsh realities of business, especially ROI. Be prepared to sway with the demands of business decision-making versus the demands of training decision-making.

Working with teams in developing training is the same as working with any product development team. You must be well organized, flexible, and very business minded.

Training for training’s sake doesn’t cut it in the business world.

Training for the sake of the business does.


# # #

One comment on “Teaming for Training & Development Efforts

  1. Pingback: Guy W. Wallace’s PACT Facilitation Guidelines: Series Wrap Up & Close | EPPIC - Pursuing Performance

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.