Centralisation or Departmental Freedom?

1. Centralisationor Departmental Freedom? Mike McConnell Iain A. Middleton Institutional Web Management Workshop18-20th June 2002

2. Featuring: • the department • the management

3. Overview • The problem • Historical development of HEI websites • Barriers to change • Where to from here? • Case Study 1: The Robert Gordon University • Case Study 2: University of Aberdeen • What have we learned

5. The problem (1) Objectively: • the site’s a mess! • can’t find information • patchwork of sites, inconsistent in presentation and navigation • non compliance: usability, accessibilty, legal obligations... • is it any more than the sum of its parts? • uncoordinated/inconsistent development • outdated/irrelevant/incorrect information • non representation of key areas/aspects

6. The problem (2) Departments’ point(s) of view: • the site’s a mess! (but ours is OK, leave us alone) • we do what we can • we can’t get stuff up • the bloke who did the site has left • we don’t have the time • we can’t find ‘our site’ • why can’t we have a link from the home page?

7. The problem (3) Management’s point of view • the site’s a mess! • our institution is a laughing stock • can’t find anything • doesn’t look corporate or consistent • doesn’t impress • can’t be good for business

8. Everyone agrees the site’s a mess... …so why does the situation arise and persist? • HEIs differ from other large organisations • historically, sites have ‘developed’ ad hoc • barriers to change come from both departments and management

9. tradition of departmental autonomy and academic freedom looser management structures departmental ambivalence to: management corporate identity multiple activities and objectives - research, teaching, consultancy Characteristics of HEIs

10. Historical development of HEI websites Independently by departments: • because we can: • The technology is there • I suppose we ought to; everybody else has one • amateurs/enthusiasts • Look! I can do HTML/Flash/animated gifs • I want to advertise my research/hobby/pets

11. Historical management of departmental websites • let the most techie/enthusiastic member of staff to ‘do the website’ • designate a person to do the website, regardless of ability • work done according to: • ability • inclination • ‘free’ time available • priorities/rules/standards of the individual

12. What is really required

13. Where we are:

14. Barriers to change (1) Departments • lack tools/skills/resources • can’t effect change outwith their own areas • lack incentive beyond their own (perceived) interests • can’t articulate their needs • may not even perceive a major problem

15. Barriers to change (2) Management • can’t articulate overall vision • or haven’t realised they need one • can’t provide guidance • don’t resource it, so can’t influence it • don’t know what departments do • think departments are all the same

16. Conflict • Departmental view • what about all the work we’ve already done? • we’re used to doing it this way • we’re unique • no thanks • exists for our own many individual purposes • give us support • Our web site Management view • we need a “better” web site • if we spend £x we could get one like theirs • we want consistency • branding! • exists to sell the institution • make them comply • the university web site

18. Departments’ fears

20. Where to from here? • give up? • throw it away and start again? • outsource it? • demand that people shape up? • make threats? • throw money at it?

21. Case Study 1 The Robert Gordon University

22. Where we were – 2000 • 1 central +3 independent servers +outsourced ‘bits’ • departmental maintenance completely devolved • pockets of proactivity and enthusiasm: • patchwork by outsourcers, individuals, amateurs • highly variable quality • non-representation, non-participation of key areas • confusion over ownership/responsibility • no supported authoring tool, minimal training • insufficient resource, skills, tools and support • Decision to act

23. Decision to act • representations from Web Editor & departments • consensus on need for change • common ground with “web enablement” vision & BPR • Result • web project initiated as part of BPR project • significant resources were made available • Web Team set up, reporting to BPR board.

24. Web Team Role • redesign and redevelop core site • ensure site-wide consistency of appearance • increase participation & body of content • simplify publication process • web-enable specific business processes e.g. prospectus maintenance/publishing

25. Web Team Composition • Web Editor • Senior Web Developer • 2 x Web Developers • plus formal part-time involvement from extant staff for • database & other tech issues • business analysis • graphic design Reporting to Project Leader

26. Initiation • all non-essential departmental web development halted • key players identified • staff hired • externally for tech skills • internally for organisational knowledge • structures and action plan for senior mgt approval • design concepts • equipment purchase (new servers etc)

