If You Feed Them, They Will Come
- 03 April, 2007 12:19
- 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 — get users involved from the very beginning via a carefully considered process — 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 — 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.
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 — even a simple data change or the removing of old content — 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.
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 — 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
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.
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.
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.
The identified staff and implementation consultants joined forces to define the time lines for training, conversion/migration, graphic design submissions, template definitions, navigation, workflow requirements, testing and the go-live date.
Blais made sure all key players committed themselves to the effort involved in making implementation successful and that users had input to all phases of design, navigation and workflow components. "We established a commitment from users on their availability to perform testing and review during the process and adjusted our time lines based on that availability," she says. "We took into consideration the workload of both IT and users during this time frame and reviewed the new time lines with both groups to ensure consensus."
They identified milestones and attached dates to each, and held regular meetings with the implementation team so they could discuss their issues and concerns. Milestone dates were often reviewed to ensure they were met and time lines revised when necessary. "It was a busy process as this was over and above the regular work that we do on a daily basis. But the users were keen, enthusiastic and they wanted it to be successful.
Most importantly, Blais says, without the enthusiastic support of users, the new solution could well have taken as long as the old one to get up and running. Instead, working with consultants, users sat down and charted the workflow for their own development.
"They were able to bring their business processes to the table and to build their required workflow processes. We were able to adapt to new and revised workflow processes driven by user requirements."
Thanks in large part to the software's de-coupled delivery, institute members are now experiencing exceptional performance on Web site response times. As an added bonus, the de-coupled delivery allows the institute to freely work on the database, updating software and performing other database maintenance activities without having to take down the Web site during these processes.
Several departments have responsibility for managing Web content, and are now able ("active assembly" lets users independently make page layout changes on their own content pages) and willing to do so. And with users assuming ownership of content, the Webmaster can now spend time developing and enhancing the CMS system to keep pace with business requirements.
Food, Glorious Food
Since the implementation, Blais has been presenting a paper called "End-User Adoption is a Process, Not a Project" at IT seminars across Ontario. In addition to her main message, she has also been sharing a secret with fellow IT executives desperate to get their users on side: If you feed them, they will come.
"It's one thing I learned about users — feed them and they will always show up. So when I had a nine o'clock meeting I would order in continental breakfast from 8.50am. It's amazing: they would come 15 minutes early just to ensure they had their choice of pastry," Blais says.
"What does a continental breakfast cost — two or three dollars a person? And you know what? I didn't have anybody walking in half an hour after the meeting started or not showing up. If people said they were coming, they came. And I know that part of it was because we fed them. It does work, and it doesn't matter whether you're doing content management or a database system, or a membership system or a financial system, if you really want to be successful, I know now that you need to really involve your users. And feeding them helps.
"When the consultants were here, I would order in lunch and I would invite the key people to come and have lunch with the consultants, even if they weren't working with them yet. Over these lunches the users started to become familiar with the consultants and their personalities — you know, to build this level of comfort."
Blais thinks she has discovered the secret to successfully implementing complex IT projects. Not bad for the cost of a few muffins and recognition that process, not project, is the key word to describe end-user adoption.
Sidebar:Steps to Successful Vendor Selection
A long journey, but worth it
- » List of Requirements
- Asked the users to provide input — based on their needs in a replacement CMS
- Asked the IT staff and Web developers to provide input — based on their needs in a replacement CMS
- Reviewed the lists carefully to ensure the requirements were clearly defined and reasonable — reviewed the list of cons previously defined
- Encouraged the users to research the market on what software was available and receiving some recognition through Internet searches, magazines etc
- » Vendor Selection
- Selected vendors to send the first list of requirements to
- Contacted the vendors to identify the sales
- Ensured they were interested in winning the business
- Knew our budget limitations
- » Distributed Requirements
- Gave the vendors a reasonable date for submitting their responses
- Offered to clarify any requirements and shared the clarification with all of the vendors
- Eliminated vendors who did not respond or did not respond by the defined date
- Prepared a spreadsheet of responses for easy comparison by both users and IT
- » Response Review
- Key users reviewed the responses at a roundtable discussion
- Reviewed the "new" features and functions of products
- Identified and defined the key requirements of a new CMS
- Eliminated vendors whose responses did not meet these requirements
- » Vendor Follow-Up
- Worked with users and IT and developed a supplementary list of questions/requirements for the remaining vendors
- Additional product functionality
- Training details
- Technical specifications of the product
- Pricing information
- Licensing information
- Implementation costs and schedules
- Consultants and support offered by each vendor
- » Product Demo
- On-site or Webcast demos arranged
- Vendors informed of end-user and technical staff participation, so they could prepare accordingly
- » User and IT Review
- IT group met to discuss infrastructure, components and fit with our infrastructure
- Features and functionality of each product were reviewed with users
- Identified the three product solutions that fit most of our needs
- » Licensing and Maintenance
- Licensing costs
- Multiple Web sites
- Concurrent users
- Does test environment count as a licence?
- Maintenance costs
- What percentage of the retail cost?
- Phone support/online support
- Are all updates and new releases included?
- How many users can log support calls?
- What is the response window?
- What is the escalation procedure?
- » Implementation Questions
- Estimate of time for implementation
- Vendor's involvement
- Local consultants
- Consultant expenses and their guidelines
- The availability of their consultants
- » Final Product Demo
- Short listed vendors invited on-site for an in-depth product demo and final review
- Key users invited
- Worked with the users in preparing a pro and con list of the final products
- Vendors asked to submit a formal price quote (best price)
- Requested at least two referees that had been using the product for at least one year
- » Reference Checks
- Each referee was asked to respond to a list of questions, which included user queries
- If the contact could not answer all of the questions, we asked if there was someone else who could
- Responses were documented and shared with both the users and IT staff
- » Choosing the Winner
- Reviewed the price quotes noting any available discounts
- MADE THE BIG DECISION
- Notified the successful vendor and booked the first planning meeting
- Notified the vendors who were not successful
Source: Janet Blais, Director of IT, Institute of Chartered Accountants of Ontario