I wrote the full article that this is excerpted from back in 1999…
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’ slogans. 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 14 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 overhead transparencies, 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, 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 most important of all of these teams is the PST – Project Steering Team – the clients AND key stakeholders.
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 for whatever may come out of the analysis and design efforts.
Lower level folks who have been empowered will well 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
When the effort runs into issues, this team resolves them. When the effort runs into needs, this team resources them.
Perhaps a PST isn’t needed for every effort – especially if you have worked with this group before – and they now trust you. But when the going gets tough, it’s good to have this group on the project path with you – experiencing it all from the git-go.
# # #