Running to catch up I had some thoughts about last weeks #OcTEL, there was an interesting paper looking at some of the project that had failed and drawing 6 critical success factors for mobile web projects.
- The pedagogical integration of the technology into the course and assessment.
- Lecturer modelling of the pedagogical use of the tools.
- Creating a supportive learning community.
- Appropriate choice of mobile devices and web 2.0 social software.
- The need for technological and pedagogical support for matching the unique affordances of mobile web 2.0 with social constructivist learning paradigms.
- Creating sustained interaction that explicitly scaffolds the development of ontological shifts, that is the reconceptualisation of what it means to teach and learn within social constructivist paradigms, both for the lecturers and the students. The use of a structured and sustained intentional community of practice around each project was found to facilitate these ontological shifts.
Now we were meant to look back at one of our projects and use this to evaluate the key failures and successes of the project. I didnt do this!
Instead I looked at the 6 factors and thought, I think I can do better than that or at least explain it in a way that is easier to understand. A year or so back I developed “Gliddon’s Hierarchy of Technology Enhanced Learning”
You can work your way up the levels in this and use it to determine what the potential risks are to your project (just add them to your risk matrix as you consider them).
Looking at the 3 projects identified in the paper
- Diploma of Landscape Design 2008 this failed at the Training/Culture level, students did not attend training and they were not familiar with the tasks expected. Serious consideration should have been given to cancelling the project when students failed to attend training. It also had some issues at the reliability/usability level as the kit was to complicated for some of the students.
- Bachelor of Architecture 2009 this had problems at the Recognition level, with the senior member of staff not seeing the project as worthwhile or giving the students credit for engaging. It is interesting that it was possible to achieve some success with students choosing to do it as optional. I would suggest this is because with the lower levels being met some students provided their own recognition because the project had worth in their own opinion
- Bachelor of Computing 2010 this was again problems at the Training/Culture level although this time the problem was with the staff. With staff showing little interest in the changes required by the project and the training attached, the project should have been reconsidered. When evidence emerged of staff reverting to the old curriculum instead of engaging with the new it might have been time to abandon the project.
I think the researcher had done some fantastic work in the above projects often struggling on against the odds and achieving some success despite the problems (and lets be honest who hasn’t responded to problems in a project by working harder to solve them). I hope that for some people using my Hierarchy may give them the opportunity to identify problems early enough to either change them or abandon the project before to much effort is spent.