Two I specfically like are Evan Frendo's ideas on his blog, and Claire Hart, who is a particularly innovative trainer. Her student expectations exercise is great. Both are outstanding trainers.
Then after reading from Harmer and Emmerson and Scrivener I realized that all of these methods were still using the learner as the main resource for the needs. I guess I just wasn't asking the right questions because all I got was "I make presentations." and "I don't have the words." Although I was getting information about their jobs, it wasn't much information to really work with. Looking through the presentations from the BESIG meeting in Dubrovnik I realized that many of us are having trouble with this.
So here is my new method for needs analysis and it seems to give me more insight and reduce the number of surprises as the the course progresses. The advantage is that it gets the learner talking about something they don't know (what they lack) and onto something they know a lot about (what happens).
Communicative Event Analysis
The first thing we do is sit down and talk about the department/team. What is the function of the team, what are the inputs and outputs? Based on my knowledge of business practices I have a pretty good idea of what is happening. Second, I want to find out the communicative events which facilitate this knowledge transfer. Are we talking about weekly meetings, telephone calls, emails, forms, etc.? Some outputs will have one event ("a form arrives, we read it and forward it to the correct person"), some have many ("we meet with the customer and then work with the R&D department to find a solution, then we propose the solution to the customer").
My goals is to break down all the contacts into events. Once I have the events, we start working out the nature of the events, the more detail the better. So if they have a web meeting every month, I want to know the agenda. Is the meeting focused on updates and past actions? Is it a time for the management to delegate tasks? Is it a forward looking meeting to solve problems? etc. We will also look at reoccuring tasks and one-time events. This can help me devise a schedule to give them the skills needed when they need it.
We will break down every communicative event in this way. At this point, I have a list of skills, a context to gather lexis, a list of functions which occur regularly, and even an idea of which grammar the person is most likely to need. It also gives me an idea of where the communication bottlenecks are in the department.
Finally, I will ask who does all this stuff. Clearly, the student will not do it all. This leads to a discussion of which tasks the student has the most trouble with. Which emails are the most difficult to write? Which phone calls are the toughest to handle? Do you speak more in this meeting or in this meeting? Why? I can then see clearly if the learner's colleagues are handling more of the difficult communication tasks because they are better at English. By identifying the colleagues' tasks, I can help teams eliminate the communication bottlenecks.
At the end of the session I have several priorities:
1. Current tasks the learner cannot perform. (And testing the ones they say they can do)
2. Tasks the learner would like to perform.
3. Tasks the learner should be able to perform. (often similar to 2)
4. Tasks surrounding the department function. (Tasks the learner might need to perform in the future.)
Now, I can go back, find resources, plan a syllabus, combine learning objectives, disguise overly dry parts, and shape the program. This systems approach to needs analysis allows me to give them exactly what they need.
Some examples of information on a communicative event.
Email from International Sales -
The learner often receives questions from the international sales to find out if a product can be changed for a special customer. They also want to know how long the change will take, and what price they should charge for the product.
Language foci -
- product specifications
- passive (present and infinite)
- product uses (inteded for, for use in, etc.)
- modals of ability (it cannot be used for)
- describing a process (it must be tested)
- expressing probability (talking about the future without making promises)
The learner works on a virtual project team and has a one hour web meeting to go around and give progress reports on their sub-projects. The project leader then asks questions. Each sub-project leader goes in turn and the end of the meeting is an open discussion about outstanding problems or future concerns.
- Common opening sentences, giving a concise introduction
- Talking about schedules and resources (by Friday, take, last, need, enough, too)
- Giving an update (we finished or we have finished)
- Giving reasons why (because, due to, because of, as a result)
- Describing current activities (We are doing...)
- Making predictions about future activities (might be able to, will definitely)
- Talking about consquences (If... then)
- Identifying and answering questions
- Stating an opinion
- Making suggestions