As much as you might want to avoid the pitfalls of estimating how long some chunk of work is going to take, it isn’t always possible. How many times has this happened to you as an IT Manager?
Business Person <stopping Bob in the hallway>: “Hey Bob, we would like to add a simple drop down list of choices instead of that text box on the web site … how long will that take?”
Bob the Engineer: “Replace a text box with a drop down? That shouldn’t take more than a few hours.”
Business Person: “Great, thanks for the info Bob!”
About to walk off the estimation cliff
Business Person <calling on the phone later that day>: “Sally, since it only takes a few hours to switch the web site’s text box to a drop down, can that be completed tomorrow? We told the customers that have been asking for that enhancement that it would be ready tomorrow.”
Sally the IT Manager: “Um, err …” <how the heck did this happen?> “what about testing and who is going to populate the drop down with initial values and then add/subtract values as needed? We don’t have a tool for that which you could use. We don’t have a release scheduled for tomorrow and thus our Release Manager is on vacation and …” <… and now I have a big mess to sort out>
Once a non-technical person has some duration for a particular request, it is next to impossible to reset their expectations since the resetting usually involves increasing the duration with non-direct IT functions that don’t link directly to their request. Testing? Release schedules? Administration? Security? All these don’t directly contribute to the immediate need to complete the request but are all critical to the overall quality delivery of the complete scope that the request dictates.
The first challenge to avoid these scenarios is to coach everyone on your team that they must never ever give out any work estimate of any kind unless you have empowered them to do so. Make them comfortable with side stepping the artificial urgency of the request with uttering phrases such as:
- “I am not sure. Can you send me an email with the request so I can track down an answer for you?”
- “I don’t know all the details. Can I get back to you with an answer?”
- “I am not sure but I think I know who does. Can I get back to you with an answer?”
In my opinion, the best is some permutation of the first option which asks the requestor to write down, i.e., do some work on their part, what they want and send it along. I am continually amazed at how many verbal requests with urgency never become written requests when asked to be submitted as such. They couldn’t really be urgent if it takes all of five minutes to craft a quick email with what you just asked for in it and send it along.
In a follow-up second part to this pitfall avoidance I’ll suggest a format to reply to work estimation requests with “CYA” coverage.
Anyone have any other tried and true methods to show responsiveness and concern for a request yet channel the request into some mechanism to respond rationally and with appropriate “CYA”?
Related posts:
Articles RSS 2.0 Feed
Follow Midwest IT Survival on Twitter
Generally speaking the development staff should always refer such requests to their manager for triage and scheduling. It keeps the manager from being surprised, and the developer from making an optimistic guesstimate and suffering the consequent fallout.