I have a theoretical question concerning documenting the steps (procedures) for tasks and I'd like some opinions.

Let's say you have assembled a small group of subject matter experts in a workshop setting to do a job and task analysis for a particular job for the purpose of designing training for new hires.

Using a group consensus approach, the group has identified all of the duties and tasks associated with the job. They have classified all tasks with respect to difficulty, frequency and criticality. They have identified the performance standards and conditions for all tasks.

However, there are no written procedures for any of the tasks. Since the assembled group is composed of subject matter experts, they have the knowledge to develop and document the procedural steps.

Here's my question:

Would you proceed to develop written procedures for all tasks comprising a job as a part of this workshop, or would you divide up the tasks with assignments to develop the procedures, individually, outside the meeting?

Hi Pete,
SME's are experts at identifying the procedures within a task but you might find individual inconsistencies in their delivery or outcome. When developing procedures some might get very detailed while others only outline the high points. I would continue to develop the procedures as a group rather than dividing up the tasks to work on individually. That way everyone is in agreement with the procedures. Inconsistent procedures will result in inconsistent training.

Hi Pete,
I agree with Bravo. If the SMEs can commit the time I would attempt to have them document the procedures for all tasks comprising a job during the workshop. Then you can at least come to some sort of agreement as to the format and how much information is needed.

I am struggling with this very topic now. Our proprietary application is being redesigned and the app is used across multiple business segments by hundreds of employees. We are implementing application training for the first time. Not every dept. has job roles/functions documented.
We need to educate the business users as to why we need job/task information from them in order to create an effective and relevant training curriculum. I'm concerned they will resist because of the level of effort and time needed to gather this data.

JP

Hi Pete,

I do this exact thing with groups all the time - workshops that teach SMEs how to do the team-based task analysis and write the procedures. It is literally impossible to write very many procedures in the workshop. The only thing you can accomplish in the workshop is to get them to produce two to four decent procedures during a two day workshop. Most groups end up with 50 -100 tasks (at least) if they do a good job at identifying all the tasks. The main thing to come from the workshop is the process and "how-to's" of writing step-by-step procedures that are useful for training purposes. Most teams end up spending dedicated time writing once they return to the job.

I would not ever advise a company to have individuals attempt to write the procedures. As Bravo said, there will be no consistency in task accomplishment or in the way the task is taught. And people are not likely to even use the procedures that an individual writes. But they will use procedures put together by a team. Another reason that individuals are a bad idea is because it takes them, on average, 4 times longer than teams. And lastly, teams write much better procedures that become accepted as best practices. But the greatest advantage of using teams to do the writing is because they learn a lot in the process. Quite often they end up realizing the "old" way was not very efficient or effective and re-do the whole procedure. It also does wonders for their morale.

The teams should have a facilitator to guide the process and to keep them on track - but NOT to contribute to the content. Preferably someone other than a SME.

One last thing - I would strongly advise that the teams have at least one person who is not a SME as a team member. That person's job is to question anything that is not clear to them - terminology, process, etc. That is really the only way the team can make sure that the procedures are useful for training and are written at the right level of detail for the typical learner. If you already have new hires on board, have them join a team. It's a great way to learn what the job is all about and makes them feel useful at the same time. And be sure to have the teams verify every single task on site before attempting to use them for training.

There are two words that are just screaming out here that need to be said:

TECHNICAL WRITER

and/or

BUSINESS ANALYST

(or team them together for best results)

For the very same reasons I would never just throw a SME into the classroom just because they know the subject matter, I would never appoint a SME to write procedural documentation.