Midwest IT Survival

Is everyone at the same level of competency?

As I was trolling through my RSS feeds of blogs I try and keep current on and I ran across another thought provoking post by Todd (@backfromred) entitled “The Failure in Gating Process”. I wrote a brief comment to share with Todd and his readers. In the comment I stated that I both agreed and disagreed with Todd’s premise. This blog article expands on that conflict.

Todd’s premise is that having PMO enforced project gates:

• Interrupt project progress momentum
• Allow management and sponsorship stakeholders an excuse to zone till “quality gate #4 next month” before paying attention to the project
• Efficiencies lost to stop, starting and context switching

It is difficult to argue that gating process or projects does have a “cost” associated with the stoppage.

Todd’s solution is better stakeholder engagement.

Again, I can’t disagree with his solution in theory. Where is disagree is in the practical implementation of “better stakeholder engagement” in the real world. First, project teams need strong, competent and knowledgeable participation from these disciplines:

• Project and Executive Sponsorship and Prioritization
• Project and Program Management
• Enterprise and Application Architectural Alignment
• Requirements Gathering, Documenting and Tracking
• Business/Systems Analysis
• Vendor Management (if 3^rd party providers involved in solution delivery)
• Technical Development/Integration Leadership/Delivery
• Testing (from unit through final business acceptance)

Simply having resources “engaged” from these disciplines does equal success if the engaged resources lack competency in their discipline and/or knowledge in their discipline to bring into the project fold.

How practical is it to have strong, competent and knowledgeable resources on every IT project in your portfolio?

I argue it is rare and even if all those resources exist in the same organization, they are assigned to the highest priority and visible project(s) alone. This leaves mid to low priority projects with a less than optimal resource mix.

How do you get timely visibility into when a less than optimal resource mix staffed project team is trending off the optimal trajectory?

You need a project gating system applied to specific projects to strategically pause, evaluate and course correct those specific projects.

I chose the previous statement’s phrasing carefully and specifically to avoid claiming that having a default project gating system as a “silver bullet”1 is the answer. Again, I’m not arguing against Todd’s claim that better stakeholder engagement is needed for successful IT projects. I’m saying the practical application in the real world still requires a project quality gating system due to the inability to have strong, competent and knowledgeable resource.

I have some thoughts on attributes of a more efficient project quality gating system, but I think I’ll need another article to collect and share these thoughts bouncing around in my head.

1. Top notch blog publisher Peter Kretzman on his blog “CTO/CIO Perspectives” has an excellent article on IT “silver bullets” and how to get early indications of projects in jeopardy.

Get consensus or get lollipopped**?

From solving competing priorities that are affecting your resources to when to ratchet up the risk management opportunities on a high profile project that is approaching a critical deadline, as a MidWest IT manager, you are constantly forced to make decisions.  IT Engineers are also constantly making decisions, but the impact has a slightly more narrow focus where as, an IT Manager’s decisions have a much wider, more macro focus.  Plenty of the IT Manager’s job stress is directly related to having to constantly make decisions that have a macro as opposed to micro impact within the organization.  This article touches on some considerations for IT Managers to judge when one is solely empowered to make a decision compared to when it is more appropriate to solicit feedback from peers and senior management prior to making a decision in an effort to reduce that stress.  Or more simply, as the article is titled, an attempt to help you reach out to your peers, staff and management to answer the question of how much decision latitude does an IT Manager have within their organization?

In the previous article, once you got past the mild disclaimer, the article dove into the first consideration of engaging your manager what will most likely be a series of discussions surrounding the autonomous decision making abilities extended to you and how much your manager is willing to support.  In this article, adding the considerations of engaging your peer managers and your direct reports in extending you decision latitude purview.

Consideration #2 = Peers, what decisions can and can’t you make?

Along the similar thought process of strategically asking your boss for decision latitude parameters, leverage you new job or role assignment to engage with peer managers for their feedback.  Consider the example decision latitude conversation starting questions below:

