1. 1 Centralisation or Departmental Freedom? Mike McConnell Iain A. Middleton Institutional Web Management Workshop 18-20th June 2002

2. 2 Featuring: the department the management

3. 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

4. 4

5. 5 The problem (1) Objectively: the sites a mess! cant 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. 6 The problem (2) Departments point(s) of view: the sites a mess! (but ours is OK, leave us alone) we do what we can we cant get stuff up the bloke who did the site has left we dont have the time we cant find our site why cant we have a link from the home page?

7. 7 The problem (3) Managements point of view the sites a mess! our institution is a laughing stock cant find anything doesnt look corporate or consistent doesnt impress cant be good for business

8. 8 Everyone agrees the sites 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. 9 Characteristics of HEIs tradition of departmental autonomy and academic freedom looser management structures departmental ambivalence to: –management –corporate identity multiple activities and objectives - research, teaching, consultancy

10. 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. 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. 12 What is really required

13. 13 Where we are:

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

15. 15 Barriers to change (2) Management cant articulate overall vision –or havent realised they need one cant provide guidance dont resource it, so cant influence it dont know what departments do think departments are all the same

16. 16 Conflict 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 Departmental view what about all the work weve already done? were used to doing it this way were unique no thanks exists for our own many individual purposes give us support Our web site

17. 17

18. 18

19. 19

20. 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. 21 Case Study 1 The Robert Gordon University

22. 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. 23 Decision to act representations from Web Editor & departments consensus on need for change common ground with web enablement vision & Business Process Re-engineering (BPR) Result web project initiated as part of BPR project significant resources were made available Web Team set up, reporting to BPR board.

24. 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. 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. 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. 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. 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

29. 29

30. 30

31. 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. 32 Reasons for success Project with definite deliverables & timescales Management driven: –massive funding –obstacles removed –key players cant 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. 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. 34 Case Study 2 The University of Aberdeen

35. 35 Where we were - 1999 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

36. 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. 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. 38 Web Strategy Group Composition academics: HoDs, lecturers management: TMT, Deans web team manager departmental web author(s) data protection officer

39. 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. 40 Web Team Composition manager (information skills) webmaster (technical skills) developers - 1 core; others as need arises and according to income - currently 3

41. 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 aware of departmental needs

42. 42 Where we are - 2002 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

43. 43 Reasons for success process approach/guided evolution 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 a flexible framework for future development

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

45. 45 What have we learned?

46. 46 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

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

48. 48 Effective centralised control: 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

49. 49 In conclusion For centralisation to work to the benefit of all parties, people need: structures and guidelines cost effective service tools and training good reasons to work within your framework

50. 50

51. 51 Further Information Iain Middleton iain@imiddleton.com Mike McConnell m.mcconnell@abdn.ac.uk The Robert Gordon University http://www.rgu.ac.uk University of Aberdeen http://www.abdn.ac.uk Donkeys and cowboys by: http://www.clipsahoy.com/