The sun is shining here and our daughters are bouncing on the trampoline outside. It’s week 9 of ocTEL, and although I have to confess to some MOOC weariness I’m determined to be one of the 4% who make it to the end (as Damon Albarn almost said).

This week we looked at what makes a project succeed or fail. Thomas Cochrane’s (2012) article reflected on the critical factors in the success or failure of m-learning projects, while in the webinar two researchers from Imperial College London described their experiences of changing VLE and moving to a blended learning model.

I’m relatively new to the pedagogy lark, so if I tried to apply these lessons to my own experience I’d have to look slightly further back at a project I managed to build a new publishing system. I was working with a developer to convert around 80 courses from XML to Word and construct a system that would allow us to publish to print, HTML and ebook in-house quickly and easily. To add another level of difficulty, the courses had been translated into five languages and many were undergoing significant change at the time. So, just to be clear, this example is about changing the way we produced the course materials, not changing the instructional design – but I think some of the lessons I learned are appropriate.

The project was long (about 3 years), difficult and risky – I still remember the feeling of giddy panic as I updated the university’s risk register – but we got there in the end. The developer did a great job, we met the deadline and the new materials were successful.

Successes

• The planning stage was fairly [ahem] short (see below), but there was a proper acceptance testing process. Freelance checkers logged into an online bug-tracking system, which allowed me to track, allocate and prioritise tasks right through to completion. This was a must, as the people working on the project were located throughout the UK and Europe.
• Drawing up a proper contract with the developer helped to focus minds on what we wanted to do and by when, and gave us some comeback in the event of anything going drastically wrong.
• The course materials were in a state of flux, but ‘freezing’ them for the duration of the project meant that sojurns in version control hell were mercifully short-lived.

Failures

• In the week 9 webinar, the ICL researchers described a 1-year process of gathering requirements and drawing up a specification. Unfortunately I didn’t have this luxury, so the planning process was based largely on instinct and the good advice of a few key individuals. If I was doing it again I’d draw up a full project plan at the beginning, even if it caused a delay initially.
• At the beginning of the project (early 2008), the authors told me they had no intention of updating the course materials anytime soon. Then the financial world collapsed, requiring not so much the amendment of business theories but the revision of examples as previously successful companies went under or were bailed out. The pressure to update as soon as possible made life difficult. I’m not sure what I could have done to anticipate this, other than taking the initial comments about not updating with a pinch of salt.
• For all my focus on acceptance testing and quality, I have to admit that I didn’t consult the students about the look of the new materials. As soon as the new books were published I received irate emails from students about how much they hated the new font. (We had to change it; people get very excited about fonts, I’ve learned.) So a big lesson learned there: ask the students.