“Hey Bob, I’m new to Company X as the manager of the FlimFlam engineering team.  I heard you are the manager of the enterprise integration team.  At my last place, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a software component.  How does decision making for stuff like that happen here from your perspective?”

“Hey Sally, I think we met before.  You are in the customer service department as the shared services manager, right?  I used to be the support manager in the IT employee services department.  Due to the re-org, I am now the manager of the FlimFlam engineering team in the customer delivery department.  Where I came from, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a server.  How does decision making for stuff like that happen here from your perspective?”

By and large, people enjoy sharing their opinions.  Also, people generally respect and appreciate a well articulated question that appeals to their superior knowledge in their area of expertise.  Thus, another by product is a peer manager you may need to work with heavily in your new role will have a positive initial impression of you.  Additionally, you gain valuable insight into their personality, professional capability and leadership style that could be handy when the future need arises to interact with this individual in a potentially challenging situation.

Can they form a well thought out, intelligent response to your question?  Yes, they maybe worth spending more time with gaining knowledge about your new surroundings.  No, they maybe a low priority time investment going forward.  Do they immediately reveal they have an ego that indicates their cube might not be big enough for both you and their ego to fit comfortably?  Yes, and then file this away for a future encounter where an ego stroking communication style would benefit the next exchange.  Do they appear overwhelmed and oozing stress from every pore in their being?  Yes, then whatever feedback they provide might not be particularly valuable since they could very well be stressed due to ineffective decision making.

The topic of decision latitude is a great excuse to get some valuable interaction and intelligence from your peer managers.  One note, the above question and answer examples are just some thoughts to get your head thinking and not a direct mapping to a finite decision latitude specific determination.  Many other factors could be motivating an individual to respond to your initial queries a certain way such as an out side of work challenging situation.  Thus, the above suggestions are a means to get you thinking about starting dialogs with your peer managers to start to build a decision latitude framework that is ever evolving.

Consideration #3 = Ask your direct reports how decisions were made previously?

In the same thematic vein as interacting with your peer mangers, asking your new direct reports on how decisions were made prior to your arrival is another wealth of decision latitude information with a similar by product: ability to start building trust with team.

A fault of some IT engineers that get promoted into management or sometimes managers in general get a sense that because they are managers, they must make decisions because they are managers.  Be it ego or the power trip that comes with having influence over others, some managers tend to assume they know everything and thus must make all decisions without consulting anyone let alone their direct reports.  Nothing reduces engineering employee engagement and morale more than an engineering team that has a manager that is off making all kinds of crazy decisions without consulting his or her staff.  Time after time I’ve seen these individuals consistently get reorganized from team to team until they eventually get lolipopped** on the organization chart.  Does anyone want to take a guess on who disappears in the next round of staff reductions?

Using this situation to your advantage, a great way to start to establish a rap pour with your new team is to solicit their feedback on how their previous management made critical decisions.  They probably have a laundry list of past examples of good and bad scenarios.  What is the old adage?  Those that don’t learn from the past are doomed to repeat it from the Spanish philosopher George Santayana.  Your new team probably has some great stories where their previous management went off and made a crazy decision to do something and the corporate drama that ensued.  Take this opportunity to allow them to share the details of decisions gone haywire.  Plus, listen to how each contributes to the discussion.  Who is talking the most?  Who has the most passion in their description of past events?  Who zones out during the discussion and has nothing useful to contribute?  The conversation will give you clues to how your new position fits into the organization’s decision making process.  Additionally, you will be able to gather valuable insight into your new team and what makes up and novitiates each individual.

Wrap up

Finding yourself in a new leadership position within a different department within your current company or starting a brand new job, how an IT manager participates in the decision making process can easily map to a how stressful the job turns out to be.  Running around feeling compelled to make quick, off the cuff decisions in an organization that possesses a culture of methodically researched decisions is one way find your job stress going up.  On the contrary, a culture where an engineering team doesn’t use the restroom without consulting with management is going to take a different approach to go from day one decision making to day X where you ultimately desire the decision latitude to exist within your sphere of influence.  Using the newness of your role presents a great opportunity to consult with your manager, peer managers and you new team members to get some decision making parameters.  Additionally, you’ll have the side benefits of starting a valuable dialog with your new manager around how they expect your role to be successful.  You will also have the ability to get a feel for how your role was or is expected to function within your department’s peer management pool.  Finally, by tapping the past experiences around good and bad decisions that impacted your new direct reports, you will gain valuable insight into what worked and what didn’t work in the past.  You will also begin to establish a rap pour with your new as a manager willing to listen and understand rather than command and control out of the gate.  This process of understanding the decisions latitude at your prevue is on going.  You can expect the minute you get a sense of comfort that you have a good grasp of when you can just decide on the spot rather than form a committee to launch a research team, there will be a re-organization or an acquisition or some other corporate event that will throw the balance out of whack.  Keep expecting the variability to be the normal state and try a more scientific rather than trial and error approach to having a good sense of your decision latitude.

** “Lollipopped” slang for a senior position on an organizational chart that doesn’t have any direct reports when peers at the same level have staff and potentially additional management layers below them.

Do I make the call solo or get consensus first?

From solving competing priorities that are affecting your resources to when to ratchet up the risk management opportunities on a high profile project that is approaching a critical deadline, as a MidWest IT manager, you are constantly forced to make decisions.  IT Engineers are also constantly making decisions, but the impact has a slightly more narrow focus where as, an IT Manager’s decisions have a much wider, more macro focus.  Plenty of the IT Manager’s job stress is directly related to having to constantly make decisions that have a macro as opposed to micro impact within the organization.  This article touches on some considerations for IT Managers to judge when one is solely empowered to make a decision compared to when it is more appropriate to solicit feedback from peers and senior management prior to making a decision in an effort to reduce that stress.  Or more simply, as the article is titled, an attempt to help you reach out to your peers, staff and management to answer the question of how much decision latitude does an IT Manager have within their organization?

[Mild disclaimer ahead]

Now I am not referring to straight forward decisions such as how often to schedule team meetings or how long before email responses would be considered tardy.  I’m referring to decisions that have a lasting or strategic impact.  Examples such as is it the right time to switch resellers or approval to kick off an expansive systems upgrade project or whether your team should provide an additional service that the organization is requesting that has new hardware, additional licensing and staff increase associated costs.  These are stress inducing examples.  Making say, a service extension decision autonomously, could land you in hot water when your boss finds out that, to be successful, you need more money and staff than the budget allows, yet the rest of the organization is moving forward assuming you are providing the new service.  Ever sit in an IT managers meeting with a cross department attendee list to sort out ownership of key services that need to come together to meet a new, high profile business need and watch a manager proverbially step right in front of a speeding bus by agreeing to provide a solution that everyone around the table knows they should have consulted their management prior to agreeing?  This sounds like the start of a series of high stress post meeting discussions.

Lastly, this article isn’t meant to be a step by step guide to stress reduction based on an all encompassing decision making strategy.  This article is more of series of considerations and possible approaches that might suggest a more structured approach to decision making rather than pure trial and error.

[End of mild disclaimer]

In my Internet wanderings, I came across this definition of decision latitude and its link to work stress:

“…the ability to make work-related decisions. When employees can make decisions related to the way they work, they are able to devise coping strategies than can mitigate the effects of stress” (Halpern, D.F., 159). *

Applying this perspective that how a MidWest IT Manager approaches the decision making process directly correlates to the amount of job stress experienced, one could simply extrapolate:

• Effective decision making, less stress
• Ineffective decision making, more stress

