im_004426.jpg

Becky Burks

Find me on:

Recent Posts

Nightmare on time sheet; how we overhauled the time logging process (part 3)

Author: Becky Burks

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!

David time logging.jpgFarhan time logging.jpg

 

 

 

 

 

 

 

 

 

 

 

 

Caroline time logging.jpgMarta time logging.jpg

 

 

 

 

 

 

 

 

 

 

 

 

Matteo time logging.jpgNelson time logging.jpg

 

 

 

 

 

 

                

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.

Nightmare on time sheet; how we overhauled the time logging process (part 2)

Author: Becky Burks

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 check-list, 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 let 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:

Story of the problem.png

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.

Time logging.png

At this point, we had output from our workshops. We had the devlopers' 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!

Nightmare on time sheet; how we overhauled the time logging process (part 1)

Author: Becky Burks

It had been coming for a long time…

At the end of every month, developers scrambled to complete their timesheets, while the operations team were breathing down their necks, threatening them with sticks to get it done - and done right. The developers were left wondering why operations wanted their time logs so desperately. Surely they already knew what they had been working on? The operations team were scratching their heads as to why the developers didn’t do it; they had been reminded at the end of every month like clockwork, yet every month the same story. It was hugely frustrating for both sides, and was approaching boiling point. As soon as the Customer Experience team had a break between projects, we knew this was a top internal issue that had to be solved.

Explore - the operations perspective

We knew we needed to start by getting to the root cause of the problem. So, we set up workshops with the different stakeholders, including operations and developers. They were set up in a way to not mix audiences, so that people would be free to express themselves without someone from a different side of the argument being present. 

The operations team is the right size for us to run the session ‘interview style’, with carefully prepared questions. From a CX Analyst point of view, it was an eye opener. We were so used to being involved in internal project teams, that we hadn’t considered the operations point of view. As we interviewed the team, we drew out a reflection of the time logging process as they saw it from their perspective.

We learned that time logs expected from developers were actually for the company to be able to calculate its profitability, and have a view of the staff utilisation. The operations team had to do a bunch of reports on these topics at the end of every month for the directors to be able to make informed decisions, and for the company to know where it should focus improvement efforts. As the CX team, this was the first time that we fully understood what the time logs were actually used for, and why they were so important. Moving forward into the developer sessions, we were keen to find out if anyone else was also in the dark about this too.

Explore - the developers perspective

Next, we held a developers workshop. We made sure to invite specifically selected people (not that they were aware at the time!) to ensure we were covering everyone’s points of view; from testers, front and back-end developers, support developers, as well as those who were the best and worst at logging their time. We made clear to them at the beginning of the session that the aim of the workshop was to discover their pain points and motivations for logging time, as well as to gather their ideas on how we can improve the process.

But first, we had to break the ice. To start with something fun, as well as get everyone in the open and honest mind-set we needed for the real topic, we played the draw toast video from Ted Talks. Then, of course, we made them all draw their process for making toast.

While it seemed like a pretty useless exercise from their point of view (if entertaining!) it really achieved what we wanted - to show that everyone has a different point of view. It made the transition to the follow-on topic easy. Naturally, the next process we wanted them to draw was their process for logging time, however they each saw it.

When they were done, they each pinned it on the wall and explained it to the rest of the group.

As they each spoke, it became obvious that there were some common themes for everyone, no matter which member of the team they were. Everyone had a step in their process about confusion or panic. As they spoke, we also wrote down quotes from them and stuck them up with their process to get the full, annotated picture.

     

At the end of the session, our questions were answered. What motivated people to log their time? They were told to. All stick, no carrot. What was their experience of the time logging process? Confusion, frustration, panic and stress. They weren’t always sure which system to log time in, which tasks to log their time on, or even who to ask. They worried about the consequences of accidentally missing a day and having to go back to log it. Worse, because they didn’t understand its purpose, it gave them the unsettling “big brother is watching” feeling.

Around the same time, the CX team attended a fantastic Design Thinking course by Julia Goga-Cooke to further hone our skills. We picked up the useful technique of considering the Design Thinking process as a cycle of Explore, Imagine, Telling the Story and Implement. This was just the process we needed to use for the time logging project. We knew we were still in the exploration stage, and used the opportunity to delve deeper into this phase.

 

Explore - management perspective 

We held an interview with our COO, Dan Shepherd, to get his take on the time logging problem. Overall, Dan of course knew why time logging was important. He also had a good grasp on why it was frustrating for people on both sides. We shared with him some of the feedback we had gathered so far, and he was surprised to hear that the problem seemed to be more culturally ingrained then he thought. He knew that we needed to get better at internal training and communication, but he still wasn’t sure why people didn’t ask which system to log time on.

 

The next steps

As the final step, we created a company-wide survey for everyone to have the opportunity to put forward their ideas and feedback. We also wanted to use it to put some quantitative data behind the problem. In summary we found out that:

  • We were using six different systems for time logging;
  • Most people said they logged time in the official timesheet system closer to the end of the month rather than daily;
  • However most developers consistently logged time in JIRA for each task they completed;
  • Most people thought the most important reason for logging time was billing;
  • The biggest pain point was that people couldn’t remember what they had done, the second biggest that they had to log in multiple systems, and the third that they were not clear which tasks to log time against.

The last question asked everyone for their ideas on how the process could be improved. The most common answer by far was to have one system to log time in. The next was making it simple enough for staff to do it daily.

So how did we tackle the problem? Check out next week’s blog post for the next episode of our time-logging saga…

Follow infoMENTUM on Twitter