Centralisation
or Departmental Freedom?
Mike McConnell
Iain A. Middleton
Institutional Web Management Workshop
18-20th June 2002
1
Featuring:
• the department
• the management
2
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
3
4
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
5
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?
6
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
7
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
8
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
9
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
10
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
11
What is really required
12
Where we are:
13
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
14
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
15
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
16
17
Departments’ fears
18
19
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?
20
Case Study 1
The Robert Gordon University
21
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
22
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.
23
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
24
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
25
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)
26
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
27
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
28
29
30
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
31
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
32
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
33
Case Study 2
The University of Aberdeen
34
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
35
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
36
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.
37
Web Strategy Group
Composition
•
•
•
•
•
academics: HoDs, lecturers
management: TMT, Deans
web team manager
departmental web author(s)
data protection officer
38
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
39
Web Team
Composition
• manager (information skills)
• webmaster (technical skills)
• developers - 1 core, others as need arises
40
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
41
42
43
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
44
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
45
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
46
What have we learned?
47
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
48
Effective centralised control is not:
•
•
•
•
•
•
telling departments their specialisms
vetting every change
threatening people
demanding compliance
pulling the plug on sites
preventing experimentation
49
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
50
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.
51
52
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/
53