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

4
(No Transcript)
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
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
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
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
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
• 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
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
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
(No Transcript)
18
(No Transcript)
19
(No Transcript)
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
  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
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
(No Transcript)
30
(No Transcript)
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 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
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 and
  according to income - currently 3

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
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
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
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
What have we learned?
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
Effective centralised control is NOT

• telling departments their specialisms
• vetting every change
• threatening people
• demanding compliance
• pulling the plug on sites
• preventing experimentation

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
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
(No Transcript)
51
Further Information

• Iain Middleton iain_at_imiddleton.com
• Mike McConnell m.mcconnell_at_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/