Most websites go through a process of continued development and change. I’d argue that they are never really finished, it’s just that every so often they get to the stage where you want to start again from a clean (or clean’ish) slate. Often the motivation is as much a feeling of we can’t do what we want to do with the site now, mixed with there’s other sites out there that look better, have better navigation or features for example. I’d also say that there’s an element of website ‘fashion’ that make sites look out-of-date even when they are perfectly functional but that it can drive user perceptions of a site. So refreshing a site at regular intervals is something I’d want to do. In between regular site redevelopments there will always be a myriad of minor or even major changes to the site and it is one of the challenges of website management to keep track of (and manage) these changes. To do that we’ve developed a process around a Website Improvement Plan.
The Website Improvement Plan
In essence the Website Improvement Plan is a document that outlines the steps you are going to take to address issues with the site and it works to shape the development of the site over a period of time. We only use the plan to record significant changes on the site – so we wouldn’t record minor content changes but would record an activity like adding a completely new section of content with several pages. There is quite a variation in the scope of the activities – so it can range from a task to implement a new search system, or to add a rolling news feature to the home page, for example. We use the plan as a rolling document across each year updating it as we go along. We have an approval process to get new items into the plan and we record the following information about each item:
- a unique reference number for each item
- a description of the item
- the date it was added to the plan
- details of the resources needed to deliver the item and a note if it forms part of a project
- the owner of the item – the person responsible for the item
- the date the change is required
- a category – we split tasks into categories such as Content; Infrsastructure; User Experience etc
- details of when the item was approved
- a status column – updated monthly that is used to track progress of the task
We then colour-code each item to make it easy to check which items are at which stage. So pending items are unhighlighted, approved but not yet started (yellow highlight), in progress (green), completed (grey) as seen below
Pros and Cons of this approach
The processes around approving items to go into the plan and reviewing them (done monthly at a Web Quality Improvement Group meeting) help to focus people’s attention on the work taking place around the website and let people identify where there are obvious gaps in work that is planned. We feed in activities from various projects and strategic plans to take care of the higher-level activities. It’s an open document so it is available to all library staff to view and it’s reported to various library management groups. As a tool to bring together everything we are doing it seems to work.
On the negative side – there is some added bureaucracy around managing the plan and some potential delays in making sure that people have signed off developments before they take place. There is a danger that you can end up managing the plan rather than the service.
We keep version control over the document so we can compare different versions of it. This means that we can track the number of tasks that are completed or in progress and how that changes across the year as a form of fairly crude metric around website development. Within the unit we also have activity data from staff that we can use to identify the cost of website services. For us the process seems to work reasonably OK for day-to-day website management.