Friday, 3 August 2012

The Vexing Problem of Processes

I spent yesterday in a meeting with colleagues from various JISC Regional Support Centres (RSCs to folks in the Further Education and Skills Sector, though that suggests Shakespeare to almost everyone else...)

We met in Birmingham to discuss work we were all involved in for JISC Advance on coordinating resources from both the RSCs and my own service of JISC infoNet on the review and improvement of business processes

"We" were Graciano Soares; RSC Manager for London, who leads the group (as much as it's possible to lead a bunch of enthusiastic show-us-a-tangent-and-we'll-follow-it people like us), Allen Crawford-Thomas; e-Learning Adviser (Teaching and Learning) for RSC West Midlands, Colin Gallacher; e-Learning Adviser (Work-Based Learning) for RSC Northwest, and myself.

We had a lively business meeting in the morning followed by an afternoon's work creating a document of our plans for approval before it can be released.

As always though there were some real gems that came out during the course of the meeting that, unless written down and shared, can so easily be lost and forgotten.

So here's a record of three not-quite-random thoughts.

Pockets of good practice

I suggested at one point that organisations should employ business process review techniques to eliminate pockets of good practice.

A statement that on the face of it sounds initially ludicrous. Until you think about it and what I was saying was that you should make every attempt to share that good practice so that it remains a pocket for a very limited time and instead adds benefit elsewhere where practice is not so good. So then someone suggested we have a full suit of good practice, which led Colin to comment that it was all surely about how organisations cut their cloth...

Yes it is. If you allow pockets of good practice to exist in perpetuity then you are missing a trick.

What is "the norm"?

Someone had mentioned something as being "against the norm" which prompted Allen to say "So what is the norm anyway? People talk about it as though it's a constant but I don't think it should be."

We agreed. We decided that "the norm" should allow for being open to new ideas, to give space, time and resources to controlled experimentation that should be evaluated and assessed to see where it directly could add benefit through wider implementation or indirectly suggest further new ideas.


We discussed the concept that problems around technology are not necessarily down to the technology itself, but may be about reluctance to use it, uncertainty as to whether use is mandatory, a lack of knowledge or skill or confidence on the part of users, or the lack of any monitoring for quality or compliance.

Thus we came up with a phrase and a few bullet points.

It's not just the technology - it's also the way you:

  • decide what it's supposed to do (pre-purchase/build planning)
  • prepare for it (before and during implementation)
  • prepare/collect content/data for it (process design)
  • use it (input)
  • make use of it (output)
  • monitor compliance
  • monitor quality of content/data

Thanks guys, a brilliant day.