Midwest IT Survival

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an IT manager that has a role to play on an IT project.

In the previous article, I recommended two situations in which you need to strategically determine when you and your team need to not be connected to a particular project.  In certain situations, being connected to a particular project will actually cause you and your team more harm than good.  Below I’ll outline a third situation where the more distance you can create between yourself and your team from this type of project the better.

Situation Three: production support-ish project involving the terms “ruggedization” or “hardening”

These projects usually form after a major system outage where the outage was severe with critical systems being down for a long enough period of time that higher levels in the organization were distracted from their usual duties.  These distractions involve participating in discussions as to what they might have to sign off on as far as alternative service delivery options if the outage were to extend further.  Since higher levels in the organization were forced to get involved, they want to see what is going to transpire in the near future to ensure this involvement isn’t required again.

The scopes of these projects sometimes are legitimate identifications of technical gaps in a system that indeed need shoring up.  But in my experience, they are more born from a bunch of managers needing to craft a story of how strategic investments were not made in the care and feeding of a given technology service and this “ruggedization” project will ensure this type of an outage never occurs again.  The crafting usually is done in haste to combat the high levels of the organization asking the obvious questions: “why did this happen?” and “what are we doing to make sure it doesn’t happen again?”  Thus, the crafting is more political than strategic at this point and once the crisis dies down and a new crisis is brewing, the whole effort becomes quickly forgotten.  What usually contributes to the proverbial death of the project is when someone compiles the costs associated with ruggedizing against the lack of a budget pre-forecasted to do such work compared to all the work in the budget that still needs to get done by essentially the same people.  Unless the ruggedization is so unbelievably critical IE., jobs are literally on the line, someone in the organization won’t be willing to sacrifice their budget of work that could get them a raise and/or promotion (part of their goals and objectives) for some investment in some weak technology that probably won’t break again within the current organization structure and before the next reorg.

This analysis may come across as a very negative slant.  I would argue that if you can dig into peoples’ struggles with balancing the new work against the unplanned “ruggedization” work, you’ll see a trend of the “A+B” players working on the new work and the “C” players getting assigned the “ruggedization” work which supports my slant.

In these situations, knowing that the project was formulated under these conditions is potentially the most critical piece of data to establish and retain.  Getting ones hopes up that this project is going to actually complete and deliver the outlined system improvements is prone to disappointment at best.  But having the knowledge that this projected existed at some point in the past can come in very handy in these kinds of situations:

Get ready for a fight

Support Manager: <somewhat irritated and on the verge of becoming irate>  “Why is the FlimFlam replication widget crashing again?!  I thought engineering was fixing that so it would never happen again?!”

Engineering Boss: <remaining calm, impersonal and answering the questions with more questions> “Wasn’t the FlimFlam Ruggedization project supposed to take care of that problem last year?  Did that project ever get completed?”

Support Manager: <Somewhat stuck> “Um, I don’t think so.”

Engineering Boss: <still calm> “I seem to remember it stalling when the cost of the redundant hardware was calculated in order to make the widget highly available.  Who needs to be engaged to kick that project back off again?”

An approach similar to the above removes the building emotion.  It also points the imposing finger of blame back to the nebulous ruggedization project that never completed rather than someone in the room.  Plus, alluding to why the project stalled in the first place implies the same exercise (in this example, high cost) will need to be re-evaluated with more than likely the same output: project stall.  Don’t be alarmed if the same cost collection process kicks off because it shows management is doing something in reaction to the severity of the outage … just know it will probably end in the same state as prior … thus you can relax and not be overly concerned as history repeats itself.

In summary, these articles provide some food for thought when it comes to how you, as an IT manager, want to structure you and your team’s involvement in IT projects of a given theme.

How to Survive Your Role on a Project as a Manager, Part 3

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a project.  Now if you have spent any time in IT you have probably had a role on one of these things called a project.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that everyone is accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as a IT manager that has a role to play on an IT project.

In the previous article, I recommended two situation in which you need to strategically determine when you and your team need to not be connected to a particular project.  In certain situations, being connected to a particular project will actually cause you and your team more harm than good.  Below I’ll outline a third situation where the more distance you can create between yourself and your team from this king of  project the better.

Situation Three: production support-ish project involving the terms “ruggedization” or “re-write”

These projects usually form after a major system outage where the outage was severe in that critical systems were down for a long enough period of time that higher levels in the organization were distracted from their usual duties in order to participate in some discussions as to what they might have to sign off on as far as alternative service delivery options if the outage were to extend further.  Some are legitimate identifications of technical gaps in a system that indeed need shoring up.  But in my experience, they are more born from a bunch of managers needing to craft a story of how strategic investments were not made in the care and feeding of a given technology service and this “ruggedization” project will ensure this type of an outage never occurs again.  The crafting usually is done in haste to combat the high levels of the organization asking the obvious questions: “why did this happen?” and “what are we doing to make sure it doesn’t happen again?”  Thus, the crafting is more political that strategic and once the crisis dies down and a new crisis is brewing, the whole effort becomes quickly forgotten.  What usually contributes to the proverbial death of the project is when someone compiles the costs associated with ruggedizing against the lack of a budget pre-forcasted to do such work against all the work in the budget that still needs to get done.  Unless the ruggedization is so unbelievably critical IE., jobs are literally on the line, someone in the organization won’t be willing to sacrifice their budget of work that could get them a raise and/or promotion for some investment in some weak technology that probably won’t break again within the current organization structure and the next reorg.

In these situations, knowing that the project was formulated is potentially the most critical piece of data to retain.  Getting ones hopes up that this project is going to actually complete and deliver the outlined system improvements is prone to disappointment at best.  But having the knowledge that this projected existed at some point in the past can come in very handy in these kinds of situations:

Support Manager: <somewhat irritated and on the verge of becoming irate>  “Why is the FlimFlam replication widget crashing again?!  I thought engineering was fixing that so it would never happen again?!”

Boss: <remaining calm, impersonal and answering the questions with more questions> “Wasn’t the FlimFlam Ruggedization project supposed to take care of that problem last year?  Did that project ever get completed?”

Support Manager: <Somewhat stuck> “Um, I don’t think so.”

Boss: <still calm> “I seem to remember it stalling when the cost of the redudant hardware was calculated to make the widget highly available.  Who needs to be engaged to kick that project back off again?”

An approach similar to the above removes the building emotion.  It also points the imposing finger of blame back to the nebulous ruggedization project that never completed.  Plus, alluding to why the project stalled in the first place implies the same exercise (in this example, high cost) will need to be re-evaluated with more than likely the same output: project stall.

In summary, these articles provide some food for thought when it comes to how you, as an IT manager, want to structure you and your team’s involvement in IT projects of a given theme.

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?