Manchester Metropolitan University

mail from Alan Paull

We are currently working on the Archimate and systems thinking stuff.

The Archimate work is proving very interesting.  As the current system
is paper-based, we have no actual Enterprise Architecture type
structures (no ICT), which means the COVARM-in-Archimate will be
business layer only.  We will have some comments on the COVARM model as
it stands, having discovered one or two dangling threads!

I would like to make a note here about complexity and the purpose of our
process modelling.  The COVARM model of MMU processes is complicated and
reflects their complex nature.  The purpose of the COVARM model was to
enable the project team to analyse the processes alongside processes at
other institutions in order to create a generic course validation model,
so it is not very accessible to other audiences.  On the other hand our
purposes are four, I believe, at the moment:

(1)    To gain an understanding of the whole process, with a view to …

(2)    Presenting potential interventions (ICT tools and process
improvements) to a wide audience and …

(3)    Modifying these in the light of comments and experience, and
finally …

(4)    Recording the changed processes, with the engagement of the
community in the maintenance of the models.

This means that the parameters of our models might be these:

The viewpoints need to cover the concepts relating to the HEI staff
practitioners, those involved in the processes, rather than from the
viewpoint of application developers.  Viewpoint from employer would also
be essential.

Understanding of the current processes, indication of intervention
points and presentation of any new or revised processes will mean the
focus is probably not as fine-detailed as the COVARM version.

Concentration should be on the main flow of processes, with only a
passing mention of exceptions or alternative flows.

The models will be iterative and therefore subject to change as we
receive stakeholder comments.

We will keep a clear split between our ‘as is’ model and our ‘to be’
model(s).

The model will not provide all the answers!  I think this is important.
Witness that the COVARM model does not include a lot of highly pertinent
information, for example the extent and nature of the documentation
referred to, which will colour perceptions of those actually involved in
doing the processes.

Alan Paull has persuaded us that using scenarios will be a good way of working through the issues relating to quality enhancement and the SRC project. The ideal situation will be for colleagues working on the different strands to suggest these so that they can be mapped to see if there are any oddities or inconsistencies in the workflows which are being developed. I found it quite difficult to get started with the scenarios but there are now a couple of examples on this page if that helps others to think about them.

The idea is that we will use the scenarios to develop workflows (who does what, when) so that we can start passing that information to relevant people who might find it useful as well as asking Alan to do some more technical modelling. We will also use scenarios in workshops with stakeholders looking at mapping the QE processes. And they will almost certainly get used to help us to produce appropriate staff development materials to inform colleagues about QE processes.

I’ll do my best to collect bits of scenarios from the main project strands as and when I bump into people around campus, so be prepared (either to recount a tale of QE activity or to invent an urgent appointment elsewhere as appropriate).

Process Review Meeting 8/1/09

Present: Rob Baker, Philip Lloyd, Alan Dove, Nigel Farmer, Peter Leyland, Rachel Forsyth, Robin Johnson

Aim: to bring CASQE and PMI up to speed with SRC plans regarding process review and to capture their thoughts about the best way forward. In particular, the meeting aims to discuss ways to undertake the baselining activity and to discuss a workshop proposal to capture the views of a range of stakeholders regarding responsiveness within process review.

1.    There was considerable discussion about the need for SRC to integrate its activities with other projects and University initiatives in order to avoid duplication of effort, conflicting goals, internal competition, etc. It was felt that this will arise because there is no clear strategy for the work being undertaken in these projects and initiatives.  The following diagram (to be inserted) highlights the projects and initiatives that SRC is currently aware of but it is possible this is incomplete and certain that this list will change considerably during the course of the project.

2.    It was noted that considering “responsiveness” was not sufficient and that we also needed to consider Quality and Risks.

3.    It was pointed out that the responsiveness required in considering qualifications to meet the needs of 18-21 year olds was quite different to that required to meet the needs of employers CPD.

4.    It was decided that this group would meet again to review the COVARM model of MMU’s review processes. ACTION: Robin to produce an A0/A1 printout of the model and arrange meeting.

5.    Philip felt that it would be useful for users of the process review processes to also review the model, possibly separating them into those that are experienced and those that are less experienced in using it. ACTION: Robin to arrange small group review meetings (suggested attendees?)

6.    We ran out of time to discuss the workshop, so attendees agreed to look at the plan and provide feedback by email on approach and membership. ACTION : All.