Showing posts with label quality. Show all posts
Showing posts with label quality. Show all posts

Wednesday, 8 October 2014

QAA? Armageddon outta here!

Yesterday’s announcement – on the HEFCE webpages but on behalf of HEFCW and DELNI and in parallel with the Scottish Funding Council – has caused more than a few ripples of excitement.

What’s the news? A request for feedback from the sector, to inform the specification of a tender for quality assurance for higher education. If that doesn’t sound significant, let me tell you that it is. First, some background.

The 1992 Further and Higher Education Act provides (para 70) that the Funding Councils “shall … secure that provision is made for assessing the quality of education provided in institutions for whose activities they provide, or are considering providing, financial support …”. Each Funding Council has a Quality Assurance Committee, comprising people with sector experience, to advise on how to undertake this work.

If my memory serves me right*, in the early stages HEFCE did some assessment of standards work in-house (the Academic Audit Unit), and a sector body – the Higher Education Quality Council (HEQC) – developed methodology for assessing and assuring quality at a subject level. And in 1997 the QAA was established to bring it all together.

An opportunity for a new logo?
And so the consultation and tender exercise is giving notice that the status quo is up for renegotiation. No doubt with pressure from some such as the Russell Group for a ‘risk-based’ approach (‘leave us alone, the metrics show that we’re fine!’) and, with an equal lack of doubt political pressure from different quarters to address perceived issues such as contact hours and value for money

And so this is a fight about university autonomy and about marketization. Part of the rationale for establishing HEQC and QAA (both bodies owned by the HE sector, like UCAS and HESA) was that if the sector didn’t do something, government would impose an OFSTED style inspectorate. And since one of the crowning glories of UK higher education is that our academic standards are high, this would be a problem. Universities need autonomy to set and maintain these standards, so the argument goes.

And marketization? Well, applicants to universities, almost by definition, don’t know much about the content or value of the programme they’re seeking to join. In the OFT’s view, they are much less sophisticated as consumers than the universities with which they are making a contract. So an assurance regime which is more like consumer protection – guarding against rogue traders – might be considered appropriate. There’s a lot of public money and private individual debt at stake, so these aren’t concerns which can be dismissed flippantly.

There’ll be a lot of debate and discussion. The Wonkhe post by Mark Leach is a good resource with links to various statements and also in the comments. Which is where, by the way, the Armageddon word came from: #QAmageddon being the hashtag of choice …

It pays to read the legislation carefully: “assess the quality of education.” Who defines quality and its indicators, that’s the question. And the outcomes will matter for the sector.

*Edit 9 October. My memory didn't serve me right! Academic Audit Unit became HEQC; HEFCE continued with TQA until QAA took over. Thanks to Mike Ratcliffe @Mike_Rat for the correction. We need the equivalent of rock family trees ...

Monday, 19 May 2014

Operational effectiveness

Any manager will at some point have worried about achieving reliability and efficiency in delivering a service. There’s a powerful combination of two established management tools which can help you.

The first tool is to use Standard Operating Procedures – SOPs. This isn't (just) an instruction manual for how to do something. It’s also a set of habits which keeps that recipe card current. Here’s how.

Document the procedure – and have it done by those who actually operate it. SOPs are common in laboratories and in manufacturing processes – here's guidance from the US EPA which includes examples – but they also apply to administrative processes, and particularly those which use complex databases or other IT systems. SOPs should articulate the critical steps; and identify any choices that the operator has to make, and the parameters for those choices. They should also not be so long that they become unusable.

Have the procedure reviewed and signed off by a senior member of staff, not involved in its drafting – the head of section or, if it's a small team, their manager. This is so that the process has formal authority as well as the expert authority that comes from the knowledge of its authors. It also means that any organisational or resourcing issues have to be addressed. And finally, it shows that the SOP is serious: make the sign-off process a real hurdle, and people will see that it matters.

Include in the document the reasons for the steps. Tell people why something matters and they are more likely to do it. Robert Cialdini reports a fantastic example of this in his book ‘Influence’, reporting on work done by Ellen Langer of Harvard University. Ellen Langer conducted experiments in which she asked people queuing to use a photocopier if she could push in.

  • When the question was Excuse me, I have five pages. May I use the Xerox machine because I'm in a rush? 94% let her go ahead of them
  • When the question was Excuse me, I have five pages. May I use the Xerox machine? only 60% let her go ahead of them
  • And when the question was Excuse me, I have five pages. May I use the Xerox machine because I have to make some copies? 93% let her go ahead of them

So when you give a reason – because – you get much more agreement. And note that the reason doesn't even have to be a good one – ‘because I'm in a rush’ and ‘because I have to make some copies’ get pretty much the same response, but the second reason adds no extra information. Why stand in a photocopier queue if you don’t want to make copies? So use a because and people will more likely notice.

Train people in using the procedure. It doesn't have to be a full day's training session, but at least talk them through the procedure; let them ask questions; observe and coach if they're unsure.

Set a review date; stick to that date; and involve those who operate the procedure in the review. Keep the procedure current; make sure you take account of any other organisational or priority changes which might impact; and learn from the experience of operating the procedure.  What tips and wrinkles have the operators identified? What would they change to make it better?

So that’s the first tool – standard operating procedures.

The second tool comes from Lean thinking, and is both simple and devastatingly powerful. It’s about identifying the nature of the tasks to be done, and makes the following distinction.

  • Runners are tasks that occur on a daily basis, and are of sufficient volume to justify having a specific process to deal with them
  • Repeaters are tasks that occur on a regular basis, but not frequently, and are not part of the day-to-day business of the organisation
  • Strangers are tasks that occur infrequently

Now apply this distinction to a standard operating procedure. Does a single procedure try to cope with too many different types of event? Are you dealing with repeaters and strangers when you could be focusing only on runners? This can lead to delays where questions get passed around the organisation, and bottlenecks are created in workflow. I've seen this happen in processes around the student journey, where one non-standard case delays processing a whole batch of students, resulting in disproportionate problems.

The trick is to design the bottlenecks out. Make the procedure work for one specific task. If there’s another task which occurs, have another procedure. You can’t make apple pie with a recipe for blancmange. And make sure that you have triage at an early stage: work out if a case has the right features to be dealt with by a given procedure. If it has, then process it. If it doesn't, then refer it elsewhere. Just like a hospital, making sure that the broken bones go to the fracture clinic, and the blocked ears go to ENT.

And there you have it. Think about runners, repeaters and strangers, to make sure that your procedures have the right scope and focus. And then write and use a standard operating procedure to improve quality and reliability.

Good luck!