Step Two Designs

CASE STUDY (AUGUST 2001)

RTA Case Study

Written by James Robertson, published August 10th, 2001

Categorised under: articles, case studies, intranets

Please note that we no longer develop or sell content management solutions. This case study demonstrates the basis for our current content management experience, and we now focus solely on providing vendor-neutral advice regarding CMS selection and implementation.

Overview

In October 2000, Step Two Designs won the open tender to develop a Knowledge Management System (KMS) for the RTA. Despite competition from other KM vendors, we were able to demonstrate the value of the solution we developed for the NRMA (see the NRMA Case Study).

Our proposal for the RTA project was built upon NRMA’s proven XML-based publishing system, customised to meet the RTA’s specific requirements. In this way, the RTA could be confident that they had a stable base on which to develop.

The users

The KMS project focused on users in the newly-developed Newcastle Call Centre (NCC). This 150-person centre was created by consolidating a number of smaller call centres into the one large facility.

This was a high profile project within the RTA, and one that had proceeded more quickly than anyone had expected. With the flood of new staff into the centre, there was a clear need to support these less experienced users with effective information.

The KMS project was therefore initiated, with the following goals:

• Provide improved service and information to customers
• Help new staff bridge their initial knowledge gap of RTA policy and procedures
• Reduce training costs
• Help reduce average call handling time
• Reduce escalation to the team leaders and help desk

The team

With the initiation of the project, a team was established consisting of:

• Team leader (Sandra Whittle)

  Sandra developed the initial business requirements documents, wrote the business case and chaired the tendering process. She was the main point of contact between the project and the business, with responsibility for leading all change management activities.

  On top of this, Sandra was responsible for project management, selecting and hiring staff, and the myriad of other day-to-day activities required to keep a busy project running.

• Technical Writers

  Two contract technical writers were hired into the team. They provided invaluable experience and knowledge, ensuring the overall quality and consistency of the content.

• Subject Matter Experts (SMEs)

  Two staff were brought into the team on secondment from the help desk. Each had over ten years experience in the RTA, and were our main source of accurate information about the RTA’s policies and procedures.

• Step Two Designs

  As the vendor, we provided installation, customisation and technical support. We also provided key skills in: knowledge management, information design, usability and change management.

It is worth highlighting the importance of having a balanced mix of professional technical writers and subject matter experts. Without the former, the quality will be poor. Without the latter, the writers have limited knowledge of the subject matter.

Information design

The most important first step was to identify the information that would be published by the Knowledge Management System (KMS). A thorough review of current manuals was completed, and a comprehensive list developed.

This was then used as the starting point for several "card sorting sessions" with the actual users at the Call Centre. (See our white paper on card sorting for details on how to use this technique.)

These sessions:

• Introduced us, and the project, to our end users.
• Gave us a clear idea of how they use the information. This determined the main menu, and the overall structure of the content.
• Provided an opportunity to hear the users’ issues, and to get a sense of the actual needs of the Call Centre.

This was the first of many visits to the Call Centre over the lifetime of the project.

With this information in hand, we then started a six week process of creating the information design. This addressed many different areas:

• overall structure of the content
• site navigation
• appearance of the pages
• writing standards
• linking conventions
• technical improvements required to support the design

Much of this was determined by taking actual examples, and working through them as a team. We would solve the large issues, and then create a new draft. This draft would then be brought back to the team and further discussed. We kept doing this until a consensus was reached.

While the design process was long and demanding, it provided many benefits:

• We developed a Style Guide detailing writing standards.
• Working as a team ensured that everyone understood the issues and resolutions.
• All team members had valuable contributions to make to the overall design.
• Each member brought different knowledge and experience to the table.
• This large task could be shared amongst the group as a whole.

We left this phase with a set of "gold standard" topics to use as examples, and a clear understanding of our goals and strategies.

Capturing knowledge

Three key areas of content were identified for Phase 1 of the project:

• Context-sensitive (F1) help for the frontline system (called DRIVES)
• Frequently Asked Questions (FAQs) covering common problems and issues
• Other commonly-used information, such as Fees and Charges

Much of this work involved converting tacit (undocumented) knowledge to explicit (documented) knowledge, as neither F1 help or the FAQs had previously been created within the RTA. We were lucky to have two of the most knowledgeable people in the RTA to act as subject matter experts, and much of the information came directly out of their heads.

Where information already existed within the RTA, it required restructuring or rewriting, to bring it up-to-date and to make it easy to read. The users were also a valuable source of feedback and suggestions, and were often able to identify errors or omissions.

To ensure the quality and accuracy of the information, we put in place a formalised review process. This involved three groups identified as the "content owners" along with the help desk staff at the Newcastle Call Centre. Although this review process was arduous, it was critical to building confidence in the system throughout the RTA.

Interface design

With the information design complete, and content flowing rapidly into the system, we tackled the appearance of the HTML. While this was a largely cosmetic exercise, we had to meet certain challenges:

• Within the RTA, three browsers are used: Netscape 4.7, Internet Explorer 5.0 and ICE (a Java-based browser). While these browsers have considerably different functionality and capabilities, all had to be supported by the publishing system.
• A clean, attractive and easy-to-read page layout was required.
• Effective navigation was needed to ensure that users could find their way around the thousands of pages of content.

While feedback from users was that they "weren’t interested in how it looks, only what it says", the interface design process still generated rewards. With a professional and attractive image, it became easy to market the system to middle and upper management. After all, a good-looking system generates much greater excitement on first glance, and the impact of such enthusiasm should not be dismissed lightly.

Publishing system

The core of the publishing system was the authoring environment first developed for the NRMA. In brief, it comprises:

• A full authoring interface developed in Delphi.
• A database for storing the content.
• Exporting the content to XML.
• Publishing to HTML and Word, using Omnimark.

This system provides many benefits, and has proven to be very stable over its three-year life at the NRMA. For a detailed description of this system, see the NRMA Case Study, which outlines features and benefits, and provides screenshots.

Our big advantage at the RTA was that by taking the NRMA system as a starting point, we could continue to develop a more extensive and powerful solution.

Our work has focused on developing the publishing workflow, built around a number of Apache webservers. This was designed as follows:

• The publishing system places the generated HTML on the development webserver, which allows the authors to view their content as it would appear in production. This is also the test area for new code development.
• When the content is ready, it is promoted to the staging webserver, where it is reviewed by the content owners. This machine is a core part of the quality control (QC) process.
• Once the final checking is complete, the content is sent to the production webserver. This is then accessed by the end users.

These servers utilise the very popular Apache webserver software, installed on Sun X1 rack-mount boxes running Solaris 8. Careful design of these machines allowed us to deploy a number of valuable features:

• Stamp duty calculator

  This web-based calculator for determining the stamp duty on a vehicle took only a few days to develop, but eliminated a dozen pages of tables. Not only does this save time for the frontline staff, it also reduces errors.

  Behind the scenes, a web-based admin page allows the authors to update the calculations at the click of a button.

• News

  The front page will shortly feature a sidebar with the latest news. Developed using PHP, this system is quick to use, and easy to browse. The authors create and manage items using a straightforward web interface.

• Feedback page

  Although this seemed like an obvious feature to us, it turned out to be somewhat of a revolution for frontline staff. For the first time, they could simply enter comments into an online form, and know that they would reach the authors.

• Web-based admin

  A comprehensive admin interface is accessible online by the authors and administrators. This gives them the ability to browse a number of reports, and update various configuration settings. By delivering via a web browser, it allowed us to create a simple and secure interface; remote admin also becomes easy.

  There are a number of core components of this admin interface, described in the following sections:

• Web statistics

  We track the number of hits on the webserver, along with the most popular pages. This gives a clear picture of overall usage, and helps us to judge the success of our training and marketing.

• Context-sensitive help usage

  Every use of F1 is logged in the system. This is summarised in a report showing the most used pages in the system. Another report lists the pages for which we have not yet developed help, thereby determining a "hit list" for creating new pages.

• Search engine usage

  Use of the search engine is also logged, and several reports are generated. The first is a summary of search usage (by month), showing the most popular terms used, and the number of matching topics.

  The other main report shows the "failed searches"; that is, the searches that returned zero hits. This is a clear indication of information that users want, that we have not yet provided.

• Search synonyms

  The failed searches report also highlighted a number of typos, due no doubt to the time pressures at the call centre. One common error: instead of "quarterly", they would enter quot;quartly", "quartely", or "quately".

  Based on this evidence, we developed a web interface for entering search synonyms (terms that are equivalent). The authors then entered the common misspellings into this list, along with other matching terms. This has now significantly reduced the number of "failed searches".

What surprised us is that while most people were enthusiastic about the content, there was equal interest in the admin pages. These pages gave people greater confidence in the system, and helped to assure them that someone would be keeping an eye on how the system was going. It also gave a sense of "transparency" in the way the system worked.

The technical writers have also made extensive use of these admin pages, and have quickly incorporated them into their daily routine. Already, the creation of new content is being driven by the statistics gathered off the webserver, and feedback received from the end users.

Marketing the project

Before the release of the system, we had succeeded in generating a high level of enthusiasm and expectation. When the final system did everything that we had earlier shown them, this was translated into a rapid uptake, and considerable positive feedback.

How did we achieve this outcome?

Communication plan

The team developed and documented a communication plan in an early phase of the project. This identified:

• key audiences
• messages that needed to be communicated
• methods of delivery (news items, face-to-face, etc)
• milestone dates

By creating a formalised plan, it became possible to coordinate all communication activities. This maximised the impact of our efforts, and ensured that our messages were being received and understood.

Local visits

Throughout the project, we made a number of trips to the Call Centre. On each trip, we organised a session with the two user groups (the telephone operators and the help desk staff).

In each session, we gave a demonstration of the system as it stood at that point. Initially, what we were showing was quite rough, and far from complete. We then listened to their comments and incorporated their feedback.

We gained credibility by acting on their comments, so that at the next trip, they could see the updated system. We found both groups to be the source of many good ideas.

We also kept the Centre’s management informed of our progress, and reported any issues that arose.

Occasionally, we prepared a survey or activity (such as the card sorting discussed earlier). These structured methods helped us to solve specific issues, and we always ensured that the results were communicated back to the staff.

By picking a different group of staff during every visit, we ensured that almost all of the Centre had seen the system before it went live. Those that had missed out during a visit were quickly informed via word-of-mouth.

Company news

The team prepared an article for the company newsletter, briefly outlining our project and its goals. This allowed us to reach a wide internal audience.

Project brochure

Just before "go live" the team designed a one page, full colour brochure. This was professionally prepared and printed.

This brochure told staff that "Frontline Help is coming!", as well as providing screenshots, and highlighting the system’s features and benefits. A copy was placed on every desk at the Call Centre, and further copies were distributed to the managers and team leaders.

As it turned out, this may not have been necessary for the frontline staff (as almost everyone had already seen one of our demonstrations). It did, however, prove invaluable in lifting our profile within the business. This generated enthusiasm amongst the "head office" groups, which assisted greatly when we started discussing formal business processes.

Knowledge management

There are many aspects to a knowledge management project, the least of which is perhaps the technology. In this project, the team:

• Created an authoring team
• Established a working environment for the team
• Designed and deployed a technical infrastructure
• Determined user requirements
• Structured the information
• Conducted usability testing
• Captured tacit knowledge
• Improved and reworked existing explicit knowledge
• Developed a review and sign-off process
• Deployed a publishing system
• Developed a communication strategy
• Created and implemented a training plan
• Marketed the project
• Ensured user acceptance

This took some time (six months), but all these areas (and more) must be addressed if a project is to be
successful. Of these, the most important issues are those relating to users. If they are not happy with the system, it will fail.

The Future

The project has been received enthusiastically by the end users and their managers, and usage is growing rapidly.

The challenge is to now convert this once-off project into a permanent team with the responsibility to maintain and grow the knowledge repository.

With word of the project spreading rapidly, we have been very surprised by the interest and enthusiasm shown by even upper levels of management. As a result, we are confident that a team will soon be in place.

Once the team has been finalised, the processes of information capture, review and publishing must then become a normal part of the daily operations within the RTA. If this is not the case, the information will become stale, and users will lose confidence.

With several groups already clamouring to put information into the system, we see a rosy future for the system, resulting in the creation of an invaluable one-stop-shop for all of RTA’s frontline staff.

Screenshots

Tags: call centre, case study, content management, intranets, needs analysis