Midwest IT Survival

I recently enjoyed this article [http://bit.ly/4fcas] on the concept of “Managing Up” or actually titled “10 Ways to Make Your Boss Love You”, by Anne Kadet of SmartMoney.com. As I was reading the proposed ten ways, I was finding myself switch back and forth between IT manager and IT employee and finding consistent examples of each point in my career.

Make Like Mini-Me

For number 9, “Make Like Mini-Me”, Kadet restates an old adage: “They say that if you want to be the boss, you should dress like the boss”. I was reminded of a manager a few employers back that was constantly commenting on people in his department’s dress. Was a particular female wearing slightly revealing clothes for his department? Was a particular male wearing regular jeans and a casual shirt for a one on one meeting with this manager? He was constantly making these comments to my manager, but never to me, about the folks on my team. Thus, my manager would have to relay the information to me and then I would have to strategize on how to get the message across to the employee in a way that the employee would accept as process-able feedback. Thus began my learning of the art of communicating illogical, non-technical information to primarily logic focused IT engineers (another article in the works for this one).

For number 1, “Put in the Hours – When It Counts” definitely rings true. I had an employee once that was constantly coming in early, staying late, and coming in on the weekend. Initially this appeared as dedication. But as time went on, the focus on the hours in the chair wasn’t matching the error rate in work the individual was performing. Thus, very quickly, the extra hours became an additional negative because the energy was focused on appearance rather than results.

Number 2, “Empathize” with your manager is a winner all around. Your manager is trying to solve or at least make meaningful progress towards a better state for any number of problems. If you can offer some insight and follow-up with a possible action plan that your manager can support, you are going above and beyond your expected duties for the person that has the most influence on your day to day professional existence, a la paycheck. As a manager, I hate having to determine a solution in complete isolation. Employees that can professionally challenge my ideas or offer creative solutions for consideration become the employees I frequently engage in tactical and strategic discussions … as well as sell up the chain as being linked to successful endeavors. This blends in an aspect of number 4, “Be a Conduit” as well.

Number 5, “Ask for Help” … I can’t stress enough … sitting at your desk burning time trying to figure something out is exceedingly frustrating to a manager. I find myself thinking “why doesn’t this individual just ask the person next to them for some new ideas instead of just sitting their stuck in the mud”. The perception of asking for help equals a weak employee just doesn’t ring true with me. I find the complete opposite to be the real truth. Someone that asks a question pertaining to moving them forward on a given problem which then in turn allows them to complete a task faster is someone that is worth having on the team and even giving stretch assignments.

Lastly, Number 10 … Probably for the first decade of my career I struggled with understanding why I honestly believed I was consistently delivering quality output per my role, yet I observed others getting more recognition. The others were even viewed as borderline competent by peers. But in the later decade, I have to admit that I agree with number ten with greater fervor. The concept of strategic sucking up baffles my, at heart, engineering view that logic and delivery trump bumbling, illogic, rumor and perception. The notion of likeability over competence gives me a migraine. But as I look back over multiple Midwestern industries, this theme has been consistently reinforced. If you are finding that your own honest assessment of your work quality isn’t getting the recognition that it deserves, maybe you aren’t putting enough energy into “managing up”?

Anyone have strong feelings on these or any of the other points in the article?

Anyone that has had to participate in a meeting to determine why some IT system went down is echoing a collective groan as they read this title.  For both IT managers and engineers alike, it is the least desired activity following a system failure of any kind.  Business and/or product owners outside of IT are waiting, after the dust settles and the system is restored to working condition, to have primarily two questions answered:

1. Why did the system go down in the first place?
2. What is IT going to do to make sure this doesn’t happen again?

Everything is broken!

Since the business folks have had their otherwise perfectly aligned piles of work to do that doesn’t involve IT completely interrupted by IT, they start the root cause analysis process by contacting that person in IT that represents their “relationship” with IT.  That IT person is usually high enough in the management hierarchy that their need for answers to these two seemingly straight forward questions generates an urgency that has all the IT stakeholders rallying together in camps.  As each camp is forming, one underlying theme prevails: no one wants to be the engineer that broke the system and no manager wants to be responsible for that engineer and thus the breakage itself.

Engineering Perspective:

The last thing an IT engineer wants to hear from his boss is that after being up all night fixing the problem, that he or she has to come into the office to participate in a root cause or root cause analysis meeting to talk about what happened.

Bob the Engineer: “But we all know what really happened … Storage Support was supposed to monitoring the temp storage volume and when it starts to fill up, get someone on the DBA team to start dumping transaction history data … but since Storage Support let the volume fill up, of course the DB transactions are going to halt, which backs up everything in the system and then it crashes!”

Sure, that could very well be an accurate root cause to the problem.  Take a deeper dive into the group suggested to be dropping the proverbial ball on this one: Storage Support could be waiting on Storage Engineering to build/provide/implement a monitoring and alerting solution due to some past recognition that there doesn’t exist a reliable way to alert appropriate folks when a storage volume reaches a certain threshold.  And yet, Storage Engineering is actually actively working on a solution as part of a formal IT project already in flight based on some past disaster that kicked of said “ruggedization” project.  Thus, once “projectified”, the ownership of the delivery of an alerting and monitoring solution for the temporary storage volume is arguably not Storage Support, nor Storage Engineering but rather the more nebulous ruggedization project itself.  Thus, if the ruggedization project has been providing frequent and accurate updates to project sponsors and stakeholders as to the status and ultimate delivery dates of the project itself, one could argue that the project sponsors failed to assign appropriate priority to the ruggedization effort itself.  And since the project sponsors are most likely IT managers the situation becomes increasingly complex in that the logic (or illogic if you may) proposes that IT management, the same people that very well could be getting the phone calls from the business people, are actually the root cause of this hypothetical outage.

Whew … now if you are still reading and haven’t passed out yet, congratulations!  As an engineer caught in the middle of this interconnected web of essentially competing priorities of limited resources, you have a couple different ways to participate.  Each participatory approach has its positives and negatives, thus choose the approach you are most comfortable with to achieve the approaches associated outcome.

The next article will outline some participatory approaches and their associated pros and cons.

As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly random sources of work coming at your team.  Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is outlined below to stop the surprises:

Step 1: Identify the attributes of your team

First, sit down and make a list of all of the request attributes of your team.  The request attributes represent all sources of work that can be said to impact your team in some way.

For a typical engineering team, I’ve identified the following example attributes:

Your Team's Work Request Attributes

• Production issue support = ad hoc requests from outside your team for subject matter expertise to assist with resolving system production issues or ad hoc “consulting” such as assisting peers with solving a problem based on your team’s expertise
• Vendor product end-of-life = vendor products that you have purchased and currently use that will ultimately reach a vendor dictated end of life date by which you can no longer get support from the vendor thus you should/have to upgrade
• Vendor product upgrades = instead of the vendor forcing an upgrade due to a product’s end of life, you may need to upgrade a product prior in order to take advantage of new features and functions, etc. you or someone desires
• Service Strategy = the IT service that you provide to the organization needs to keep up with new demands on the features you provide externally as well as the time/energy spent keeping the service functioning internally.  This is greater than just “upgrade to the latest version” but could entail workflow changes, process or procedural changes, etc. that mean some level of work impact to your team.
• Projects requesting engineering support = business sponsored projects that require some resource assistance from your team

Step 2: Build a list of sources of requests to the attributes of your team

Make a list of the sources of work requests

Proceed to go attribute by attribute and identify all of the possible sources of requests to your team.  Breaking down the sources based on similar pattern request frequency.  Using the example above:

Production Support Issues

Breakdown the high level sources of these requests assuming you provide IT services to company employees:

• Company centralized help desk

Or if you provide IT services in the form of a company product to end customers (such as a company web site):

• Company centralized help desk for employee operations group that services the product
• Customer call center that takes trouble calls directly from the end customer users

Vendor product end-of-life

Breakdown all of the vendor products by vendor, then product, then version and corresponding end-of-life date:

• Vendor A
  • Product X, Version 1.0, end-of-life = 12/31/2009
  • Product Y, Version 2.0, end-of-life = 7/1/2010
  • Vendor B
    • Product X, Version 5.5, end-of-life = 12/31/2010
    • Product Y, Version 7.0, end-of-life = 7/1/2010

Vendor product upgrades

Breakdown all of the vendor products by vendor, then product, then version, corresponding upgrade version and upgrade driving force criteria:

• Vendor A
  • Product X, Version 1.0 to 1.5
  • Upgrade in order to reduce the manual effort it takes to administer the system with the automation provided in the new version
  • Vendor B
    • Product Y, Version 7.0 to 7.1
    • Upgrade in order to get the ability to import documents in the XYZ format when the XYZ format becomes the company standard at the end of the year

Service Strategy

Breakdown all of the requests that consume time revolving around the strategic aspects of your team’s services and their associated time/resource demands:

• Yearly budget, Aug. thru Sept. yearly cycle
• Architectural Review Committee Meetings, 4 hours once a month every month
• Quarterly service roadmap presentations to senior management, 2 hours once a quarter plus 2 days each to prepare
• Vendor management, approximately 1 day per month spread throughout the month

Projects requesting engineering support

Breakdown the high level project engagement model that makes resource demands on your team:

• Yearly IT externally sponsored project discretionary IT project cycle
• Internal department sponsored projects
• IT sponsored projects that require changes in your services to support their projects goals

In the next article, I’ll take the attributes and the request sources and identify trends you can use to start building a work model for your team.

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 engineer that has a role to play on an IT project.

In the previous article, the concept of a “pre-task” was introducing a gap in the project plan and introducing gaps into the plan causes panic.  Thus, how can you redirect this panic to work for you?  That is were the ability to introduce a gap or a “pre-task” from the example in the previous article that redirects the panic on to another individual or entity while at the same time, implying the gap should have been already accounted for because everyone knows it is a required tasks works.  Breaking down the previous example:

How does a pre-task help me?

“…I can’t finish until the Architect signs off on my design document” introduces a gap in the plan that doesn’t involve or imply more work on your part.  Rather, it brings in a task that is a barrier for you to complete your task.  Thus, and here is the selfish benefit, this technique allows you to work on your task without someone hovering asking every five minutes … “is it done yet?  How about now, is it done yet?” as project managers tend to do.

“All designs must have Architect sign-off” is the follow-up sentence implying that it is the project manager’s job to know this standard operating procedure or process.  Thus, it isn’t your job and thus you can take no blame for not having this step in the plan from the beginning.

In summary, whether you find yourself with too many chiefs or too many indians, using the tools above should help you succeed in your role on a project.  Now if you have read this far and are thinking to yourself, “geez, this sure sounds like a lot of work above and beyond doing real engineering work.” my response is yes, it is.  And yes, none of it is seemingly appealing to the engineer that just wants to do engineering work.  But, in my experience, I have seen, time and time again, the good natured engineer get himself, his boss and his team in hot water because all the chiefs were pointing the finger of blame squarely on the good natured engineer that became the almighty reason for the project delay.  The finger is pointed regardless of all the prior missteps that get conveniently forgotten in these scenarios or have already been covered up.  To better position yourself not to get caught up in these nontechnical exercises with chiefs, it pays dividends to invest some time understanding what the formal and informal processes are in relation to your project role and get into the practice of always having a pre-task in your back pocket to use when chiefs are starting to dig into the project tasks.

Key points from this series of articles:

• Know your role on the project and ensure your boss is in agreement.
• Always have your boss in 110% support of your performing tasks/functions outside of your traditional role
• Have a working knowledge of the official project and engineer processes leveraged by your company
• Always have a pre-task ready to articulate when ever possible to create that external dependency on any tasks you are performing

When to insert that upgrade dependency

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances to varying degrees of success.  In this article, I’ll outline one which involves linking a sponsored project in flight requiring some technical solution from your team to an upgrade or enhancement your team wants but is struggling to implement on your own.

As mentioned in the prior article, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  If a project is of a high enough priority that it needs to be accomplished and your team has a role to play, consider creating a plausible dependency on meeting the project requirements via the upgrade/enhancement you want to implement.

I’ll take a stab at a typical requirements gather conversation to explain:

Project Manager: “Boss, it is my understanding that your team provides widgets that interface between the FlimFlam system and the billing system?”

Boss: “Yes and my understanding is that this project requires a widget to take the ABC format that comes out of the FlimFlam system and convert it to the XYZ format so it can be fed to the billing system, right?”

Business Analyst: “Yes, that is correct.”

Boss: “Well, I checked with my team and we have two options.  One, is we can directly develop the conversion widget in the current product version we have and that will take 20 days and there will be extensive testing and the possibility for a high number of defects due to the custom coding.  The second is we can upgrade our product to the latest version which contains native support for converting ABC to XYZ.  Thus, the 20 days becomes 1 day to configure the new product.  The new product has been out for six months and used by a number of other customers thus it shouldn’t have any serious defects.  The catch is we have to regression test the five other widgets currently in production.  Our recommendation is the second option.”

And just like that, you’ve articulated a business case that strongly suggests an upgrade you have been wanting to implement but couldn’t get all five interfaces tested and signed off.  This sixth interface project effectively completes both objectives: yours and the projects.

Hopefully you have done your homework and are seriously confident that the upgrade indeed will meet the project needs even if the “native support” is stretching the truth just a bit.  The real key is that you can realistically meet the project needs within the alternative estimated timeframe.  Once the project gains momentum and is marching down your road of upgrading and testing versus custom coding, it is next to impossible to switch the decision as long as you are trending towards meeting if not exceeding the other estimate.  One of the more difficult IT centric challenges is getting another group to test their technology that interacts with your technology when they have no reason to do so except for your need.  This approach uses the priority and urgency of this new project to drive that testing.  “Guys, we wouldn’t need you to test but this other project is forcing us to change thus we need you to validate …”

What happens if they build momentum and go against your recommendation?

The subtle power of “recommending” one particular course is one of risk ownership.  If the project accepts your recommendation, then you own the risk of not meeting the projects needs.  If the project rejects your recommendation for an alternative, then the project now owns the risk of the success and/or failure of your work to a significant degree.  How so?  Well, whenever the project comes back to complain about missed deadlines or quality issues, you have the immediate  response poised: “Well, you remember we recommended option A but you asked us to do B.  Had we done A, I believe we would be meeting your expectations.”  You have various permutations of that response as your get out of jail free card to the immediate complaint.  Clearly, if you enjoy your paycheck, you need to continue to make the project a success.  But, if the project as a whole starts trending negative, you are pretty much in the clear of taking a significant portion of the blame.

What happens if your recommendation turns out to be more complicated/time consuming than you originally thought?

This is where doing your homework comes in.  Before even recommending the upgrade/enhancement dependency option, you need to be extremely confident in your ability to meet expectations.  Going off new features and functions in release notes is a bad idea.  Working from some semi-formal product/solution testing and real engineering evaluation is a much better idea.  If your role in the organization is exceedingly intolerant of the risk failure, then I would venture to say go so far as the only open variable is the need for the formal testing signoff from the external groups.  The closed variables would be up to and including having already technically tested and confirmed the external group owned systems will work in formal testing scenarios (via the systems themselves and/or a stub of their systems touch points with yours).

The ability to link an upgrade or enhancement to an in flight project gives you the ability to help the project succeed as well as accomplish a goal on your list at the same time.  The keys are to be able to plausibly justify the upgrade approach is better than an existing solution coupled with being extremely confident based on actual testing that the upgrade will actually work.

Has anyone used this or a similar approach and had success?

How do I get this IT project started?

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  How many times have you been in a team meeting where the dialog went something like this:

Boss: “Anyone check out the new enhancement to the project management software we use?”

Bob the Engineer: “Yes, according to the release notes, it now includes a bug tracking module that is as good if not better than that silly third party product we use.  Plus, it is now integrated with the enterprise QA reporting service.  If we upgrade then we can turn off that third party bug tracking software and decommission the server.  Plus, all the PMs can stop manually typing in their project details into the QA reporting tool rather, hit a but to automatically populate the QA tool.”

Boss: “Sounds like a no brainer to upgrade … but how are we going to pull this off?  We need some time to install the upgrade, import the existing data, training and cut all the PMs over plus put together a training guide or something for the business testers that currently use the old testing software … plus, probably a bunch of other details I am not thinking of at this moment.”

Bob the Engineer: “Yah, this would totally help people in the company get projects done quicker without all the manual bologna that goes along with tracking stuff.”

Boss: “No one else is really looking at this but us …”

So here you stand on the precipice of a significant efficiency gain to the organization’s overall project delivery.  So why can’t you just jump on executing this obvious, no brainer improvement opportunity?  If you are part of most “MidWestern-ish” IT organizations, you have a great (or not so great, but your have one) engine for handling the prioritization of business driven requests, but lack, somewhat, the ability to inject an IT centric request.  More than likely, your current prioritization engine would drop this upgrade to the bottom of the list which means no one is going to be able to work on it given all the other high priority business requests.

I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances.  In this article, I’ll outline one which involves converting the IT request into a business request devoid of IT buzzwords.

As mentioned above, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  [Warning: extended water flow metaphor ahead]  It is impossible for a finite set of resources (IT) to be handling an infinite stream of requests (the business) without prioritization otherwise the organization as a whole will eventually implode in on itself.  Whether it is the example above or a new low cost storage technology or a new development language of choice major revision, one way to get some attention in the proverbial fire hose of work coming at you is to get that work into the business request pipeline.

To accomplish this, besides digging into how requests can be properly formatted to formally enter the pipeline itself, you have to start converting the IT request into a business request.  For example:

IT Version:

• Upgrade the project management software from v1.0 to v1.5
• Decommission the bug tracking software and server

Business Version:

• Enable the overall savings of $12,000 and 240 hours per quarter per IT project by providing technology and process improvements to the project delivery process, total per year savings = $480k and 960 hours less a one time investment of 200 IT hours to implement
• Supporting Data:
  • Assumption = Overall hourly rate for PM and Testing resources working on IT projects = $50 (average salary + average HR overhead + facilities)
  • Current = Averaging 20 concurrent projects each averaging 3 months in duration require 3 QA reporting updates per week consuming 1 hour per update
  • Future = Automate this process to one click, thus 20 project * (3 months * 4 weeks)  = 240 hours saved and 240 * $n = $12,000 avoided per quarter
  • [If you can compute the guestimation of monthly savings on the hardware, depreciation, software licensing and data center stuff (power, cooling, rack space, etc.) of decommissioning a server, add that to the total money savings]

Now, your first reaction maybe, “geez, those two look radically different, how can they be focused on the same goal?”  The key word in the goal sentence that I chose was “convert” an IT request into a business request.  Sure, you can look at some software release notes and quickly run through a business case in your brain that says “heck, these new features are really going to help us get work done faster”.  But non-IT people don’t immediately draw the same conclusion that you just did.  Depending on different levels of non-IT involved individuals in the project prioritization process, any number of perspectives can be drawn from the IT version:

• Why do we need to upgrade?  What we have seems to work fine
• Update = spending money … I don’t want to have to try and explain why I approved spending more money
• I don’t immediately understand this request thus it can’t be that important, next item that I might be able to comprehend …

But what are the two universal business concepts that everyone inside and outside IT can appreciate?  Doing something that will save time and/or money.

Thus, how do you get some attention and focus on your seemingly IT centric request?  Answer = convert it to a business request that somehow legitimizes benefits the change itself provides back to the business.

Anyone tried such an approach and experienced success (or failure and why)?

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 engineer that has a role to play on an IT project.

In the previous article two concepts were introduced to help you survive.  Now it is time for the most powerful concept, the “pre-task”.  As much as possible at all times, create the perception that you are waiting on something from someone else in the organization.  Make sure in every situation possible that the project manager or development lead or whoever is managing the checklist of project tasks believes someone else needs to complete their task before you can complete your task.

Not having a “pre-task”:

Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”

Bob: “Um, yah, I’m working on it but I told everyone it was going to take me five days and this is day two.”

Sally the Project Manager: “Not according to my plan … it says you build the widget and then we start testing.  You are holding up testing.  I’m going to have to escalate!”  And rushes out of your cube before you can formulate a response.

Having a “pre-task” at the ready:

Sally the Project Manager: “So Bob, according to my plan, you should be working on that widget … are you done yet?”

Bob: “Um, yah, I’m working on it but I can’t finish until the Architect signs off on my design document.  All designs must have Architect sign-off.”

Sally the Project Manager: “Um …” <has no clue what that means but now knows there is a delay building> “I better go find our Architect on this project and get him or her involved”.  And again, rushes out of your cube.

Now, in this example, there are multiple issues generating confusion.  One is task duration.  The likelihood that someone actually recorded your need for five days to actually do work is very low.  I am continually amazed that the less technical a person is the greater the likelihood they will assume a technical task takes an amazingly short amount of time.  Another is the propensity for project managers or people whose primary job it is to track other peoples work are quick to react less than rationally when their plan gets messed up.  They have their plan and they remain rational when, as time goes by, the plan remains unchanged and tasks are sequentially marked complete.  But when the plan itself appears to have a gap, panic and irrationality can ensue.

Ok, why does someone whose sole job is to track a checklist loses their marbles when there is a missing tasks or four additional tasks need to be inserted somewhere?  A quick glimpse into the project manager’s world reveals their greatest value to the organization is in their ability to predict the future with their plan.  Based on the future date their plan indicates, all kinds of business-ish things could be set to kick off.  Thus, something as simple as a plan that says when a system upgrade will be deployed could also be the starting point for a marketing team to formally kick off a set of media ads, plus a customer training/education packet could be already in the mail with dates for when each customer will be forced to use the new upgrade system, plus an accounting group could be poised to show a drop in license costs (i.e., save big money) due to the upgrade, plus, some executive is counting on the license money savings making his departments balance sheet come just under a magical finance number that triggers a quarterly bonus.  Hence, when the upgrade implementation date starts slipping from a failure of the future predictor (aka. project manager) being accurate, all kinds of heat from all kinds of folks downstream from any of the technical work associated with the project can come out of the woodwork and come down hard on the project manager for giving bad data.  Hence, fearing such heat, project managers react in a variety of ways and some of which are not particularly 100% rational.

In the next article, I’ll outline how to use this panic to work for you.

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.

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 engineer that has a role to play on an IT project.  The previous article can be found here.

How to survive with too many chiefs or too many indians

First and foremost, make sure your role is clear on the project.  Make sure at all times you are executing the functions associated with your role.  If you are unsure if your role requires you to perform a certain function, ask around to confirm and if you aren’t getting concrete yes or no answers, confirm with your boss.  It might seem like you are annoying or bothering your boss but believe me, your boss would rather answer a 30 second role clarification question than sit in hours of meetings dancing around why someone on his team did or didn’t do a particular function on a project.

Second, if you have opportunity or are asked to perform a function outside the bounds of your role, consider all the angles before just up and completing the function.  It might seem cool to build the widget that connects the two systems together to allow the transactions to flow, but if that is not your explicit role, you might be putting your boss and your team in jeopardy.  How so?  Well, if you team is a support rather than a development group in the organization, you have just forced your boss to have more ownership in the system than he has been charged to have.  Your boss will be in political hot water when you are pulled back into the project make changes to the widget while other systems your boss is responsible for need coverage and you can’t be in both places at once.  The last thing you want to be doing is creating a headache for your boss when your boss has the most direct influence on your job duties and compensation.

Not all functions outside of your role are filled with danger.  Some are filled with opportunity for praise for helping the project move forward.  In the example above, there may not be a role that is supposed to build this widget.  Maybe the project is plugging all the technology together in order to test the final solution and someone didn’t realize these two systems needed a widget.  You could be the engineer that saves the proverbial day.  When everyone is patting each others backs when the project is successfully implemented and everyone is overly positive, someone could exclaim: “Wow, glad Bob pulled the widget out of his ear at the last moment, we thought we had a big delay on our hands!”  Yes, these moments are few and far between, but they do exist, they are fleeting, so enjoy them for the brief moment they do exist.  The key to pulling this off successfully, starting even before building a working widget, is to make 110% sure your boss is completely onboard with what you are proposing to do outside your role and the risks associated.  Be prepared for your boss to agree that you are completely capable of building the miracle widget, but because of company politics that if you tried to put them together in your mind would make you pass out, he asks you not to build the widget.  Don’t get discouraged if this happens.  There will be many projects and many opportunities to stretch your role and position yourself for exceeding expectations.  Learn from these rejections on how to better sell your boss on your ideas for the future.

In the next part of the series I’ll continue cover how to survive with too many chiefs or too many indians with one of the most powerful tools the “pre-task”.

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.