Business Metrics in our Product & Support department

Noel Ross-Gillespie’s first post in our Business Metrics Series, An Introduction to Business Metrics, provided a brief overview into how we implement Business Metrics into the various departments at White Wall Web. In this post, we discuss the practical implications of measuring the performance of our Product and Support department.

In the past, our support team found it difficult to accurately predict delivery, handle growth effectively and take the subjectivity out of performance. With the notion of change as our goal, we acknowledged the age old mantra – “you can’t manage what you can’t measure”.

Before implementing any sort of metrics, the department was at a loss when asked questions such as: Is it possible to take on more work? Who are the star performers? What is the average turnaround time? This left us in an uncomfortable position of needing to make decisions on gut feel instead of factual representation – ultimately, we were in a situation where it was impossible to foster a culture of true performance.

We selected Redmine as our work-flow software of choice – an open source project developed in Ruby on Rails (which happens to be our core competency), giving us the ability to grow and develop it as our needs evolved. We immediately used it for all work which flowed through the department, thereby tracking all communication and time spent on tasks. While implementing Redmine we noticed the similarities between our processes and what we wanted to measure, and certain aspects of Kanban.

Kanban101.com best describes it as “a lean agile system that can be used to enhance any software development life-cycle including Scrum, XP, Waterfall, PSP/TSP and other methods. Its goal is the efficient delivery of value.”
A perfect illustration of Kanban is depicted in this comic strip – credited to the One day in Kanban land blog post:

Following the process of Kanban, we commenced tracking:

Lead Time: The time it takes for a task from the backlog to be completed (including wait time on the backlog).

Wait Time: How long a task is idle on the backlog before being started.

Cycle Time: Time taken to complete a task once it had been started.

Work Time: The actual time logged on a task.

Additional to the above mentioned Kanban metrics, we track the number of issues closed per person, per day, which provides us with weekly and monthly averages for the department. Not only does this afford greater short-term performance monitoring, but also provides us with quantitative measurements for more objective staff appraisals. Stealthy star performers no longer fear subjectivity!
In hindsight, what we learnt from these metrics seems obvious:

Some resources complete far more tasks which are smaller on average, than others who do fewer tasks which are on a larger scale. A task remains open for an extensive period of time, as it awaits external feedback or approval. We are able to experiment with the amount of time spent at certain stages of a tasks’ life cycle, for instance more time spent pushing for approval means lead time can be minimised, which could however lead to fewer tasks completed.

What we’ve learnt has proven its worth in the changes we make in our processes. The combination of a process to follow, and a flexible work-flow tool in which to implement it, has finally given us the environment in which measurement is possible. To date, and after only a few months of implementing metrics, we have gathered enough data to establish and view highs, lows and averages within our department. We are now able to base our decisions on facts, instead of opinions. And finally, we can enter into the feedback loop and substantiate the fact that we are improving.

Follow our Series on Business Metrics as we introduce to you the key factors to successful measuring.