Learning curves

Feature

posted 20 Jul 2004 in Volume 1 Issue 2

Bogged down with archaic and often inaccurate information provided by a clunky system, UK-based scientific and medical research charity the Wellcome Trust decided to revamp an outdated content-management system in 2001. Ruth Frost, the charity’s content architect, describes the trial by fire in implementing the system and some lessons she learnt along the way.

Picture this: you’ve been given the budget to purchase a content-management system (CMS) and have chosen one after meeting various vendors. Their enthusiastic sales people have demonstrated the many benefits their product will bring to your organisation. You are now responsible for deploying that system. You may be both excited and a little nervous at this point; after all, this is a big project. And, as with all big projects, you can never be entirely sure what will happen along the way. When ours began at the start of 2001, neither were we.

I hope some of the tips you glean from the description of our project prove useful. I’m sure some of the problems we faced and solutions we came up with will also help. But the most important lesson you can learn from us is that each deployment of a CMS is unique and you’ll learn plenty just by deploying one in your own organisation.

Why a CMS?

The Wellcome Trust is a charity that funds scientific research and major ventures in areas of neuroscience, genetics and tropical medicine.

The organisation has had internet and intranet sites for many years. They were managed and updated by staff from our publishing department, who are responsible for both print and web publications. These staff used a much older, more complex CMS that only technically-minded people could use and had to be trained on. Because the organisation wanted to improve the way it managed the web, external consultants were brought in to review our intranet and website.

They found our sites showed a good standard of writing but were falling short in terms of information currency and accuracy. The information-architecture (IA) had grown stagnant and was no longer accurately reflecting the full scope of the organisation, making information difficult to find.

There were various reasons for this.

Content contributors had many good ideas for improving the sites but were frustrated with the publishing bottleneck;
Lack of perceived content ownership and control of information flows to the sites within departments;
Valuable editorial and web-development skills were wasted on making minor updates instead of major enhancements;
Lack of IA skills meant the site wasn’t fully meeting the needs of the organisation;
It was difficult to restructure the site within the existing system;
Lack of defined roles and responsibilities between the publishing department, our IT department and content contributors;
Difficult for a small team to know what information is pertinent across the organisation and a lack of a systematic approach in defining organisational priorities for web information.

After analysing the consultant’s recommendations, the following steps were taken:

Purchase a CMS and make it available to contributors at a local level;

Establish a formal web team separate from the IT and publishing departments;
Acquire information-architecture skills.

How would a CMS help?

A cornerstone to the Wellcome Trust’s strategy for use of web technologies has been the concept of devolved content management. This was only possible through purchasing a CMS. This was summarised by the web team in the plan for the deployment project:

“The deployment will allow the Trust to manage its web content more effectively, allowing responsibility for content to lie with the people with expertise about that content, rather than filtering through a publishing process.”

We also communicated the following benefits of using the new system:

A single repository for valuable information makes it easier to find and manage content;
Content is entered once and used many times, eliminating doubt about which version is the most current and allowing different formatting to be applied to single content items for different websites;
Anyone can publish to the web with no need for web-development skills, which removes restrictions on information flows;
Content goes through defined workflow paths, assuring the quality of published content;
Version control means changes to information can be managed and tracked, avoiding confusion and errors;
Assigning metadata to content means content is fully searchable and easier to manage;
Explicit ownership information, such as the provider’s name and last reviewed date, lets users know the information is current and of good quality and allows contact with staff responsible for a piece of content.

Deployment project plan

Our CMS deployment project has been a key project made up of several major phases running one after the other.

Phase 1 (May 2001-Feb 2002): system evaluation and acquisition;

Phase 2 (May 2002-April 2003): deploy system and migrate intranet into it;2a: pilot process with subsection of content;
2b: migrate rest of intranet content;
Phase 3 (Sept 2003-Aug 2004): restructure external website and migrate into the system;
3a: migrate library micro-site into system without restructuring content;
3b: restructure main Wellcome site and migrate into system.

We actually added an extra project to restructure the intranet after Phase 2b.

Our existing CMS has moved on over the last couple of years, so the internet project has essentially been using an entirely different technology. The vendor has now developed a piece of software that allows us to develop sites and manage content straight onto the server where the content is held, instead of using a different piece of software that converted the content from the storage server and created a site onto a different server.

Instead of using expensive technical support from the vendor, a recognised support consultancy helped us with the project plan and the pilot phase of the intranet project.

Fundamental to the project was the definition of the organisational informational processes and roles that would deliver necessary content quality.

We consulted with the organisation to define around 30 communities; groups of people who work around related types of content. This related to some departments, such as facilities, but not others, such as training, due to the number of departmental responsibilities each carry. A content co-ordinator was then identified for each community. Their role is to co-ordinate content activities, support their content providers and provide a cross-organisation group to facilitate effective working across communities. The co-ordinator then nominated about 80 content providers who regularly input content directly to the system. Over the next three months, this will increase to about 140 providers as we reach that stage with the external website.

We are coming to the end of the final project phase. The new structure and design of the website is undergoing user testing with our target audiences and development will start within the CMS system in a month’s time. The library site has already been migrated into the system (www.wellcome.ac.uk/library).

Real benefits

The new system has turned the intranet from an inconsistent, incomplete and inflexible site that wasn’t meeting the organisation’s needs into a dynamic business tool displaying quality information. We have noticed the following improvements:

The intranet is now updated 20 times per day rather than 15 times per week – 600 per cent more often;
No longer holds embarrassingly out of date information;
Gaps in available information have been plugged due to a flurry of new intranet work as communities took ownership of their content;
Quality continues to improve with quarterly checks by co-ordinators finding very few faults;
Named providers and last reviewed dates appear at the bottom of the page, giving website users confidence about the quality of information and a direct link between the published information and the relevant business owner;
Web-team resources now fully able to focus on major site improvements;
Publishing resources freed up to focus on creating editorial and communications content;
Intranet is increasingly seen as everyone’s tool and not belonging just to the web team.

We are expecting even more benefits from managing the external site in the same way.

Lessons learnt

This major project has generally been extremely successful. However, there are many things that would have made life easier if we’d known about them earlier rather than later.

The vendors sold us a product that could do everything we wanted. Solution demonstrations made it look simple to use, powerful and eternally flexible. We were repeatedly informed the product could be fully customised to meet any need that arose. The blunt truth was our system could be difficult to use and tricky to build websites on.

For infrequent or less technically proficient users, the system could be daunting. About two-thirds of our content providers had some problems and all of us found it challenging.

And while it’s true that it’s easy for vendor developers to build websites, with our new system our own developers, who were unfamiliar with it, found it complicated, frustrating and limiting.

The lessons we learnt are grouped under three main principles:

Allow time to know your product;
Don’t ignore people and processes;
Limit taxonomy to where it adds value.

Allow time to know your product

You can only learn how the product works through organisational experience. It’s never as simple as it appears in the marketing literature. You can gain much of this experience through pilot programmes, but some of it you’ll only learn when you actually deploy the CMS.

We learnt to allow time throughout our project for the team to get to know aspects of the product we hadn’t tackled before. We also allowed time in between phases for our team to consolidate what we’d learnt.

Allow budget for short bursts of technical consultancy at various stages of deployment.

It was worth bringing in expensive technical consultancy from the vendor company for short bursts. To reduce costs, we avoided this in the first stage of the project, but it caused us problems. Early on, we made a couple of bad assumptions that added significantly and unnecessarily to the complexity of the project. The relatively inexperienced consultants we used to help with the pilot intranet deployment didn’t pick up the errors because they didn’t know the specific idiosyncrasies of our particular product.

Get the right people together

When it comes to the technical set up, don’t rely on intermediaries to communicate requirements. We now ensure all the people who will be impacted in the IT department and the web team developers meet with the technical experts from the vendor. These meetings are born of the painful lessons learnt from assuming everything would run smoothly. When in doubt, assume problems will exist and then be pleasantly surprised when you’ve prepared for them.

Pilot – and pilot well

Even with the proviso that you will never learn everything from them, our use of pilot phases provided an invaluable learning mechanism. We could identify the challenges, find solutions and refine our development process.

Build a website knowing your product’s characteristics – information architecture

Content-management systems work well for standardised, consistent content, while HTML sites tend to have evolved more organically. We recommend always doing at least some restructuring of your site content (if not a total rebuild) before you migrate into a CMS. We made our CMS jump through hoops to cope with our existing intranet and have since restructured the intranet to fit the CMS. We still have fluid, flexible IA, while structuring our content in a consistent way has also improved the user experience.

Build a website knowing your product’s characteristics – development process

Minor changes in HTML sites are major changes in the CMS. This applies especially to labels and navigation. We now aim to tie everything down before we start development. We collect content outside the system in a folder structure, defining templates and metadata. Then the developers build one section at a time using these components.

Keep customisations to a minimum

We put a lot of time into customising the product – partly in an attempt to simplify content management for providers and partly to make it meet our adventurous process requirements. Yet this adds significantly to maintenance complexity and causes problems when new releases of your CMS become available. We now find ways of working within the products capabilities.

Don’t ignore people and processes

From discussion with other organisations, it appears the model we adopted is fairly adventurous. Our aim was for each piece of content to be updated by the person who knew about the content within the scope of their normal work. For example, secretaries would upload minutes they’re responsible for; the legal department uploads the constitution and the catering manager uploads the restaurant menu. Out of a total headcount of 550, there will be around 150 content providers and another 100 reviewers by the time this project is finished. Only a handful of these were involved in managing web content before this project.

Ensuring that your CMS fulfils its potential in your organisation will require planning for four important dimensions.

We knew we had to focus on people and processes to the same extent as information and technology and we devoted a lot of resources on these areas. Our planning for this dimension of the project has been largely successful and the necessity of our approach has been justified time and again.

Make change management a major part of your project plan

