1
Centralisation
or Departmental Freedom?
Mike McConnell
Iain A. Middleton
Institutional Web Management Workshop
18-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

4

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

17

18
Departments’ fears

19

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

29

30

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

42

43

44
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

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
Effective centralised control is not:
• telling departments their specialisms
• vetting every change
• threatening people
• demanding compliance
• pulling the plug on sites
• preventing experimentation

50
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

51
In conclusion
You can give people:
• structures and guidelines
• cost effective service
• tools and training
• good reasons
to work within your centralised framework to the benefit
of all parties.

52

53
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/