Capability Stairsteps

When we begin a new deployment of our software applications at an organization, we always ask the users "How will you know if this project was a success or not?" We're usually expecting to hear things like "Our staff will spend significantly less time putting together monthly reports" or "We will finally have agreement between the membership lists on the website and in the AMS." But at a recent project kickoff the bar for success was really low: "Our staff will actually use the system." Problems with the adoption of new IT tools can rob an implementation of much of its ROI. And the the solution is not simply making sure you've picked the right tool and delivered the proper training. There are specific steps that need to be taken to encourage user adoption. My friend Russ Eisentstat of TruePoint uses the phrase "capability stairsteps" to emphasize the incremental nature of such transitions. These steps may involve partial use of the new tool, use by a subset of the eventual target user community, or both. But before you can climb these steps you need to design them - adoption will not necessarily spread naturally or completely unless the organization creates a plan and monitors it. The example Russ and I discussed related to the use of a wiki to capture organizational knowledge. One of my long-standing contentions is that an enormous amount of organizational knowledge exists in emails between stakeholders. If these emails were simply captured and organized, a great deal of knowledge documentation could be managed with little or no new writing. But both of us had limited success in encouraging our own organizations to use our wiki. What would a stairstep model for adoption of the wiki look like? First we need to put someone in charge! This is a step that is often ignored in this type of change management. Someone needs to take personal responsibility for the effort to develop the wiki into a useful tool. As soon as we have identified the wikimaster, we have at least one more committed user. The next step is to identify the barriers to adoption so we can plan to eliminate them. Russ and I both agreed that the main barrier is the catch 22 of social sites: the wiki is not attractive to users if it is not yet rich with useful information -- but this will not happen until people begin using it. This barrier can be reduced by "priming the pump." Step two is that the wikimaster takes active responsibility for getting the first fifty articles on the site. He can poll users frequently to get them to send him any material that would be apporpriate for inclusion. This spreads some buzz about the wiki without asking people to utilize it themselves in any way. A second barrier: it takes a bit more learning to become adept at posting than just to read the site. So this suggests the next increment. Step three is to encourage the use of the wiki as a passive repository of information, without leaning on people to post. People can still rely on the wikimaster to post their articles, but can begin to turn to the wiki to look for information they might need. Only now do we tackle active contribution - again a step at a time. In Step four might the wikimaster to encourages people to comment on exisiting articles - reminding them of this capability, and having existing champions comment to prime the discussion on this forum. Step five might be then to put in place rules for how others should post their own articles - how to tag them, how to deal with the home page, how new articles are announced, and so on. At this point a training or informational session might be held for new posters. So what I had thought was a one step procedure - "let's start using this new tool" - has become a five step staircase. This model of identifying barriers and building a step to climb over each one in sequence can be used to encourage adoption of systems of all kinds.

Five tips for software systems training

My good friend Adriano Pianesi, the former trainer at Members Only Software, has taken the bull by the horns and announced the creation of his own training consultancy, Participaction. Take a look at this site - you'll see his approach goes way beyond drilling users on what button to click when. Adriano and I have had some long conversations over the years about how to best provide the training organizations need to make effective use of their information systems, and he led us in experimenting with a lot of different ways of doing training. We've led some awful sessions and some great ones. Eventually, we found that traditional classroom training was rarely the solution. Here are some of the things we learned: 1. Information Systems training needs to focus more on organizational policy and business practices than on technology. It's easy to teach someone how to issue an invoice. But who is the customer? When are invoices issued? What should you do if the system warns that an account code was not set up properly? Without this kind of knowledge, your users will have a long slow climb to productivity on the new system. But its not the software guys who know this. So the training needs to be a collaboration. 2. Information Systems rollout trainings need to include a change management component. Mission critical software rollouts have broad implications for the way people work. Otherwise, why bother? But to say "this will make our work easier" or "these tools will help our teams collaborate" just skims the surface. The users know the new system will alter their day-to-day lives. They may be eager for the change, afraid of it, or just plain resentful of the disruption. The training is a time to prepare for procedural upheavals. 3. Training needs to be active and interactive. Presentation and drill on the workings of the system are boring and ineffective. Training sessions need to actively engage the user from the first minute. We found, for example, that a treasure hunt -- plopping the users in teams in front of the new system and asking them to figure how to find things was far more effective than a presentation of where key information is to be found. 4. Your organization needs a plan for ongoing training. This is an area we see most organizations neglecting. Everyone knows they need new system training. But how will you deal with staff turnover? After a couple years, some of your key users will move on, and you will have new staff members who come in and find the system already in place. You need to create sustainable plan to train these new staff members without constantly paying someone from the outside to do it. You need ongoing training for other reasons, too. Staff forget things they learned but have not been using. And the software has seen a few updates by now - are you sure you are getting the full use out of your applications? 5. The answers to most of your ongoing training needs are already in your organization. The ongoing training is not as difficult to organize as you might imagine, because someone in your organization knows the answer to almost every question someone else has. The challenge is to make the knowledge accessible to your users. We did an advanced users training a few years back at one of our YMCAs. People were asked to submit questions in advance - and we got 56 of them. At the training, we broke the sixteen participants into tables of four and randomly distributed the questions to the tables. Each table was to present to the group the answers to the questions they'd been dealt. If no one at the table new the answer, they'd solicit help from other tables. On only 6 out of the 56 questions was our help needed at all. So the real issue had not been training in the traditional sense - but simply setting up a structure for sharing the information. image originally uploaded as http://www.flickr.com/photos/leighblackall/76202405/

The permanent Beta?

Browsing through some old posts in the always worthwhile Creating Passionate Users blog, I came across this interesting post from last March: Ultra-fast release cycles and the new plane. The post is about the growing popularity of extremely short turn arounds between versions that has become characteristic of web2.0-type development - what O'Reilly called the permanent beta. This is an issue we discuss in our office quite a bit. We have some users who demand rapid release. They feel that if they find a small bug on Monday, dream up a new piece of functionality they'd like on Wednesday, and want the menus reorganized on Friday, they should certainly be allowed three versions that week. After all, they're paying. What about the increased risk of defects? Well, they don't mind... they'll report them and they will be fixed in the next rapid release. On the other hand, we have users who despise the rapid release. These clients expect us to organize their requests, implement them all, test them all, and give them an upgrade once or twice a year at most. Installing any more often, they've told us, complicates user training and increases the risk that a new release will break something that was already working. Far from demanding rapid release, they see it as a lack of professionalism. How do we understand this difference? In the Creating Passionate Users piece, Kathy Sierra talks about the short-release trend as a "cultural" one. She's focusing on the youthful subscribers to the Myspace website, her model of the rapid release project. So she focuses on factors relating to youth culture. What she does not dwell on is that Myspace is fundementally different from business software - it is not critical to most users' bottom lines. Let's look at this "cultural" difference among the staff of non-profit organizations using our Members Only software. It seems to me the difference here hinges on the perception of real costs and real risks associated with installing a new version. These costs and risks actually differ significantly between organizations, so the evolution of different cultures around software installation is not at all irrational. It has to do with the organization's size (in number of users, and in number of locations) and the level of activity (How many transactions go through the software in an average day.) Large organization using software for mission critical purposes are aware of the costs of training and of the bottom-line impact of a significant defect, and therefore want to minimize the number of training and testing cycles they expose themselves to. Where does you organization fit on this spectrum? Are you happy to use a permanent beta? Are new features on a regular basis worth encountering bugs you will need to report? Are you the kind of user who is always pushing for the next update, or are you loathe to install them? What factors have shaped your attitudes?