This post is a quick summary of a requirements workshop that took place at the Manchester student support and resource centre (SRSC) towards the end of January 2019. Also, at the end of his blog post is a short summary of a discussion and presentation that took place at the School of Computing and Communications away day, that took place in February.
The January event was originally called a ‘participatory design workshop’, but if the truth is told, we didn’t actually get as far as doing any significant design; we had way too much to talk about. The aim of this workshop was to figure out a couple of things:
- to learn more about how we might gather requirements about an AL workload management system, and
- to try to gather some of those requirements.
Since this was the first requirements gathering event (that I know of), arguably the first point was the more important of the two objectives.
One of the things that I’ve learnt from teaching interaction design for ten years is that it’s really important to involve people (especially if those people you’re speaking to are going to be affected by a system that you’re going to be introducing). It’s also important to identify which groups of people are going to be affected by the introduction of a system through a process that is broadly known as stakeholder analysis.
The stakeholders who were involved at this workshop was a group of staff tutors from the school of Computing and Communications. It’s important to say something about this group of awesome people: they work within a number of different organisational cultures. They work within a particular school and within a particular faculty (the STEM faculty), and (of course) within this particular university.
My point is that different staff tutors (and stakeholders) may well have different needs and requirements. The needs and requirements gathered from this one group of staff might be different to those gathered from another group. I’ll put it another way: to get a real understanding of what you need from a system means that you’ve got to go and ask different groups of people. What the tutors will need (and tutors are, arguably, the most important stakeholder in this system) will be very different from what the staff tutors need.
Another point to remember is that you can’t just buy a ‘work management system’ for tutors off the shelf. The reason for this is pretty simple and obvious: the OU tutor contract is specific to the OU, and that the OU is pretty unique amongst institutions, which means that an off the shelf ‘talent management system’ (or whatever they might be called) is unlikely to suit our needs. This said, this important reflection shouldn’t stop us looking at other products to gain inspiration and insights.
The question is: how do actually go about specifying a new system? Actually, there are a couple of subjects in computing that can help us: interaction design (which I’ve mentioned earlier), and requirements engineering (I know more about the former than the latter).
What follows is a summary of the plan for the day, a brief summary of some of the points that were gathered, followed with a quick summary (and a suggestion about next steps). A more detailed document (complete with more pictures and text) will be prepared from all the resources that has been captured.
The workshop plan
The workshop was (roughly) split into thirds.
Part 1
The first third was all about context. Steve Walker (who was involved in the contract negotiations) began by introducing the contract. Steve said that he was being asking two types of questions: type A questions were questions about the detail about the contract; type B questions were questions about how the new system would work. The aim of this workshop was, he said, to answer some of those type B questions that everyone was asking. These questions were, in essence, about the detail (and when it comes to system design, details matter).
After Steve had completed his introduction, he described the connection between the new tutor contract and the replacement of some university systems. The timing of the negotiations were such that they are not connected or linked to each another. The point is that the new tutor contract represents a set of additional system requirements that need to be taken into account (somehow).
Next up was yours truly. I described some tools and principles from the subject of interaction design (which is all about the designing of interactive systems). I spoke about personas, scenarios and use cases.
Importantly, user personas have already been used by the contract team to understand different tutors who might move onto the new tutor contract, but personas didn’t exist for other stakeholders (such as staff tutors, academic services staff, HR people, and central academics).
Some further points were: there is the need to explore the problem space, and the importance of iteration and prototyping. An important point was: the later you make changes in an IT system, the more things cost. The obvious solution for risk mitigation is that it is really important to understand what you’re building before you go ahead and build a system.
Part 2
This was the part where staff tutor colleagues got themselves into small groups. The brief was kept simple: think about the challenges that you face in your day to day work as a staff tutor, and use the different interaction design tools to try to create something. That something might be: personas, narrative descriptions of tasks, or rough sketches that illustrates how the tutor management system needs to work (and what the different stakeholders need to do).
Part 3
This final part was where all the different groups shared something about their discussions with each other. This bit was very informal, and led to a group discussion about some of the various issues and challenges that were exposed. After the discussions, all notes (and scribbled on flip charts) were gathered up in anticipation of the next step: analysis.
Outcomes
Two related questions that interaction design students can ask is: (1) how much requirements gathering should you do? And, (2) how do you analyse and make sense of all the data that you’ve gathered?
The answer to the first question is: “you should keep gathering requirements until you spend your budget and/or find that you’re no longer gathering any more new requirements”. Regarding the analysis question, I feel that it’s very much an inductive process: you look at everything and try to figure out what it all means. As you do this, you can begin to write everything down and start to use some of the design tools that I’ve mentioned earlier.
By way of a start, what follows are some broad themes (and questions) that have emerged from our workshop discussions. One thing that I should be clear about is that that the identification of the themes is influenced by my own experiences as both an AL and a staff tutor. Different colleagues could easily identify different issues.
Stakeholders
There are loads of stakeholder (more, perhaps, than we had realised): there are ALs, AL exec and assembly members, staff tutors, lead staff tutors, cluster managers, Academic services (AL services), module team members, module chairs, curriculum managers, people services (HR), IT, Associate Deans and Executive Deans, and finance people. I'm sure there are others too.
In addition to there being loads of stakeholders, another really important point is that different stakeholders will have different perspectives.
The perspectives of (and experiences) ALs from the STEM faculty will be different to the perspectives of WELS ALs, and these will be different to the perspective of business school ALs. There are important differences between other stakeholder groups: STEM has staff tutors, FASS has staff tutors and faculty managers, and FBL has student experience managers. Different modules, programmes and disciplines may point to differences that need to be thoroughly understood and appreciated.
Implications for stakeholders
An important question to ask is: how will the stakeholders feed into decisions about any system that supports the operation of the new contract? There are other important considerations and implications that need to be taken into account:
- How will or should different stakeholders understand the system? Will they see it in terms of managing people, or about managing work or workload? (Or, in interaction design terms, what is the overall conceptual model?)
- Does the new contract mean that there is a change from managing tutors to leading tutors?
- Which perspective is the most important: national, regional, cluster or module? Again, to what extent does this differ between different stakeholders?
- Will different stakeholder see a different dashboard or representation of the system that makes the tutor contract possible? If so, what might this dashboard look like?
Questions
During our workshop, we unearthed a whole bunch of important questions that we couldn't answer by ourselves:
- Who will be able to make decisions about the skills audit?
- Will the ALs be able to see their skills audit results through their TutorHome pages?
- How do staff tutors handle an increase in the student numbers? (And how does this link to HR procedures?)
- What happens when a tutor requests a leave of absence?
- How can tutors and staff tutors manage holidays?
- What happens if a staff tutor can’t fill or top up a percentage of FTE? Does the system tell a staff tutor what percentage this is, and offer helpful recommendations?
- What are the recruitment procedures to use if everyone is maxed out on their FTE (or, what buttons might you press)?
- If a stakeholder finds a need for a new work component, how do they get it added to the system?
Workshop Reflections
The aim of this workshop was to ‘bootstrap’ or to start the gathering of requirements for a tutor workload management system.
A key reflection was that the plan for the workshop was hopelessly ambitious.
I had imagined that we would create some new personas and start writing a few scenarios, and then prepare a bunch of ‘straw men’ (or ‘straw person’) sketches that could form the basis of further discussions. In some ways, some groups did start to do this by sketching what bits of information staff tutors would like to see on a screen or 'data portal' or dashboard. Such a step represents the first steps towards a beginning of a design; one that could (and should) be criticized, reinvented and then redesigned.
The truth of the matter was that we were not at the requirements gathering phase: we still didn’t have a good understanding of the problem space.
I’ll share a pretty direct opinion: for a system to be a success you need buy in from its users and stakeholders.
People like (and need) to be involved. A suggestion is, therefore, to roll out a version of this workshop to different groups of staff across the university: different groups of tutors, different groups of staff tutors, different groups of academics, and different groups of academic services administrators.
Requirements need to be gathered, and potential users need to be listened to. To get it right all this requirements and engagement activity will, necessarily, take time.
A change to the tutor contact represents a significant change to how the university operates. The systems that support that change needs to be right.
An important point to remember is that we’re not talking about a computer system, or a bunch of web pages: we’re talking about the need to figure out how a complex socio-technical system works.
A concluding opinion is that: we shouldn’t rush the implementation and roll out of a workload management system for tutors. It is way too important.
Workshop Acknowledgements
A big thank you to Steve Walker who introduced the tutor contract during the first part of the workshop, and to all participants. Acknowledgements are also extended to Georgina Harris and Mark Slaymaker and other colleagues who reviewed earlier drafts of this post.
C&C Away Day Discussion
On 13 February I gave a short presentation about the new tutor contract during the School of Computing and Communications away day. The aim of the presentation was to introduce the ideas behind the new tutor contract to colleagues in the school. I based the presentation on a set of slides that had been presented during the Staff Tutor workshop event (thanks Steve!)
After the presentation, there was a short Q&A session, where I tried to answer questions (with help from fellow staff tutors helped). During that session I tried to be as clear as I could in terms of sharing what we knew, and what we didn't. Or, put another way, what the 'know unknowns' were. The most significant of these 'known unknowns' are: what system we use to record everything, how we practically go about carrying out a skills audit and what the HR processes might be for recruiting new tutors to the university.
Here are some key questions that were raised by colleagues in the school:
- Will we have a loss of control over who we give particular bits of work to? (My personal answer to this one is: I don't think so)
- Do we (module teams) need to specify what "additional duties" mean, and how does this relate to FTE points? (A related question is: how do bits of work translate to FTE units that we can fit into the work plan for an associate lecturer?)
- Will central academics be able to see an AL profile to get an understanding of what skills resources are available within a school, so we can try to plan for when we might need more capacity in particular areas? (Or, put another way: what information will module team members be able to see?)
- What process will there be for the fair selection of associate lecturers? This might apply to either recruiting associate lecturers into the university, or choosing bits of work. (An accompanying question is: what processes do we follow if our decision making is challenged?)
- Also, we may need to recruit some associate lecturers with specialist skills. Will the new contract enable us to do this?
- Finally, to what degree will central academic staff need to be (and should be) involved with the academic professional development (or upskilling) of associate lecturers?
After the discussion, I agreed to pass these points on to the project team.
A point I made at the start of the presentation was that the new tutor contract has the potential to change the character of some aspects of the university and affect the way that we all do things. With this in mind, I do feel that it's important that we engage with discussions that relate to its development and implementation.
Additional information
Messages about the new tutor contract regularly appear in my inbox. Here's a quick summary of some of the most important links I've found: