I lead a team that provides learning technology support for a range of undergraduate and postgraduate degree programmes. This includes a significant amount of work getting modules ready for new academic sessions.
Eleven years ago this meant an extremely busy summer ‘rolling over’ several hundred modules for the start of a new academic year.
Things changed in 2016 when we moved to a new model in which a programme could have up to four academic start points in a year. The flexibility for students is fantastic. You want to start your degree in April, no problem! You don’t? How about July, October, or January? Not all of our new programmes use all four available ‘sessions’, but all of our new programmes do use at least two sessions.
What does this mean for my team? It means more module rollovers, and more often.
But it gets better (for students, that is) because a module developed in 2022 (in comparison to one developed in 2011) is more interactive/interesting/varied… what’s the word I’m looking for… COMPLICATED!
Once upon a time rollover (in Moodle, as we’re Moodlers) meant replication of content, reset, and hand over to the academic. But now there are a long list of content items that need specific interventions: linking to a Pearson lab, sending student lists to Kortext, populating a wiki with some starter content, and so much more.
Administration of work, that’s the point. Approximately 800 modules that each run between one and four times a year, each of which may (or may not) need some (all, or none) of 20-30 different things doing to them. Toto, these aren’t our usual rollovers! This process needs a name that shows it greater respect. These are deployments! And deployments need some serious administration to power them.
Maybe you can see where this is going. The humble spreadsheet. So we have a spreadsheet that lists every module available, every session in which it might run, and detail tracking each iteration of when it actually does run. Keeping it up to date is so much fun! Especially when X module might run in July but not April last year, and April but not July this year – does it alternate in this way consistently, not at all!
So far we’re just tracking what runs, when. But for a given session (say October 22), what do those 123 modules need done to them? Cue another spreadsheet to list what needs to be done, and another (with a tab for each session) to track that it has been done!
Spreadsheets are complex and wild creatures. We think we’ve tamed them, but they live their own lives outside of our control. Before you know it you have 123 rows (one per module) and a HUNDRED columns to track information, identifiers, and potential ‘configurable items’. Twelve thousand three hundred cells of glorious technicolour. A simple glance across the spreadsheet can tell you perfectly how deployment progress is going… if the answer you’re looking for is best represented by a toddler returning from a birthday party having eaten too many skittles and has thrown up all over the Jackson Pollock rug.
Preparing a 123×100 spreadsheet in anticipation of a new session is serious business. It has to be perfect, a mistake here means a deployment goes wrong. It easily takes a week or more to get this right – with constant interruptions because work doesn’t stop to let you work on planning work, right?
If there’s one thing I can’t stand, its boring work. Nothing worse! Except for boring work which surely should have already have been brutally unalived by the battle-axe of automation! Cue obligatory XKCD!
While the XKCD chart can be read in jest, let’s take it seriously. If a task takes a day to do, once a year, we should invest 5 days automating it. Consequently if the task takes 5 days to do and is done 4 times a year, that’s 100 days of time we should invest in automating it.
We’re finally getting to a point! But I had to suffer to get here, so the above is your version of feeling my pain.
My solution is a web-based app linked to a database that can hold all the information the spreadsheets held, contain all the logic for how the information should be put together, and provide interactivity in tracking the whole deployment lifecycle.
Thus the Deployment Web App was born. Called DepWA when I want to sound obscure. Called Deux Points when I want to sound both obscure and pretentious.
- A variety of web-pages to manage the bulk to the DB information (lists of programmes, modules, possible configuration items, the specific configuration items each module requires, and the pattern in which modules run from available sessions)
- A planning page which shows which modules are running in the selected session and what they need done to them
- Tick boxes against each item so they can be marked off as they are done (changes pushed automatically to the DB
- All data able to be exported to CSV for any use cases that need to get back to a spreadsheet
- A percentage progress selector to record how far through deployment each module is
- A dashboard showing a doughnut chart of deployment progress so colleagues have a single graphical view to minimise the “are we there yet?” requests which become increasingly frantic as time goes by
- Powered by editable datatables, bookstrap, jquery, chart.js, an array of other almost random selection of javascript libraries, MySQL, PHP, blood, sweat, tears, and the joy of spending time creating something that eliminates significant volumes of boring work
- Best of all, it didn’t take anywhere near 100 days to build
If you don’t know a bootstrap from a shoelace nor a jquery from a weary colleague named Jake, what are you supposed to do?
Are there off-the-shelf software products that delivery a perfectly bespoke experience without six months plus of consultancy? If there are, can your business afford them?
Do management trawl through every department’s administrative processes and identify automation oportunities and hire developers? Would that even be cost effective versus just getting in a temp to mindlessly smash their head against a handful of spreadsheets for a few weeks a year?
If you’ll forgive me waxing hyperbolic… We used to be able to get away with knowing a few things in Word and Excel for the narrow world in which we worked. Now we’re expected to juggle sharepoint groups, teams channels/chats, live online collaboration in those Word/Excel documents, and more. Perhaps even this isn’t enough for the present, let alone the future. To be effective in our workplaces do more of us need to be part-time developers? Will knowing your LAMP stack be as required a job skill as an excel vlookup?
Alternatively, is much of our shit work inevitable? Is it simply financially optimal for a business to accept this rather than invest in the processes of those that have to do it? Are there reasonable solutions to these problems, or do we just need to accept and suffer boring repetetive work? Work is work, is it important if we don’t enjoy all aspects of it?
In an ideal world perhaps we all ought to be conversant in a handful of different scripting languages, and be able to build our own automated tools and processes. We improve our work life and our business benefits, is that a win-win? What does a business look like that invests in either our skills to solve these problems for ourselves, or in solving them for us?
Imagine an agile workforce that isn’t traditionally stratified into the many different skills to carry out very specific, intricate, boring processes. A pool of problem solvers that cycle through the business engaging in all levels of work. They identify inefficient manual processes, opportunities for automation and improvement, and build a bespoke administrative toolchain to improve both the experience of colleagues and the effectiveness of the business. The goal isn’t to use less labour, but to do so much more. Put training in place to level up colleagues so not only do you build them a macro, a web tool, a bash script, etc. but you teach them to understand it enough to troubleshoot and maintain it. With enough training/aptitude they join the pool of problem solvers. Is there scope for a digital revolution of our labour? Where a worker isn’t a specific shape/size of cog getting ground down against the friction of their work function, but a silicon chip reprogramming themselves to be ever more effective and mentally invested in their work?
I’m getting carried away. But I’ve automated away some of my team’s tedious work, feeling great about it, and wanted to share.
Stephen Ogden
Senior Manager Learning Technologies