People don’t resist organizational change! – People resist being changed!
My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
My team were worried that rolling out our software would slow and fitful which would threaten the eventual success of the programme. There were a couple of reasons for this worry: the core functionality was complicated and was taking longer than expected to build and, although key to the business, the core functionality was not very exciting. So we backed a couple of side bets, specifically a couple of variations on a "content exchange"; think journalists touting their journalistic wares in an internal market.
These content exchanges directly addressed specific and immediate user needs, needs that were within our general remit but definitely not strategic. They were the kind of thing we might have got to a year or so down the line. Despite the fact they were side bets we went ahead and did the work within the first few months of the programme. This took only a week for a couple of team so the cost was low. But the benefit was immense and the features were run away successes. They addressed the specific need but also created considerable excitement and interest in the wider programme giving us a PR breathing space on the main rollout.
The content exchanges were very much "short term wins" for us (Kotter, 1995). Kotter identified eight steps to transforming organisations with number six being "Planning for and Creating Short-Term Wins". Meeting short term goals and the associated celebrations helps to maintain momentum.
We’ve also used another type of side bet. Unlike the content exchanges where all we did was bring forward something we would have done anyway, the second type of side bet was, nominally at least, outside our scope.
I mentioned Guest Handling in my post on Reinforcing Success but it is also a good example of side bet. Guest Handling was not part of our original scope but we were asked to do a pilot. On balance we decided it would benefit the organisation so was worth investing a week of a developers time to do the work. Then the business ran for a pilot for couple of weeks. The pilot was surprisingly successful. We got good feedback and demonstrated how an automated tool could fill the gap in the current process. This result was sufficient incentive to back the winner and invest more; in fact our business stakeholders were clamouring for a production ready version. Of course we had to trade off requirements and drop other functionality to do this – see Agile Change Management.
As part of our programme we are asking people to do something new, typically abandon whatever method / tool they’re using to do the job and adopting our method / tool. To get the people to change we have to address their unstated question of "What’s in it for me?".
The first and most important question for any individual in any change environment is ‘What’s in it for me?’ – Until this question is answered they will not hear anything else objectively.
A typical example is we need the users to enter metadata fields that didn’t exist in the previous tool.
Unfortunately benefit for the organisation don’t cut it, at least for most people, and we need something more individual. That is where "Sweeties" come in. We’re not talking chocolate here or monetary incentives. We’re talking features of the product that make it the user’s life easier.
The first example is on our deployment sheets. These are literally sheets of paper issued to News crews as they walk out the door with information about the story in question, where the crew have to go to, and what to do when they get there. If the resource manager has time they’ll also look up the address in google maps and print out a map of the destination to give to the crew. To encourage the resource manager to use our replacement system we bundled an automatically generated map with the new deployment sheet – the sweetie. It probably only saved a few seconds from their workflow but every second counts.
The second example is people locator. This is a tool we built so enable the newsgathering department to track where in the globe their people are – something that had been quite difficult. Of course to get that benefit – the sweetie – newsgathering staff had to enter people into the new system as meta-data – the behaviour we wanted to encourage – whereas in the old system they could type anything they wanted.
Kotter, J. P. (Mar-Apr 1995). Leading Change: Why Transformations Efforts Fail. Harvard Business Review, p. 61-67.