1 Centralisation or Departmental Freedom? Mike McConnell Iain A. Middleton Institutional Web...
-
Upload
isaac-mccullough -
Category
Documents
-
view
212 -
download
0
Transcript of 1 Centralisation or Departmental Freedom? Mike McConnell Iain A. Middleton Institutional Web...
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
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
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 &
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
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 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
51
Further Information
Iain Middleton [email protected]
Mike McConnell [email protected]
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/