Midwest IT Survival

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”?

The Art of IT Work Estimation

One topic that I am definitely still learning ways to improve is IT’s ability to successfully provide work estimates to those outside of IT in order for them to make business and/or priority decisions.  It definitely seems to be a balance between providing enough information for the other party to understand what is driving the work and at the same time, not too much information or worse, too much technical information that the other party will get completely confused by.

Some general techniques I’ve found to work across the board:

• Use a presentation style (such as Microsoft’s PowerPoint or OpenOffice’s Presentation)
• Make a recommendation
• Put yourself in their shoes

Presentation Style

It may seem like extra work to re-format what you have to say into a slide deck.  But the subtle power of the slide deck or presentation style is in your ability to lead the other party through your information in the way you desire them to be exposed to it.  As you are talking to the slides and they are viewing the slides, you are very much in control of the information that you are presenting compared to a piece of paper with stats or some full of words business case/recommendation.  Now clearly, if you didn’t do the research to gather all your support facts, no amount of talking and fancy presentation is going to convince the other party to go with a half baked approach.  The process of creating the deck on top of the analysis work already completed is yet another opportunity to think through what you are presenting and ultimately recommending.

Make a recommendation

If you have a well constructed slide deck with all kinds of factual data but don’t make a specific recommendation, you are missing a great opportunity to seal the deal.  You open yourself up to greater discussion outside of your control which might introduce new facts or worse, new supposed facts that can derail your original intention of getting a decision within your data.  If you present the facts and quickly arrive at a recommendation based on those facts, then others have to have done research greater than yours to contradict.  With a recommendation, you simplify the decisions the group has to make, which is to accept of reject the recommendation.  If you present facts and hope people are absorbing those facts to propose a recommendation, you may not be rewarded with what you need, rather, boundless discussion.  Thus, your chance of everyone having a more healthy discussion within your constructed bounds and arriving at a decision is greater with a recommendation.

Put Yourself in Their Shoes

Sure, you need an answer from those accountable for making work prioritization decisions.  Yet, your IT world is significantly different than their business world.  If you need a product manager to decide on exactly what features on the list need to be in the next release, try and figure out why each feature was added to the list in the first place.  Was it a high profile customer request?  If so, it is pretty important.  Was it operations wanting an improvement to speed up their work flow?  Important, but it is not compared to a customer request.  Is this a request that has been on the list for multiple releases but keeps slipping?  If so, it probably can keep slipping since it has already been passed over in the past.  If you need an auditor to sign off, try and put together a story that shows constant progress being made over multiple releases to ultimately close out the issue you can’t close in just one release.  Make sure it release further reduces the risk or exposure with data the auditor can take back to their team with confidence the issue is getting attention, risk is being reduced and the exposure will be eliminated in a fixed timeframe.  Having the ability to put yourself in your target audience’s shoes and thinking through what is it that is going through their mind as they are forced to make a choice of a less desirable result than “We are implementing everything everyone asked for in the next release” will help in getting support for your recommended approach.

I think I will write a series of articles on various techniques I’ve found to have more or less success with a given audience.  The above three high level considerations are probably some of the most universally applicable.

Anyone have any other go to approaches to the “we have more requirements to fulfill than we can possibled handle by X” IT challenge that they found work for a variety of audiences they can share?

What about specific techniques that work for a specific group or a specific situation?