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…
