Summary of post structural review discussion - DRAFT

There was a common concern, that whilst shared offices and pandemic planning have helped, there is still a degree of SILO culture (between the units)

  • We reckon that we probably can't go much further re knowledge sharing
  • ACTION - Agreed that we should have another documentation week (but geared towards internal documentation?)
  • Some good has been undone by recent office moves (splitting across buildings) . We may want to look at all COs being co-located in the long run?

USU, in particular, had concerns that they weren't always informed of imminent user facing changes

  • All units should consider impact of changes and report any substantive impact to USU before changes go live.
  • The new development meeting should make it easier for user-support to influence design and implementation for formal projects (USU should ensure at least one CSO at development meeting), but many changes are misc development / operational.
  • We considered a wiki page to record all changes and possible impact (in CO speak), but we concluded that this was expensive and overkill.

There have been occasions when USU haven't been able to contact anybody in a particular unit (by chat/email/phone/in-person).

  • We need to avoid this whenever possible during the working day.
  • ACTION: We should update the telephone list.

We need to formalise and resource our support for self-managed platforms

  • ACTION: This wasn't raised during the review - we will convene a separate meeting for this.

Small devolved budgets for units

  • Alastair has been considering a delegated budget of 2k for each unit from the maintenance/consumables budget.
  • ACTION: He will check whether that is affordable (there are already many large fixed commitments).

Formal time reporting: This seems an unnecessary burden, and anyway, the results don't seem to be used. Do we want to continue with this?

  • After much discussion it was agreed that we would drop formal time reporting for all but projects.
  • What has been achieved is as/more important than how much effort has been expended, so frequent project updates (eg using a blog) are important
  • Units may agree to continue with formal time reporting for all activities, but there is no obligation to report these "upwards".
  • Individuals will personally keep track of their effort spent on CPD.

Possibly unhelpful emphasis - 'Development good; Operational bad': I don't agree with the philosophy (and, anyway, the demarcation often isn't as easy to make as one might think) but it seems to drive some things here - not least the time reporting above. It might be better to concentrate on the more general aim of providing good-quality systems which serve the current/future purposes of the School, and to judge our success in that by looking at what is (or is not) actually produced.

  • Alastair explained that Informatics COs are expected to lead in developing new systems and this is used, in part, to justify our higher CO staff budget compared to other schools.

Sometimes, what seems like the uncritical transmission of instructions from higher up: An example from a couple of years ago was the proposal for 'continual appraisal'. Where did that come from? (And where did it go?) Another example might be the suggestion that computing staff 'want' to be more involved with teaching. More sensitivity (at least) to those of us not in the direct chain of command might help. This might just be a matter of more communication/explanation.

  • CEG now has a CO/CSO rep, rotating on a weekly basis, which hopefully should improve communication.
  • We will have an annual meeting to discuss the draft computing plan.

-- AlastairScobie - 03 Dec 2014

Topic revision: r2 - 04 Dec 2014 - 10:14:52 - AlastairScobie
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies