If You Feed Them, They Will Come

Reader ROI

  • Why end-user adoption is a process, not a project
  • How to gain valuable feedback from the end users
  • Ways to improve the vendor selection process

This is a story for any CIO who has yet to fully internalize one of the hardest and least intuitive lessons of IT: that end-user adoption must always be a process, never a project.

Canadian Janet Blais, director of information technology at the Institute of Chartered Accountants of Ontario, admits she had to relearn the hard way, and at pretty high cost, how quickly a complex and expensive IT system can become shelfware without user buy-in. And she concedes turning end-user adoption into a process, rather than a project, involved plenty of trial and error. It was an effort that took some time to pay off, although pay off it certainly did.

However, these days, she says, with an extraordinarily successful buy-in process under her belt, she has become a bit of an ambassador for the idea of making end-user adoption a process. Whenever she talks to a fellow CIO struggling to implement software, she has found the problem is usually due to a lack of acceptance and enthusiasm from users. Yet given how frequently the necessity of buy-in has been aired over the years, she is still surprised how often the question, 'What do your end users think?' earns the reply, 'I don't know, we didn't ask them', from those frustrated, if naive, IT practitioners. Her message to them mdash; get users involved from the very beginning via a carefully considered process mdash; might be painful for some CIOs' egos but it can generate a massive pay-off.

It is not that Blais had not involved users in the implementation of products before mdash; she most certainly had, although more typically in the form of a project, rather than a process. Blais has, after all, been with the institute's technology area for more than 28 years. She has been through all its growing pains from technology to technology, and devised her own methodology for selecting new products and winning buy-in. But the institute's first content management system (CMS) was basically an IT-driven project, largely because no one had a clear idea at the time of what was required. She has no doubt that was the root of most of that system's ills.

"That was really an oversight on my part because it was new territory for us. If the users had been involved from the start, we might have been more successful because we would have had their support and cooperation. Because we didn't involve them from the get-go, the users did not feel they were a part of the process.

"Our members visit our Web site every day looking for current CA [chartered accountant] news items, applications, events and more. Because it's such an important part of member communications, our Web site is constantly being updated to keep it fresh. It is important for the staff who update the site to have an efficient CMS system that is easy to use," Blais says.

Page Break

Round One: A Big Mistake

Headquartered in Toronto, Ontario, Canada, the institute is the qualifying and regulatory body of Ontario's 32,000 CAs and 4000 CA students. Since 1879, the institute has protected the public interest through the CA profession's high standards of qualification and the enforcement of its rules of professional conduct.

When the institute set out to buy its first content management system as a very early adopter, its IT team chose a product they believed met their criteria and budget. That system was then presented to users as a fait accompli. The approach proved to be a big mistake. The institute's relatively unsophisticated users, still grappling with the idea of Web content, found the product unduly complicated. The institute's IT team found its efforts to get users to buy in and take ownership of the system were not well received by all staff.

"The institute was quite early in terms of developing Internet access and building a Web site, which was originally hosted outside. That meant whenever we wanted to make changes to content mdash; even a simple data change or the removing of old content mdash; we had to talk to the hosting company, and then wait . . . Still, it was only after we brought that Web site in-house that we understood why we needed content management," Blais says.

So, while the CMS met all of the IT requirements and was a good product to boot, (despite taking a full year to install and put into production), it was never going to be considered "successful" because it did not really meet the users' needs.

There were other issues as well. Since the software was not easy to use or very flexible, the Webmaster still needed to manage most aspects of content publishing. This created bottlenecks for getting content published on a timely basis. Enhanced workflow capabilities were also needed but unavailable and the performance was unacceptable to the point that some of the content was actually stored outside the CMS.

With the institute's growing and increased reliance on the Web site as a communications tool for its members, the previous CMS was struggling to keep pace.

"On occasions of heavy activity by our membership, we experienced major performance degradation due to the dynamic method of serving pages to users directly from the database. This was often complicated if the content was stored in a secure area of the Web site and needed user authentication," Blais recalls. "It forced us to publish the more popular content outside of the CMS."

The second time around, the institute wanted to do things differently. Blais was determined to undertake a process of end-user adoption through getting the users to provide input from day one. The first step was to meet with the users and together define the pros and cons of the current CMS, to hear what the users were looking for in a replacement CMS and to define the criteria for success that the new project would be measured against.

Page Break

Learning from the Past

Faithful to her new understanding that it takes a process to secure end-user adoption, this time Blais was determined to involve users in the selection process from the start. The theory was that, after the last unfortunate experience, a good mix of end users and IT working together would do a much better job of successfully selecting the new CMS system. That meant contacting the directors of the various areas within the institute and asking them to assign someone to sit in on meetings mdash; an approach that was warmly received.

"Often, in addition to the area staff who would be future users of a new CMS system, the directors themselves wanted some involvement, which was fine," Blais says.

"What we said to them right from the start was: 'This is a product that you will be using. We're going to install it, we're going to manage it, but you're going to use it, because IT does not create content. We will make sure that we have the right infrastructure in place and that we build security to authenticate the members. We will make sure that we back up the Web site and will fine-tune it to ensure it performs from a technical aspect. But as far as the detailed creating, publishing, editing and approval processes go, as users, you own that.'"

With the users drafted, Blais then met with the group to reach a common understanding of the deficiencies with the current CMS, as well as its advantages. She also drew input from IT staff and then reviewed the lists carefully to ensure the requirements were clearly defined and reasonable.

Users quickly made clear they wanted enhanced workflow so that prepared content could be routed to one or more approvers. They wanted enhanced performance to eliminate complaints from members about not being able to get to the content because of the speed of the Web site.

But the institute's first content management system (CMS) was basically an IT-driven project, largely because no one had a clear idea at the time of what was required- Janet Blais, director of information technology, Institute of Chartered Accountants of Ontario

Having waited a year for the first CMS to be installed, they wanted it to be up and running in a reasonable time frame. And they wanted to simultaneously see a full redesign of the Web site, with a new look and feel and a bit of "splash" that would encourage members to make more use of the site. Without consultation with the users at this stage, Blais says, some or all of those criteria might again have been missed.

"We had to rebuild the IT reputation a little bit here," Blais says. "But more importantly, we wanted to ensure users had some ownership of both the process and the software that was selected. We felt if we had their input to initially help us develop and work with the product, when we were ready to go live everybody would be ready at the same time."

Blais encouraged users involved in selection to actively research the market for available solutions. Getting users to research and identify potential solutions was, she says, the easiest way to make them aware of the functionality on offer so they could consider its importance and make informed decisions at subsequent meetings. Some of the users chose not to become directly involved, perhaps based on other commitments and lack of time, and trusted that those who did would apply diligence. But others welcomed the opportunity to do some research and came back with some valuable input.

Page Break

Blais took everything into consideration, and followed every Web link the users pointed her towards. Then she developed a massive spreadsheet showing the functionalities each system had to offer and reviewing the list of pros and cons previously defined. Armed with this information, the team sat down as a group to distinguish between necessary and merely desirable features, and to consider any trade-offs involved in incorporating some of the merely desirable ones.

Together, they then selected a list of seven vendors to send the initial list of requirements to, making sure first that they were interested in winning the business and could meet a defined date for submitting responses. Next, the team considered vendor responses at a round-table discussion where they reviewed the "new" features and functions that each vendor was highlighting within their product, while eliminating vendors whose responses did not meet the basic requirements.

The users and IT group then developed a supplementary list of questions and requirements for the remaining vendors concerning additional product functionality, training details, the technical specifications, pricing, licensing information and implementation costs, as well as the schedules and the support offered by each vendor.

Once the vendors responded, the selection team reviewed all the responses and narrowed the choices down to three products. "I don't remember any disagreement," Blais says. "By the time we put the questions together we had already weighted the various features. So we were all on the same page, since we had been working together on all aspects of this project."

Next came the on-site demonstrations or Webcasts of the products for both technical staff and users, with vendors told to allow plenty of time for questions. That tactic ensured the vendors had technical staff on hand during every demonstration. After the demonstrations, the IT group met to discuss the products' infrastructure, components and fit, while users reviewed their features and functionality. "When we got down to three, all of them managed content quite well," Blais says.

"One was more of a Cadillac than the other two, but the price was a little higher as well.

"In consultation with the users, I then prepared a list of questions that I was going to be asking the vendors' references. The same questions would be asked to each of the references. I let the users know that, if they had any specific issues that they wanted to discuss with other end users of the product, I would try and arrange for that as well.

"The reference contacts were very informative and helpful. All of the reference responses were documented and then shared and discussed with the entire group."

The decision to go with Percussion Software's Rhythmyx Enterprise Content Management (ECM) solution was unanimous. Blais says users were particularly taken with Rhythmyx's de-coupled delivery architecture, which appeared capable of boosting performance and eliminating the CMS as a single point of failure, as well as some unique features that were not available from the other vendors' products.

Page Break

Far from the End

However, Blais says securing user buy-in involves more than just letting users play a part in product selection. To ensure their ongoing commitment, their involvement in planning needs to go much further.

With a product selected, Blais hosted an initial planning meeting to identify the IT staff who would be on the implementation team, the Web development staff who would handle graphic design and navigation, and key users responsible for creating, approving and publishing Web content. She also asked the vendor to identify their key implementation consultants.

1 2 Page 1
Page 1 of 2
Security vs. innovation: IT's trickiest balancing act