Midwest IT Survival

How do you survive without SMART goals in today's Corporate IT?

There are plenty of great resources on the Internet that offer excellent perspectives on management and leadership that can be readily applied to those working in corporate IT. And one would think with the vast amount of excellent free advice, all managers would excel at their jobs. Alas, today the demands on IT management make readily putting that advice into practice exceedingly challenging. Recently I’ve been contemplating on how to best articulate what I feel is the dichotomous role a corporate IT professional has in today’s workplace.

Dichotomous Role:

1. Deliver on what your manager of the moment expects
2. Deliver on what your role is expected to deliver to the organization

Why “dichotomous”? More often than not, what your manager expects can be incongruent with what the organization expects.

One might think all you have to do is understand your job description, your department/team/personal goals and objectives and go off every day and do your job. And for some they maybe enjoying this straight forward, obvious job function clarity. But for most, I would feel confident in saying that seeking this expectation clarity can consume a significant number of brain cycles everyday with varying degrees of success. Frequently, your manager’s expectations differ with what the organization expects. What forces are at play creating this dichotomy and what can you do to stay sane over time?

Biggest Contributors to Role Dichotomy? Lagging Goals + Manager Shuffling

First, Lagging Goals

I know of no study or statistical evidence to support my claim, but I feel rather confident in saying that the rate of change in IT has increased dramatically in recent compared to prior years. Step back and take a sample of recent IT management articles. How many are asking the CIO role to change? How many are saying you have to have a mobile work force, outsource development or leverage “the cloud” or risk falling behind? With all that rapid change, in my opinion, pragmatically, gone are the days of SMART goals. Recently, Pawel Bordzinski posted an article similarly calling SMART goals into question here. Sure, MBA academics and management blog pundits will tout the benefits of clearly articulated goals leading to reports having increased delivery success and improved job satisfaction.

Let me be clear up front; I am not contradicting the sound fundamentals of solid goal setting. But unfortunately, with corporate fiscal cycles starting/ending and thus “trickle down” goals trailing six months or more from the cycle start, the average corporate IT employee is lucky to get written goals if they get any goals at all. In looking back over my last five years I probably can point to only two situations where I actually was given documented goals for my job role. In both cases, the fiscal year had already been underway for a good five or six months before I got those written goals.

Why the lag in goal delivery when all sound management principles suggest timeliness equals improved organizational success? In a phrase:

The current corporate business climate expects IT change at such a rapid rate that lagging goals can’t easily, if at all, keep up with the organizational change and subsequent overlapping vision changes.

These typical corporate IT scenarios may seem extremely similar to many and they help illustrate my point. Consider how established goals would need to be handled in each case:

1. The company hires a new “chief marketing officer” who has a new chunk of budget to spend on a “mobile strategy”. Suddenly, new IT projects are kicked off to deliver mobile solutions.
2. An IT Director of the “something” department retires and a new Director is hired from outside the organization. Managers reporting to the previous Director either start reporting to new areas of the organization or start leaving the company. The new Director starts hiring replacement mangers from his prior company.

In the first scenario, assuming managers, teams and individuals had goals that reflected pre-CMO priorities, all now have to wind down a bit on what was previously being worked on and wind up on what the new CMO sponsored projects entail. Sticking to pre-CMO priorities are just not an option. The company clearly has a strategic gap hence the CMO was hired in the first place. Thus, ignoring the CMO’s “high priority” projects because they don’t fit nicely into prior communicated priorities and goals is effectively ignoring the business needs of the company.

In typical corporate IT fashion, the priority of these new CMO projects has been communicated from the top of the house down thus the entire IT delivery management structure is trying to figure out how to reshuffle in-flight work in order to accommodate them. The crisis of the moment has shifted from whatever was the previous crisis to the new CMO project delivery crisis. The company wasn’t strategic enough to see the need for a CMO earlier as new media outlets were creating new demand, what is to say the organization is strategic in addressing new IT project priorities? Lastly, with IT departments cut staff and budget-wise due to the recent recession, what management structure is going to stop and revise all previously documented goals? The demand for flexibility, agility and rapid change makes it next to impossible to be able to cleanly re-write goals as priorities shift.

If the goal setting challenge faced a stagnant organizational chart, then there might be some HR efficiencies all could leverage, but on top of priorities changing, org structures rarely stay static for more than a few months. The second part of this article will dive into what compounds the goal problem for corporate IT employees: rapid organization and management reporting structure changes.

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.

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 a IT manager that has a role to play on an IT project.  The first article in the series is here.

