Wait: you need to read part 1 and part 2 first!
The fun side of cultural change
You’ll remember that last week I discussed the crucial need for a cultural change in how we dealt with time logging. After the CX team’s thorough research, we were ready to take the findings – and our ideas – to our board of directors.
The first thing we showed them was our low-hanging fruit - a solution to the problem of people not remembering to regularly log their time. One of our in-house designers had created some fun posters to stick up around the office. A while back, we had an internal photoshoot as part of our rebrand, and we used our peer’s funny photos in the posters. With their permission of course!
We had approval to put them up straight away. This was a great start. We didn’t need to have a new system to start implementing this kind of cultural change. Everyone found the posters fun and entertaining, and we still have them around the office today.
Changing the system
Then came the more challenging part - justifying a change to our internal systems. We approached this in a structured format, leaving the best for last. First, we talked through all of the analysis we had done in the exploration phase, to prove why we needed a new system and a new time logging process. Then, we went into the details of how we selected the two potential options, along with the benefits that each would bring, and the cost implications.
We introduced both systems to the directors in a similar way to what we’d done for developers, and went into demo mode of each, answering the directors’ questions as we went along. At this point, it was clear that the room was leaning towards System A, just as the operations team had done when they saw the systems. System A was easy to manage and made it easy to get reports. The interface was also very similar to our existing time logging system, so the change needed was minimal.
Then, we showed them the results of the survey we had done at the end of the developers’ workshops. It turned out that pain points were lessened by more than half by System B compared to System A. Developers thought that System B would foster daily time logging from them as opposed to weekly with System A. All but one person thought their time logging would be more accurate with System B. On the final question about which system they would choose if it was up to them, all but one answered System B. The results were astounding. It was not what had been preferred from a management perspective at all, and without this feedback it would not have been the selected system. Of course, this information changed the game, and the directors immediately agreed the answer was to implement System B. The operations team and managers could adjust to a new way of working; the most important thing was to have a system that the developers actually wanted to use.
At the next company meeting, we announced the good news. Shortly after, we rolled out our chosen system: Tempo Timesheets (a JIRA add-on). We provided training to all of our different user groups.
Since then, nobody has looked back. This is not to say that everything is perfect, and as with any rollout, the cycle of continuous improvement should always follow. However, whenever people are asked in feedback sessions if they prefer the new system to the old, they chuckle and immediately agree it’s miles better.
Lessons learned
There’s really only one moral of this story, that really must always be top priority for any implementation; a system is useless if your users won’t use it. Listen to your users, have a plan for how to manage the change and approach it openly and honestly involving different areas of the business, and of course, make sure that what you deliver is something they genuinely want to use.
