My team performs software maintenance on a legacy product. Basically we respond to software trouble tickets. These tickets are tracked closely by the customer. Our company's help desk team has been recently hounding us for "estimated resolution dates" for each ticket. So development has been figuring out, given what we know about the problems, what is the most likely date when we can produce a fix.
Something did not seem right about the Help Desk stating they were being hounded by the customer for estimated resolution dates. So I decided to participate in the next meeting with the customer. It was here that I found out what the customer was looking for. They wanted to know what was the date that we could expect a user to be able to experience the fix and verify that the trouble ticket had been resolved.
That about blew my mind. There is often a huge gap between the time we release a fix to our customer, and when the user actually experiences the fix. Our customer has a lengthy configuration management process. Our fixes go through their quality control first. Then somebody has to actually implement the fix. This can take time, especially when pushing workstation fixes out to the multitude of our users. There are also some processes which run once a week. Depending on the timing, users may not see the process run for up to a week.
I was glad when our project manager also expressed concern about the definition of estimated resolution date. We had to amend the way we accounted for the days that make up this metric. It seems we had been shooting ourselves in the foot by using the wrong definition of this date. You need the right process in place. And that process needs to be continually monitored to ensure it is still relevant and correct. Otherwise you are potentially marching down the path to doom.