Note: I don’t think anyone could make the claim that effective decision making can eliminate all stress.  Rather, effective decision making can only reduce stress given some level of stress is involved in all decision making and as a manger; you are constantly put in a position to make decisions.  Ineffective decisions lead to an increase in problems or issues that force one to have to make even more decisions, thus repeating the cycle and in the process, bumping up the stress level each time.  Thus, if you find your job to be exceedingly stressful, have you stepped back and considered how effectively you are making decisions?

Consideration #1 = Boss, what can and can’t I decide?

The very first consideration is, for your role within your organization, what are you empowered to decide and what requires three committee reviews and seventeen signatures on a company form in order to decide?  Every company culture is different.  Plus, the larger the organization, the more cultural elements of the organization trickle down from division to department to group to team such that a role in one department might have a radically different tolerance for autonomous decision making compared to the same role in another department within the same company.  To make things even more challenging, with every reorganization or incremental leadership change at some higher level within the organization starts an eventual shift in the autonomous versus group decision making abilities.

So, how does one sort all this out within your organization?  Well, if anyone has a silver bullet answer for this one, I would appreciate hearing it.  In my experience, this is an ever evolving process of pro-actively seeking feedback coupled with reflection on the results of decisions made.  The most immediate source of proactive feedback is your direct manager.  If you are new to an organization or you find yourself suddenly reporting to a new manager, you may want to consider putting a high priority on this following example exchange within your first, formal one-on-one discussion:

You to your New Manager: “One topic I would like to cover is how you see this role empowered to make decisions within the purview of the team and the services it provides to the organization versus when I need your or others involvement.  As an example, in my prior role/organization/management relationship/etc., given a situation such as <insert example of recent past where you were completely empowered to make a decision without any additional peripheral involvement>, I was able to make decision X without having to involve anyone else and I knew I would have the support of my management.  In another example, < insert example of recent past where you had to involve your manager, peer managers, senior management, etc. prior to getting a decision made> I needed to directly involve my manager, peer managers and senior management in order to achieve a consensus on a decision.  Can you share your expectations on how much decision latitude you foresee my role having that you would support?  Follow up question, if a needed decision doesn’t fall within the parameters you see for this role, how best should I request your involvement in the decision making process?”

A couple nuances on this example exchange:

• Use of examples

If you asked directly what decisions you can and can’t make, you are likely to get an unhelpful response such as “I would expect you to make the decisions you feel necessary to get the job done” and then leaving your new boss with the impression you are somewhat weak since you had to ask such an open ended question.  By sighting examples on both ends of the decision spectrum and the circumstances that lead up to your autonomous or consensus based decision, you provide your new boss with context as to why you are asking the question.  The context created by the examples allows your new manager to consider your question within the realm of his or her leadership style.  Plus, you will gain valuable insight into your new manager’s priorities and approach to their role.  If your new manager suggests they need to be involved in every decision, you will get a clue they my have micromanagement tendencies or need to reach a level of trust before they are willing to allow you to function somewhat autonomously.  If your new manager suggests they don’t need to be involved at all on anything, you maybe getting clues you are reporting to an “arm chair” or “Monday morning” quarterback manager who will need to be drug into decisions that they would otherwise enjoy you make and then criticize later.

• “Decisions you would support” caveat

The value of adding this to the end of your big question is to get what you really need from your new manager.  Similar to clues you get from the context setting of your examples, what you are really looking for is your new manager to support your decisions not just allow you to make them.  Having this phrase at the end of your question emphasizes this critical component of your question.  You may want to consider the use body language and voice inflection to politely draw attention to these last few words so you ensure you have your managers focus on the words lest they are already formulating an answer based on your lead in statement to the question and examples.

• Follow up question on how best to engage your new boss

Equally critical is establishing some parameters around the best way to engage your new boss when they need to participate in making a decision.  Again, you gain value insight into your new boss’s leadership style based on the answer.  Equally important, as opposed to trial and error, you now have parameters by which you can engage your boss in decision making.  Thus, as a situation pops up that requires you to make a decision, if it in any way meets this parameter, your stress level doesn’t have to rise significantly.  Instead of stressing, start capturing the information needed and approach your boss as they outlined.  Fight the immediate reaction of making a decision on the spot.