First recommendation: delegation of project attendance duties.

First and foremost, you must admit that you can’t be everywhere at all times.  You can’t be in every meeting.  You can’t ask every question and get the answer first hand.  Thus, you have to develop a system for determining if you need to know about a particular project or not.  And if you do, do you need the information first hand or would a staff member be able to gather the information for you.  One easy way to determine if direct attendance is needed is if peer managers are planning to attend.  Although this isn’t always easy to determine, just because the invite list has a laundry list of names of peer managers doesn’t mean they all will indeed be attending directly.  This is where having a sly way to contact the meeting organizer and schmooze yourself a list of who has accepted, denied and not replied is helpful.  If all this recon fails, error on the side of caution and attend.  A brief note, if your company has multiple locations, dialing to a meeting via conference call rather than attending in person can be an efficient way to get the information you are looking for without sacrificing valuable hours of the day.  A word of warning, if all your peer managers are in the room and you are on the phone, you will potentially miss valuable non-verbal and post meeting chatter.  Thus, choose your attendance vehicle carefully.

If the focus of the meeting is not geared towards managers and your peer managers aren’t attending, then seriously consider delegating attendance to a staff member.  If you team is full of heads down engineers who would rather be hands on with technology rather than sitting in a meeting hear about some else talk about what some project is going to do with technology, then try and spread the meeting attendance burden around so no one gets dumped on with meetings.  I’ve found that if you are overtly clear on exactly what you need this staff member to absorb, things usually go well:

Boss: “Bob, I have a conflict and can’t make the FlimFlam Upgrade kickoff meeting.  I need you to attend and gather some info.  Specifically, you should announce yourself as part of our team and explain you are in attendance to understand the scope of the project but are not assigned as a resource.  For any resource assignment, have them give me a call.  What I think the team needs to know from this meeting is if the FlimFlam software is going to need a widget to interface with the accounting service.  Thus, if by the end of the meeting no one has mentioned the need for a widget, please ask directly if the project scope includes the requirement to build a FlimFlam to Accounting widget.  After the meeting, please let me know how the meeting went and if a widget is needed.”

What do I need to know?

Obviously, as you are more in the routine of having staff members attend meetings, the level of formality to the request to your staff can relax.  Just a word of caution, in the process of relaxing, make sure you still put energy into making sure the role the staff member plays and the questions you need answered are made clear.  It is easy to relax in these frequent requests to staff and if you start assuming the staff member knows what you need from them without explicitly confirming with them, you run the risk of have lost a premium opportunity to get info when you need it.

Next recommendation for the next part in the series: strategically determine when you and your team need to not be connected to a particular project.

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.

Attend the project kickoff or not?

Boss: <thinking out loud> “Did they actually get approval to kick off the FlimFlam Upgrade project?  I better have someone on the team plugged in so I can tell if we are going to have to change our procedures in anyway.”

Boss: “Bob, looks like the FlimFlam Upgrade project needs a resource from our team and based on our team’s workload, I am going to give them your name.”

Bob the Engineer:  <forcing a look of enthusiasm> “Thanks boss, I’ll get right on it.”

As an IT manager, I’ve found my role related to projects to vary based on a variety of circumstances.  Some projects, I want to be heavily involved because the project’s scope suggests some potential major changes to my team.  On other projects, I want myself and my team to specifically be completely devoid of any knowledge the project was going on in order to avoid having resources consumed on a project that had a high likelihood of being cancelled down the road.  One thing to note right at the start, a manager, not explicitly sponsoring the project, getting involved on a project impacts the project differently than if a staff member gets involved.   When managers are tactically involved, it usually means something is going wrong and someone probably messed up.  Thus, one of the first decisions to be made is do you, yourself get directly involved or do you assign a role to one of your staff to fulfill on the project to get you the details you need.  The larger the organization and the more enterprise-ish your role then the more information you need to have on all of the projects in flight that could impact you and your team.

That being said, I’ve seen too many new managers, especially ones that are moving from engineering into management, that make the mistake of assuming they personally must know everything about everything that is going on around them.  You have probably run into these types.  They always appear in a constant state of stressfulness.  They are rushing into every meeting a few minutes late and rushing out as soon as the final agenda item is discussed.  They always speak twice as fast as everyone else and they never stick around after the meeting where the real information is shared.  In their quest to know everything that is going on they put themselves on a fast track to mistakes and burnout.  Thus, we arrive at my first recommendation for the next article in the series: delegation of project attendance duties.