centralisation or departmental freedom n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Centralisation or Departmental Freedom? PowerPoint Presentation
Download Presentation
Centralisation or Departmental Freedom?

Loading in 2 Seconds...

play fullscreen
1 / 53

Centralisation or Departmental Freedom? - PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on

Centralisation or Departmental Freedom?. Mike McConnell Iain A. Middleton. Institutional Web Management Workshop 18-20th June 2002. Featuring:. the department the management. Overview. The problem Historical development of HEI websites Barriers to change Where to from here?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Centralisation or Departmental Freedom?' - mira-whitehead


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
centralisation or departmental freedom

Centralisationor Departmental Freedom?

Mike McConnell Iain A. Middleton

Institutional Web Management Workshop18-20th June 2002

featuring
Featuring:
  • the department
  • the management
overview
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
the problem 1
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
the problem 2
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?
the problem 3
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
everyone agrees the site s a mess
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
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

Characteristics of HEIs
historical development of hei websites
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
historical management of departmental websites
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
barriers to change 1
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
barriers to change 2
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
conflict
Conflict
  • 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

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
where to from here
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?
case study 1
Case Study 1

The Robert Gordon University

where we were 2000
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
decision to act
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.
web team
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
web team1
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

initiation
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)
action
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
launch
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

post launch
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
reasons for success
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
caveats
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
case study 2
Case Study 2

The University of Aberdeen

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

Where we were - 1999
needs identified
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
web strategy group
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.
web strategy group1
Web Strategy Group

Composition

  • academics: HoDs, lecturers
  • management: TMT, Deans
  • web team manager
  • departmental web author(s)
  • data protection officer
web team2
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
web team3
Web Team

Composition

  • manager (information skills)
  • webmaster (technical skills)
  • developers - 1 core, others as need arises
what happened next
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
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

Where we are - 2002
reasons for success1
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
caveats1
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
what have we learned1
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

effective centralised control is not
telling departments their specialisms

vetting every change

threatening people

demanding compliance

pulling the plug on sites

preventing experimentation

Effective centralised control is not:
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

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

further information
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/