Even if you go for a model less complex than ours, plan at least a third of your project resources on training, support, establishing new processes and communicating with all levels of staff. Exactly how you should manage the change depends on the way you will be managing your content, and how much this differs from the existing content-management situation. If your CMS project is simply rolling out better software to people who already manage your website or if all the providers sit within one department, then change management will be simpler.

Have the right skills in your deployment team

It’s important your team has sufficient people and change-management skills to sell the concepts and embed new ways of working. If you only have information and technology experts, you may not have all the skills required.

Identify users of all capabilities and work with them

We already knew members of the deployment team were not representative in terms of their technical proficiency. However, it was still easy to forget that what seems simple to us could be very challenging to some of our CMS users. We found it was good to keep some users who always struggle with technology in mind as we went along.

Allow resources for supporting providers

As well as factoring in time for training and communications, leave some resource slack in your project for the ongoing support of providers. It’s no use training people and then finding you’re too busy with the project to go to their desks to help them.

Limit taxonomy to where it adds value

The other working title for this section was, ‘Beware the enthusiastic information professional’. In our project, that information professional was me. I have since met others like me involved in CMS projects tying themselves up in over-ambitious taxonomy/metadata work.

I was recruited partly for my previous work on organisational taxonomy. I stressed we could use metadata to manage content in the system to reflect our organisational structure for the benefit of content providers, while our website architecture would be structured around user needs. I said we would be able to exchange our information many ways within the site and in the future could restructure the site at any point just by changing metadata queries. We also considered how this could become a full document-management system for the whole organisation outside of the web arena.

This attempt to divorce content management from the website architecture was a mistake. I attempted to define a metadata model that met the differing needs of three audiences: the content provider, the developers and the website users. In trying to be all things to all people, I came up with an over-complex model that didn’t fully meet anyone’s needs.

For content providers, we tried to present them with a content-management structure that represented our organisational structure rather than the site structure. We found the complexity of the model scared them. In the end, it actually turned out to be easier for them to think in terms of the website.

The developers needed unique content identifiers to accurately place content onto the site. They could publish the site through the model but it was a ridiculously over-complex and risky process.

We assumed website users would like advanced searching and that we could automatically generate links to related content through subject metadata. We later realised browsing would be far more important than advanced searching (which most web users do not use) and that sites with related links, including the BBC, usually maintain these manually.

Use metadata that defines site location

The major change we made when we restructured our intranet was to introduce location metadata that specified site location down to two levels. Further complexity beneath this is done with other subject metadata that describes what the content is about.

Be clear what you need taxonomy for

All of your content may benefit from being applied metadata terms as part of a cohesive taxonomy scheme. But we no longer strive towards a global taxonomy that applies to all site content. We avoid using it across organic, small amounts of content where browsing is the predominant way users will access pages. We use more complex metadata in areas of our site only when it adds value and where resources exist to define and maintain the taxonomy.

Situations that respond well to applying subject metadata terms defining the content are:

Available resources to define and maintain the taxonomy. We have classification skills in the web team but these are only useful if subject experts from communities are available to help develop and maintain the list of terms;
Sufficient quantity of content to justify resources used;
Where website users will benefit from advanced search functionality (and are likely to actually use it);
Standardised content where each item shares characteristics, descriptions of products, policies;
When displaying content in multiple ways in one site. For example, we have drop-down menus on the homepage of all the forms and minutes that are published across the intranet;
Identifying metadata is needed to drive workflows.

By working out these principles, we have been able to focus our taxonomy skills on areas where they add value rather than tying ourselves up in work on corporate taxonomy.

Conclusion

Each CMS deployment project is different and will throw up its own challenges specific to the product and the organisation. We were quite ambitious in the scale, complexity and approach to our project. We aimed for an ideal where managing web content is an integral and simple by-product of people’s day-to-day work.

There were many things we got right. The web manager never underestimated the size of the project and subsequently we successfully managed expectations about timescales and justified the considerable resources required.

Having the courage to justify a considerable amount of resources on the people and process aspects of the project has been crucial to the success of the project. Any time we started to get sidetracked on system problems, you could feel the processes start to unravel and grumbles beginning to emerge from providers.

Nevertheless, we were still taken aback by how difficult it was to use the system when we compared it to our impressions during the acquisition process.

In reality, the only experts to tell us how our system would work best for us turned out to be the deployment team, who were gone after we had installed the system. Once we accepted this learning curve into our project, we could start to enjoy ourselves.

We also learnt to manage our own expectations and focus on doing simple things well. We now build websites, working within the characteristics of the system rather than over-customising it to meet our needs.

Our current website at www.wellcome.ac.uk is still managed the old way. Our restructured site will be managed through the CMS and go live this autumn. Most of the expected improvements immediately visible will rely on the information architecture, user testing and development skills of the web team rather than management through a CMS.

But unlike many sites, I have confidence in the continued and improving currency, quality and completeness of the content in the years ahead. This is due to the fact the site is maintained by the people with expertise over its content – a situation that is only possible due to our CMS.