Hint: you'll need to read part 1 first for this post to make sense.
Phase 2: Imagine
The CX team got together to discuss the problems and carry out an internal ideation workshop to tackle them. We knew that we had 3 key tasks:
- Improve people’s knowledge of why time logging is important
- Create a culture of time logging as a habit; and
- Make the systems they needed to use simpler and clearer while having less of them!
Knowing that there was no room for improvement with our existing official timesheet system, we started to look at the market. We were looking for something that would integrate with JIRA, where our developers work on a daily basis, so that time logging could become a seamless process for them. We narrowed the list of contenders down and chose the two most promising to fully evaluate. We needed to evaluate each to check that it could cover all of the functionality we already had; and more importantly, that both operations and the developers would want to work on.
After a few weeks of testing both systems and evaluating them against a requirements checklist, we showed them both to the operations team. Overall, they liked both systems but preferred System A over System B. However, we all knew the real test was to see which one the developers would use...
Two workshops were held simultaneously with two different groups of developers. One group saw System A first, where we ran a quick presentation about how it works and then let them play around logging time. While that group was looking at System A, the other group was doing the same for System B. Halfway through the sessions we swapped each team over, so they were evaluating the other system.
This approach lets each team play with both systems, but in different orders and without speaking to each other. The idea was to eliminate any bias people might have after speaking to their peers in a different group, or bias towards the first or last system they saw.
At the end of the workshops, we asked them all to complete a survey before leaving the room. The survey questions were created to gauge how the systems would help them with the problems we had previously identified:
- How regularly do you think you would log your time using System A and then System B?
- Which pain points are lessened by logging time in System A and then System B?
- Are you likely to spend less time in System A or B than you do currently?
- Which system will help you to be more accurate?
- What advantages do you think each will bring you?
- If you were in charge of choosing a system, which would you choose and why?
The feedback was nearly unanimous. But it wasn’t quite time to make a final decision yet. We also needed to go through a cultural change…
Telling the story: why is time logging so important anyway?
The next stage for us in our time logging journey was to map out all of the pain points we had identified, and group them in an order which told a story of the problem:
Then, it was time to communicate this to the masses. The arena? The next company meeting.
We used the company meeting as our golden opportunity to talk openly about our time logging woes. We presented the view of the problem from different people’s perspectives, and Dan took the time to explain why we actually need to log time, and how it helps us all.
At this point, we had output from our workshops. We had the developers feedback. We even had solid ideas for the way forward. Now, it was time to go to the directors to get their approval for implementation…
Check out next week’s blog to find out how we further managed cultural change and finally untangled our time logging troubles!