• Potentially the greatest value = the exchange itself

Just by having this exchange, you begin the process of establishing a level of trust with your new manager.  They should begin to perceive you as one that values the reporting relationship as well as management pressures that exist at both your and your boss’s level.  They should observe that you value their reputation and role within the organization through establishing these operating parameters.  Just like you don’t appreciate having to navigate around a crazy decision made by one of your team members that puts you and your team in a bad place, your new boss does not look forward to having to respond to crazy decisions you make.

Finally, by having this exchange very early in the new reporting structure, you lay the ground work for on going dialog on the subject of management supported decision making until you reach that level of trust where the parameters and boundaries are firmly established.  Sure, you could learn these parameters and boundaries through trial and error, but why endure the stress and proverbial bruises when asking a strategic set of questions that could avoid the entire steaming pile of cow dung associated with making a call you shouldn’t have made on your own plus have the side benefit of building valuable trust.

In the second part to this topic, look for considerations around how to involve peer managers and direct reports in extending you decision latitude purview.

* Halpern, D.F. (2005). How time-flexible work policies can reduce stress, improve health, and save money. Stress and Health (21), 157-168.

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

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.

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 first article in the series can be found here.

Projects where everyone knows their role on and the goals of the project are rare.  More than likely, the project you are about to join is top heavy in one of two ways.  The first is too many chiefs and not enough indians.  Like the proverbial saying implies, plenty of people taking about the work, defining the work, breaking the work into chunks or phases or milestones or whatever is great, but if there is no one around to actually do the work, you as an engineer or as a do-er is likely to get dumped on.  The second is too many indians and not enough chiefs.  Equally dangerous because the lure of a bunch of engineers doing cool engineering stuff without chiefs provide direction, priority and governance, time and costs are ripe of getting out of control.  The next section will cover each in more detail with tips on how to avoid the prospective pitfalls.

Too Many Chiefs

A project full of managers, project managers, business analysts, requirements documenters, technical writers, testers, QA folks, support people, program office people, release coordinators, business liaisons, time keepers, relationship managers … well, you get the picture: people with functions to perform on the project but no one to actually do the engineering work itself.  As an engineer getting assigned to the project, you run the risk of getting all the “real work” dumped on you.  If you can handle all the work, great, if you can’t, there will be fifteen people with charts and graphs and emails and ten other ways to make it obvious that you dropped the ball.  In subsequent sections, I’ll over tips on how to navigate in this type of project.

Too many Indians

A project full of engineers, developers, architects and coders sounds like utopia with a whole bunch of people all doing actual work.  A bunch of people that think it is great when some new, hot off the Internet coding technique can be used to make some function perform some task at wire speed with four lines of code.  All those people cost money and consume time. People, managers, which are responsible for tracking and managing money and time don’t have an infinite amount.  At some point in time, someone, somewhere in the company is going to ask the dreaded question: “Hey, it has been four months, how close are we to implementing that new FlimFlam product?”  This is the holy crap moment for the managers that are responsible for the resources on the project.  If someone is asking that question, it means the project is in a heap of trouble.  Since that someone doesn’t already know how far along the project is, how much it is costing, how on track the project is to cost as much as originally estimated and exactly when it is going to finish, the project has failed and nothing has even been released yet.  Managers will be swooping in to ask the dreaded questions:

“What have we built?”

“How long have we been building?”

“When are we going to be done building?”

“When can this be implemented?”

If you have a bunch of engineers sitting around trying to answer those questions, the answers are not going to be what managers are expecting to hear.  More than likely, all kinds of cool stuff has been half built with no plan to pull it all together and meet the original goal of the project.  Managers are thus put in the tight spot and will react with decisions on what to do next which you are definitely not going to like.

In the next part of the series I’ll cover how to survive with too many chiefs or too many indians.

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.