27. Action • intensive meetings with key players • mind mapping techniques to elicit needs • content requirements identified • actions assigned to participants (some surprised faces) • layout & navigational design finalised • in house CMS developed • issue-specific projects developed (e.g. prospectus) • home page & graphic design finalised (finally) • dealing with opportunists

28. Launch • CMS training programme for content providers • Intensive period of getting content online • Quality & Completeness checks • delay! • SWITCH Massive publicity throughout to prepare users for change

31. Post Launch • Web site presents a cohesive public face • Rapid development of departmental sites • more than half have developed or redeveloped • very consistent in graphic/layout terms • depts are free to express themselves within this • Web Team can deal with projects on a priority basis • Legacy site moved to www2.rgu.ac.uk • still available as before to users and developers • still contains much core information

32. Reasons for success • Project with definite deliverables & timescales • Management driven: • massive funding • obstacles removed • key players can’t hide • Buy-in from departments due to attractions of CMS • quick; easy; non-technical; no design skills • Easy to add content, therefore site grows rapidly

33. Caveats • did tight timescale give long-term answer? • focus on product, appearance, making web pages • but procedure? Information strategy? • other work frozen for duration of project • quality control of content • maintenance • legacy site confusion • CMS tool does not allow deviation from template • not everyone wants “generic” feel

34. Case Study 2 The University of Aberdeen

35. 1 central and 8 major independent (‘rogue’) servers departmental maintenance completely devolved large body of authors with varying abilities highly variable quality missing some departments and key sections confusion over ownership/responsibility poor presentation and little or no corporate ID no standard tools or technologies Decision to act Where we were - 1999

36. Needs identified • a formal body to decide web policy strategically, to: ‘assess core needs, evaluate competing interests and have the authority to sanction or preclude Web activity’ • a centralised body to provide design and authoring services, implement web policy and monitor departmental activity • support mechanisms for departmental web authors • standard tools: authoring and publishing • training • networks/communities of interest

37. Web Strategy Group Role • provide a forum for issues to be raised • identify key areas for development • arbitrate between competing interests • consider institutional responses to external factors: HERO, accessibility legislation, etc.

38. Web Strategy Group Composition • academics: HoDs, lecturers • management: TMT, Deans • web team manager • departmental web author(s) • data protection officer

39. Web Team Role • implement policy as decided by Web Strategy Group • maintain central web presence and core web information • provide a paid-for authoring and design service • provide and maintain publishing and authoring tools • provide training courses • provide advice and support to departments

40. Web Team Composition • manager (information skills) • webmaster (technical skills) • developers - 1 core, others as need arises

41. What happened next • corporate ID established and made easy to use • Web Strategy Group resolve ongoing disputes • free support and training offered by Web Team leads to enhanced communication with departments • paid for work begins to trickle in • snowball effect - increased income leads to more staff and economies of scale • whole Faculties negotiate maintenance agreements • departments more open to strategic aims; management more open to departmental needs

44. 1 central and 6 major independent (‘rogue’) servers 60% of departmental maintenance centralised - ever increasing much of web authoring community trained and using supported tools 99.99% complete coverage increasing uniformity of navigation and appearance corporate identity established non-prescriptively ownership/responsibility issues resolved Where we are - 2002

45. Reasons for success • process approach/guided evolution - a framework for future development • departments and management involved • free training/cost-effective authoring service is easiest option for departments • non prescriptive - leads by example • focuses on facilitating organic growth/participation • environment created for ongoing definition and delivery of solutions

46. Caveats • change can be slow • charged resource favours wealthier departments • peaks and troughs in demand • popular opinion is not necessarily the best - compromise may dilute site impact • dependent on key individuals • dependent on departmental ethos - participation not mandatory • no launch party

47. What have we learned?

48. What have we learned? • the entirely devolved model by its nature does not “self-organise” • control is essential for progress • some degree of centralisation is necessary to effect control BUT • the revolutionary approach can alienate key players • projects do not provide solutions for the long term • sustaining the ecology is vital; therefore Centralised control must be carefully defined

49. telling departments their specialisms vetting every change threatening people demanding compliance pulling the plug on sites preventing experimentation Effective centralised control is not:

50. protects your corporate ID and core information from: embarrassing faux pas legal challenges an administrative nightmare delegates other content appropriately and ensures responsibilities are fulfilled is responsive to new needs and opportunities, external and internal has ultimate editorial authority - ensuring compliance Effective centralised control: