Addressing Responsiveness

Few years back I was asked to lead an effort to accelerate the “responsiveness” of our organization. Our organization developed, maintained and implemented software solutions. In a bid to become more efficient and effective at the same time, our General Manager had initiated few projects and increasing “responsiveness” was one of them. The definition and measurement around that were left loose and we were told to figure things out and implement.

To understand the work that had already been done in the industry, I along with my team started researching on the internet. What we found was responsiveness as a measurement was used mainly by call centres and customer support organizations. We could not find anyone in software development industry measuring responsiveness. So we started asking ourselves some questions and answering them as well:

What makes us more responsive?

-          If we can become faster in developing software and implementing them.

How can we do that?

-          If we can produce and implement software faster i.e. if we can increase the productivity of our people

How do we measure that?

-          If we can come out with a process to measure the size of our deliverables and then divide that by number of employee-hours spent to do that, we would have a measurement in place

We thought we had almost nailed the definition, so we started working the details. And that’s where we found ourselves lost. We had so many activities that could not be sized correctly. For example how would one differentiate between two enhancement requests, one of which required 15 hours of analysis and 20 minutes of code fixing and one which did not need much analysis but would require 10 hours of coding and testing. There could be so many permutations and combinations of these things.

The day of our first review with our General Manager was approaching. We thought we would put down what we had agreed so far and what we still needed to work on. What we heard from him was a bit of a surprise - he said “you guys are working on a wrong definition, increasing productivity will make us more affordable but not necessarily more responsive. Go and talk to the customers before you guys get into any more theoretical discussions.”

So we were back to the whiteboard. We went and talked to several customers and their feedback was “you guys take too much time to deliver”. We were confused. On one hand the customers were telling us that we take too much time to deliver and on the other hand our GM was saying it was not productivity increase that would give us the solution. How could that be?

Incidentally, around the same time I had some construction work going in at my home. The contractor was taking way too much time to complete the job. It’s not that his people were incompetent- they did good work when they turned up but there were days when no work would happen because no one turned up for work! As it turned out, the contractor was working on five different projects and he would juggle his people between these projects. One day, I was discussing my ordeal with my colleagues and one of them said “Well, that’s how these contractors are, they are not very responsible” Suddenly that gave me the idea, are we doing the same to our customers? Can we organize our workflow better to become faster?

When we started analysing our workflow we found several interesting things.

-          There were times when a solution was ready but was not getting implemented because some review was pending

-          At times, we were delivering similar solutions to different customers but we did not have a standardized workflow - hence each iteration was taking almost the same amount of time

-          The total elapsed time could be reduced by automating some of the standard procedures

-          There were places where we could deliver part of the solution quickly and work on the not-so-important parts later

So, we had our definition and measurement of the problem. It was not productivity gain but it was reducing the total elapsed time that we took to deliver the solution. We could reduce significant amount of elapsed time by optimizing the time when we were not working on the problem vs. taking less time when we were working on the problem.

It’s true that in the process we gained significant productivity, but we could have never solved the problem if we looked at productivity gain alone.

My learning from this journey was two-fold.

Firstly, it is very important to define the problem correctly before you start running to find a solution. Einstein once said “If I had 20 days to solve a problem, I would spend 19 days to define it”.

Secondly, it is important to look at things from the customer’s point of view. Our entire paradigm started shifting when we started talking to customers. What is even more enriching than listening to the customer is to be in the customers’ shoes. It’s only because I was frustrated with my contractor that I started seeing the problem differently and was able to drive the resolution to the problem.