1 Not inadvisedly or lightly: Planning VLE DowntimeKate Wright, E-learning Group Manager, Aberystwyth University My name is Kate Wright and I’m the E-learning Manager at Aberystwyth University. I’ve been working with Blackboard since 2002 and if anyone asked what the hardest part of my job is I would say it’s planning maintenance time. I’m not going to be talking about dealing with unplanned outages or disaster planning – those are entirely different talks. I’m also not going to be talking about the technical aspects of maintenance or upgrading (that’s someone else’s job). What I’m going to be talking about is the soft side of downtime planning – the hearts and minds work. So today’s presentation is going to feature wedding pictures – a lot of wedding pictures! I have an extended metaphor for planning VLE downtime, which may just get stretched a little too far. But let’s go with it. So I came up with this metaphor during our winter downtime period; we have three scheduled periods each year, one at Christmas / New Year, one at Easter (which we never use) and one in the summer. The first two are 2 days each and the last is 4. Having moved the downtime period from just before the Christmas vacation to after the January exams (because of complaints), we got a whole new set of complaints. I was writing an and the phrase ‘not inadvisedly or lightly’ came into my head. A quick Google search told me that wording is in the Anglican Book of Common prayer and is about how one should enter into a marriage – and the metaphor grew! I’ve blogged about this on our Nexus In my experience, planning Blackboard downtime is as involved and stressful as planning a wedding – but without the cake, hats and party afterwards! Photo by Blavou Weddding Photography (http://blavou.co) used from Flickr under Creative Commons (https://flic.kr/p/FcC28b)

2 Who to Invite? So – the first thing to do is decide who is coming – or in the case of the VLE, who needs to know first and agree the date. When the VLE wasn’t so heavily used, we just set dates ourselves. Not many people used it, we knew who they were and no-one really relied on Blackboard for much. But as time has gone on the VLE has become more and more important (and that’s probably the case for some of the systems you work with too). In a way we’re victims of our own success. We began to realise that we had to start asking people when to take Blackboard out of service. When we started this we consulted with our E-learning Steering Group – they agreed a broad period of time, we selected a couple of dates and they signed off on them – job done. For a while - Now – I’m a big West Wing fan, so in the spirit of Posse Comitatus we had our gang of eight; In the US the  Gang of Eight is a colloquial term for a set of eight leaders within the United States Congress who are briefed on classified intelligence matters by the executive branch (in The West Wing they are the ones who know about an assassination attempt on Sharif – if you’ve not seen it, it’s a great episode) In Aberystwyth this was a small group of senior and influential staff who we considered had a good oversight of the running of the university to ensure that they would spot any potential problems. The Gang worked for a while, but gradually more things started happening – summer projects that people don’t realise were using Blackboard, more distance learning etc etc. It became clear that the Gang had to grow. Now it’s a bigger group – there are 35 people on it, and they range from directors of UG and PG studies in our institutes, to admin staff supporting DL to our branch campus. And they all get a say in when the down-time takes place. Theoretically they also play their part in spreading the word, but this isn’t always the case. So, at this point the diaries come out, 35 people all have their say, and we attempt to find a date – a date that suits them and also suits the staff undertaking the work (who of course need to take leave, see their families etc etc). There are a few things we try and avoid – we don’t finish maintenance on Fridays – there’s nothing worse that discovering a problem on a Saturday afternoon (especially if the Rugby’s on – who wants to make that call?!) We also have tried to avoid working over the weekend, although we are moving more towards some part of the work being done over the weekend. Often other staff will expect us to work over the weekend and we have to explain that maintenance required more than one person – particularly if things don’t get well. You may need a networking person, or a server person and if they’re on holiday things can rapidly go downhill. And of course we may need to contact Blackboard, which is harder over the weekend (or at Christmas!). Given that system staff often work on multiple projects there are other times we have to avoid – so in the past we have had to avoid Graduation (because our systems staff help out with the Graduation ceremony streaming), we don’t do any maintenance work at all during clearing, and we avoid our resit period. This takes a long time … a very long time, and undoubtedly someone isn’t going to happy. Fortunately, among our 35 we have a number who are very understanding and willing to compromise; with enough time and planning they are willing to change things and work flexibly. We love these people – they make our lives so much easier. And the reason they’re like that? Because they understand how hard it is to plan – we’ve spent time with them, we’ve explained the issues and we’ve had a dialogue so now they know the frustration, but they understand the importance of what we’re doing … Photo by Stephanie Chapman used from Flickr under Creative Commons (https://flic.kr/p/7CgE83)

3 Once a date is agreed, we then start our publicity on the downtimeOnce a date is agreed, we then start our publicity on the downtime. This will invariably flush out someone who hasn’t been consulted but has a pressing reason for Blackboard not being out of service. Sometimes this is pressing enough to go back to the drawing board and consult on a new date, sometimes we just have to explain to the person in question that we can’t change the date. It’s a judgement call based on how many students are affected, the depth of the impact etc. Often we just have to say no and offer some options. One of the problems that we face is that with so many other systems hooking into the VLE it’s not enough to say that Blackboard is out of service – you need to remember all those other things that use Blackboard as authentication, or can only be used via Blackboard. Two prime examples of this are Panopto and Turnitin. Initially we used to advertise that Blackboard was out of service but staff didn’t realise that this meant that they couldn’t authenticate with Blackboard to record with Panopto. We’ve had to be more specific about what services would be impacted. One of the things that we are working on at the moment is finding other ways of accessing some services should it be required. So we’ve been thinking about how to access Panopto for offline recording if you can’t authenticate as well as access to Turnitin. Turnitin is probably the most difficult – staff can use the iPad marking app if they are organised in advance. They can also login via turnitinuk.com to view and download papers (but they can’t mark). None of these options are particularly satisfactory but they can help people get out of a spot if they’ve forgotten. We’re now advising staff and students to think in advance and contact us if they want some advice. We try and get people to add the date to their own calendars and plan around it – we know that downtime on any system is irritating, but it’s vital. Save the Date Photo by Sarah Parrott used from Flickr under Creative Commons (https://flic.kr/p/5FFz28)

4 Fix the Roof While the Sun ShinesAnd speaking of vital – I’m going to break the metaphor for a while. This is how we explain downtime to people who want to listen – it’s a bit like mending a roof. Best to do it in the sunshine rather than when it’s raining. Planned maintenance is always, always better than the unplanned kind. It’s a really hard concept for people to understand – why would you take something out of service, something we rely on? I think it’s worse when they can’t see that anything’s changed. This is particularly the case if it’s something infrastructure related. If they can see new features, or an annoying bug has been fixed then they see the value. So we try and use our comms to tell people what’s changed – even if it’s infrastructure we can explain that it will make it quicker, more secure, more robust etc etc. We may try and tie it back to problems we’ve experienced in the past, and if we can tell staff that a bug they have experienced has been fixed so much the better. And of course some work is actually unrelated to the Blackboard system at all – that is really the most difficult to explain. So it’s very important to be involved with the planning of that work. This is the kind of server level maintenance when lots of systems are affected. If you’re lucky then the teams working on that know to talk to the ‘owners’ of the systems – if you’re unlucky someone decides to patch the server at an inopportune time for you (but not for them!). We’re really lucky, and have worked very hard to foster good relations with our systems staff. Often they aren’t as aware of the academic timetable as those of us who work directly with staff. Good communications between back office staff and front line support is vital and something that I would encourage you to develop. Photo by Chris used from Flickr under Creative Commons (https://flic.kr/p/in94N)

5 The Wedding Planner But back to the metaphor … If we’re the wedding planners – what do we do to plan? Planning for downtime has become a much bigger issue as reliance on the system has increased. An out to a few people just doesn’t cut it any more. So, what do we do at Aber? A lot of approaches – obviously is a big thing, and for the first time this year we have sent round an all users . All users s are generally only used for very important issues (including evacuating buildings due to inclement weather). But we’ve judged that the VLE is now so central to the life of the university that it warrants this level of communication It means that lots of people who never use Blackboard are now aware of the downtime, but it should mean that there is no excuse not to know. We used to get a lot of complaints that messages we circulated to key contacts weren’t getting forwarded, so now everyone gets one. We’ll be doing this a month and then a week before the downtime, but we know that people don’t always read and inwardly digest their mail … We’ve added it to the main University calendar and encourage staff to put a reminder in their own calendars – we use Facebook and Twitter and our internal comms. We also put information into Blackboard using Community Engagement – my favourite one of these is our ‘24’ clock, which gives a countdown to downtime from about 24 hours before we take the system down. The information goes into our signatures so every time we send a message people see it. And this is all before we even start the testing (which is another talk altogether!!) Photo by Natasha Mileshina used from Flickr under Creative Commons (https://flic.kr/p/9jphcU)

6 But what if things go wrong?What if things go wrong? But of course, things still go wrong – someone doesn’t know, downtime runs over and tempers get heated … We try and mitigate some of this by planning more time than we’ll need, so if it goes well we can get things up early and if they don’t we don’t run over. We try not to change the dates if someone complains, as this is more confusing for all concerned. And we stand by the phones. Often the fall-out from downtime is worse than the actual time itself, and it becomes a problem when we spend more time explaining than actually testing the upgrade. And I know that e-learning staff have to try very hard not to be part of the problem – it’s too easy to pace up and down behind the chair of a system admin saying ‘ how much longer?’. We have to be disciplined to make sure that we don’t make things worse. I know from experience that this is hard when things don’t go too well, because we’re often try to communicate with vendors as well as our users. We’re on hand to explain all the reasons for downtime, explain what we’ve done in terms of comms, calm ruffled feathers and give people options in the meantime. And if all else fails we sympathise, empathise (and sometimes apologise). We make sure that everyone who has complained gets a personal message when the systems are back up and running. We put information into Blackboard, we use key contacts to try and get the word out. Of course, there’s always someone who doesn’t know, but all we can do is try our best. And I’m sure you all have other ways of doing it, so I’d be interested in hearing the strategies that you use. One thing that I haven't talked about is communicating downtime (planned or otherwise) on hosted systems – at least with internally hosted ones we have some say and are involved in the planning. Hosted services is a whole new issue and one that we’re still grappling with. While it might seem an attractive proposition to be able to blame someone else, I feel actually worse only being able to say ‘they did it, it’s not our fault’. If people don’t understand why we do maintenance, then its even harder to explain why a company in another country is choosing this time. But I’d be really interested in know how those of you who work with lots of hosted systems deal with this. So that’s the wedding metaphor stretched to it’s limits; hopefully this gives some insight into the planning and work that we in Aber, and may either have give you new ideas or you’ve got some ideas and methods that you can share with me. So over to you … Photo by photosavvy used from Flickr under Creative Commons (https://flic.kr/p/4F1eG5)