Midwest IT Survival

First, let me create a scene to frame my thoughts:

Write it down

You are finishing up a meeting with someone from marketing, someone from audit, someone from product and finally someone from operations.  Everyone was shaking their heads in agreement to all the tasks discussed for the last thirty minutes.  It seems redundant, but you close the meeting by re-summarizing the next steps:

“Sally, you are going to let the group know if operations doesn’t have the bandwidth to handing this special customer request plus let us know the name of your operations single point of contact for this

Judy, you are going to update the marketing knowledge base to indicate we now can offer this additional product feature.

Jim, you representing audit are fine with this approach but you will get back to the group if your peers feel uncomfortable.

Sam, product is going to create a small project request to kick off the effort to make the web site able to support this new feature plus you are going to let the group know if this is part of the monthly product usage fee or a new per item additional charge.

Ok, once we have all that, IT can get started enhancing the application.  See everyone in X days at the next touch point meeting”

With more heads nodding in agreement, you walk out of the meeting believing everyone knows what they have to do in the next few days to keep this moving.  You arrive X days later to discover the response to “did you complete your assignment?” is met with “Um, I didn’t think I needed to do anything?  I thought you were handling that?  What did I need to do again?”

It seems to me more and more, if key discussions aren’t written down with clear “Jim, you need to do X by Y” and distributed to all, people tend to not be thorough in their follow-thru.

Anyone else seeing this trend increasing/decreasing or am I just going crazy?

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?