Last Minute
Too much of the preparation was left to the day itself. That was not just the people who were sorting it out technically but also me! A course that relies on a technical fix needs to be tested for at some stage at least a couple of days before hand. This was just one such course. Lack of doing this showed in the fact the instructors PC did not have the software on and the fact I did not give out the correct names and passwords to the special accounts.
I have a real blind spot where courses are concerned and nearly always end up doing things at the last minute. This time I had the course notes printed but I needed to print the username and passwords at the last minute. I had not given time to thinking how to do this and ended up doing it in a hurry. I therefore messed it up.
Bussed in teaching
Right there was a communication problem. I discovered a week beforehand students were being told that they were getting a work shop when in actual fact they were getting a very full training. I have taught the course six times in the last year and it takes 2.5 hours to cover what I cover! I had two hours to do that. The students were not going to get to work on their own projects in that time and they really should not have had the expectation that they could do so.
The problem with this is that the training happens in a wider context but nobody has thought really about the integration of the use of computer programs into the wider course. Rather they have employed an "expert" to give the training and that has failed to meet the requirements of the course.
What is equally troubling is the students had expectations of me to teach them things that really are not the task of the computer software expert. I teach people how to use the software. I do not teach them how to construct their research project.
The separation of software training from research methodology
This is the real biggie. The course basically is in three separate parts and those parts do not hand together. There is a number of methodology lectures which talk around collecting and analysing specific types of qualitative data. There is the "workshop" I give on using software to support doing research. Finally there is the student project when they have to show they have engaged with doing some sort of qualitative research. None of the three hangs with any of the other.
At present the focus of the course is on the style of data collected. Now most qualitative researchers collect multiple sorts of data. So at one level it is sensible on the other hand it puts all the emphasis on the style of gathering data. The analysis is often treated as self explanatory. It isn't.
Secondly software has developed, today it deals with working right from the recording through to writing the report. Using software is no longer just around coding. The standard line these days is that teaching software needs to be fully integrated into the course on qualitative research methods. That means you need to run sessions on organising data, transcribing interviews, coding , reviewing coding and checking through, developing theory and exploring data and finally reporting. These sessions probably work best if the first hour is spent with someone doing the theory and the second hour is spent with students actually getting a demonstration and working in detail. All these need a sound theoretical underpinning.
Conclusion
- I need to explore ways in which I can discipline myself not to be so last minute
- I need to be clear about what I am offering and start much earlier the talk about what they are expecting people to do
- Really the course needs a redesign to increase emphasis on the analytic questions that a qualitative researcher is faced with so as to enable students to know what they are doing when taught to do something with the software.
No comments:
Post a Comment