Midwest IT Survival

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

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

You also know when you are on a bad project:

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

This series of articles will cover different aspects on how to survive as an 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.

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.

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

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

If you already have some knowledge of this project from watercooler discussions or some other means and you see this as a positive assignment, you should take this opportunity to offer some sincere appreciation for the assignment.

Bob: “Boss, I apprecaite the opportunity to work on this project”

Something brief, to the point and low on the proverbial sap works just fine.  Now, if you view this as a negative assignment, I would still strongly encourage you to still offer sincere appreciation for you can’t be working on the cool projects all the time.  Making the best of the assignment will put you in a positive light in your bosses mind and can only increase your chances of being assigned something more postive next time.

If you are 100% clear on your role on this project, you are all set.  If you are unclear, don’t let your boss leave without getting that clarity:

Bob: “Boss, I just want to confirm, I am only fulfilling the project implementation into the test environment role on this project, correct?”

Believe me, your boss probably has ten things on his or her mind at the moment and probably doesn’t realize that you can’t read his or her mind as to what being a resource on the FlimFlam Upgrade project means.  You will cause more problems for your boss and then yourself if you go off and assume you are the test environment implementation person when in fact, you are only supposed to review the design of the system before it is moved into then testing phase.

Making sure you know exactly what role you fill on this particular project is critical.  Everyone on the project will most likely either assume your role is X or want your role to be Y and if you job aboard without knowing exactly what you boss expects, you will most likely fail to meet his or her expectations.

Projects where everyone knows their role and 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 part of the series will cover each in more detail with tips on how to avoid the pitfalls.

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

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

You also know when you are on a bad project:

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

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

Attend the project kickoff or not?

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

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

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

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

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

As much as you might want to avoid the pitfalls of estimating how long some chunk of work is going to take, it isn’t always possible.  How many times has this happened to you as an IT Manager?

Business Person <stopping Bob in the hallway>: “Hey Bob, we would like to add a simple drop down list of choices instead of that text box on the web site … how long will that take?”

Bob the Engineer: “Replace a text box with a drop down?  That shouldn’t take more than a few hours.”

Business Person: “Great, thanks for the info Bob!”

About to walk off the estimation cliff

Business Person <calling on the phone later that day>: “Sally, since it only takes a few hours to switch the web site’s text box to a drop down, can that be completed tomorrow?  We told the customers that have been asking for that enhancement that it would be ready tomorrow.”

Sally the IT Manager: “Um, err …” <how the heck did this happen?> “what about testing and who is going to populate the drop down with initial values and then add/subtract values as needed?  We don’t have a tool for that which you could use.  We don’t have a release scheduled for tomorrow and thus our Release Manager is on vacation and …” <… and now I have a big mess to sort out>

Once a non-technical person has some duration for a particular request, it is next to impossible to reset their expectations since the resetting usually involves increasing the duration with non-direct IT functions that don’t link directly to their request.  Testing?  Release schedules?  Administration?  Security?  All these don’t directly contribute to the immediate need to complete the request but are all critical to the overall quality delivery of the complete scope that the request dictates.

The first challenge to avoid these scenarios is to coach everyone on your team that they must never ever give out any work estimate of any kind unless you have empowered them to do so.  Make them comfortable with side stepping the artificial urgency of the request with uttering phrases such as:

• “I am not sure.  Can you send me an email with the request so I can track down an answer for you?”
• “I don’t know all the details.  Can I get back to you with an answer?”
• “I am not sure but I think I know who does. Can I get back to you with an answer?”

In my opinion, the best is some permutation of the first option which asks the requestor to write down, i.e., do some work on their part, what they want and send it along.  I am continually amazed at how many verbal requests with urgency never become written requests when asked to be submitted as such.  They couldn’t really be urgent if it takes all of five minutes to craft a quick email with what you just asked for in it and send it along.

In a follow-up second part to this pitfall avoidance I’ll suggest a format to reply to work estimation requests with “CYA” coverage.

Anyone have any other tried and true methods to show responsiveness and concern for a request yet channel the request into some mechanism to respond rationally and with appropriate “CYA”?

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

Write it down

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

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

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

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

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

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

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

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

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

The Art of IT Work Estimation

One topic that I am definitely still learning ways to improve is IT’s ability to successfully provide work estimates to those outside of IT in order for them to make business and/or priority decisions.  It definitely seems to be a balance between providing enough information for the other party to understand what is driving the work and at the same time, not too much information or worse, too much technical information that the other party will get completely confused by.

Some general techniques I’ve found to work across the board:

• Use a presentation style (such as Microsoft’s PowerPoint or OpenOffice’s Presentation)
• Make a recommendation
• Put yourself in their shoes

Presentation Style

It may seem like extra work to re-format what you have to say into a slide deck.  But the subtle power of the slide deck or presentation style is in your ability to lead the other party through your information in the way you desire them to be exposed to it.  As you are talking to the slides and they are viewing the slides, you are very much in control of the information that you are presenting compared to a piece of paper with stats or some full of words business case/recommendation.  Now clearly, if you didn’t do the research to gather all your support facts, no amount of talking and fancy presentation is going to convince the other party to go with a half baked approach.  The process of creating the deck on top of the analysis work already completed is yet another opportunity to think through what you are presenting and ultimately recommending.

Make a recommendation

If you have a well constructed slide deck with all kinds of factual data but don’t make a specific recommendation, you are missing a great opportunity to seal the deal.  You open yourself up to greater discussion outside of your control which might introduce new facts or worse, new supposed facts that can derail your original intention of getting a decision within your data.  If you present the facts and quickly arrive at a recommendation based on those facts, then others have to have done research greater than yours to contradict.  With a recommendation, you simplify the decisions the group has to make, which is to accept of reject the recommendation.  If you present facts and hope people are absorbing those facts to propose a recommendation, you may not be rewarded with what you need, rather, boundless discussion.  Thus, your chance of everyone having a more healthy discussion within your constructed bounds and arriving at a decision is greater with a recommendation.

Put Yourself in Their Shoes

Sure, you need an answer from those accountable for making work prioritization decisions.  Yet, your IT world is significantly different than their business world.  If you need a product manager to decide on exactly what features on the list need to be in the next release, try and figure out why each feature was added to the list in the first place.  Was it a high profile customer request?  If so, it is pretty important.  Was it operations wanting an improvement to speed up their work flow?  Important, but it is not compared to a customer request.  Is this a request that has been on the list for multiple releases but keeps slipping?  If so, it probably can keep slipping since it has already been passed over in the past.  If you need an auditor to sign off, try and put together a story that shows constant progress being made over multiple releases to ultimately close out the issue you can’t close in just one release.  Make sure it release further reduces the risk or exposure with data the auditor can take back to their team with confidence the issue is getting attention, risk is being reduced and the exposure will be eliminated in a fixed timeframe.  Having the ability to put yourself in your target audience’s shoes and thinking through what is it that is going through their mind as they are forced to make a choice of a less desirable result than “We are implementing everything everyone asked for in the next release” will help in getting support for your recommended approach.

I think I will write a series of articles on various techniques I’ve found to have more or less success with a given audience.  The above three high level considerations are probably some of the most universally applicable.

Anyone have any other go to approaches to the “we have more requirements to fulfill than we can possibled handle by X” IT challenge that they found work for a variety of audiences they can share?

What about specific techniques that work for a specific group or a specific situation?

I bet everyone in IT has had this scenario happen to them at least once if not multiple times at any give company:

Bob the Engineer: <thinking> “This is a no brainer change.  Works fine for me on my PC.  I’ll just copy that new configuration over to the production servers and close out this work item.”

Change is made … some hours go by … then all heck breaks loose …

Frustrated User #3: “I can’t get that document out to the customer because I am getting this ‘Null Exception’ error message on my screen!”

Screaming User #5: “Why is it that every time I try and print I get this ‘Null Exception’ error?”

Irate User #2: “This is ridiculous!  Every time I try and do this my PC crashes.  Someone needs to fix this once and for all!”

Cooling off or Ready to Explode?

Thus that simple change … that no brainer change turns out to have some unforeseen downstream disaster.   To make matters worse, there is always that person that pops their head into the situation and utters that massively annoying phrase:

“Hey, did you test those changes before you implemented them?”

Of course Captain Obvious, these changes should have been tested before they were released in the wild in hindsight.  Plus, now everything that is broke in the near future will be blamed on this change no matter how technically unrelated:

“Hey, my mouse doesn’t work … is it because of that untested configuration change made the other day?”

Every user problem that is called into the IT helpdesk that can be remotely linked to this problem is assigned to you:

Jim the Helpdesk Tech: “Sure Mr. Smith, we will have someone look into this for you right away.” <I don’t want to investigate this … this kind of sounds like the config change from the other day … yah … I’ll just assign this issue to Bob and let him sort it out.>

Your hope here is that a new problem of some magnitude occurs and over shadows your problem so the helpdesk stops assigning problems to you and starts assigning them to the individual or group linked to the new problem.

While this situation is somewhat frustrating to work through to a successful conclusion at your level, it causes an even bigger problem for your boss.  As fate would have it, someone at your boss’s boss’s level was probably impacted.  Instead of calling the helpdesk like everyone else, people at those upper layers of the organization feel they are important enough to skip all the usual IT process and just call some senior IT manager, their peer, to report the problem.  Now your boss’s boss doesn’t particularly want to figure this out and thus picks up the phone and calls your boss to ask why he or she is getting calls about this problem.  Now, your boss needs a story.  If you have read some of my earlier articles, you know that the minute a problem like this pops up, you need to make a bee line to your boss and get him informed of the situation.  Assuming you did this, you still have left your boss in a proverbial pickle.

Good story for your boss to have (which he or she doesn’t in this scenario):

Boss: “Yes big boss, we developed the changes, we had them tested and the testers signed off they were ready to go, thus we are trying to figure out why they still broke in production with full testing signoff”  <the start of confusion and possibly shared blame>

The bad story you have for your boss:

Boss: “Um, yah, big boss, we developed the changes and believed them to be straight forward enough that we didn’t formally engage the testing team and just deployed them in production.” <stop and listen to the obvious “why didn’t you test” feedback> “Yes, I’ll work with the team on making sure all changes are tested going forward.”

What is the morale of the story at this point?  Always, always, always ensure you have followed the testing process of your organization no matter how confident you are in the changes you are making and your assumption that there will be no impact.  Why put yourself in this situation (unless specifically directed by your boss)?  If you don’t get some testing to back you up, you open yourself up for three negative consequences:

1. Extra work and hassel dealing with fixing what you broke and redirecting all the technically unrealted but still assigned to you Helpdesk problems.
2. Causing problems for your boss means your boss has to take some heat because of your actions [never good].  Your boss has a good memory for these events and who caused them.
3. Being labeled as a “cowboy” which is a negative perception amoungst your peers [annoying to have to deal with] and could very well lead to you being passed over by the your boss for new, cool, high profile assignments because you boss can’t risk someone going all “cowboy” on this critical new work [very difficult to get back into your boss’s good graces].

Anyone care to differ?

Remind you of IT?

The first question that may be coming to your mind as you embark on reading this is why identify MidWest IT engineering and management as a separate categorization from IT engineering and management in general?  Is it because you have to consider roof strength in your data center construction so that you don’t end up with a pile of snow on your server racks?  Is it because there is a constant struggle to find key resources during the summer months or hunting season?  Well, I believe that the use of information technology in a traditional MidWestern company varies enough from a Silicon Valley technology company that existing books and articles on the skills and needs associated with succeeding have gaps.

Don’t get me wrong, there are a number of great sources of insight into how to succeed in functioning as an IT engineer or IT manager in the market.  Michael Lopp’s “Managing Humans: Biting and Humorous Tales of a Software Engineering Manager” book and associated blog, “Rands in Repose” (http://www.randsinrepose.com/) is a great and humorous source for the trials and tribulations associated with working in an IT workplace.  Yet, I believe there is a distinct difference in working for a company that primarily produces technology as its core business function (aka Silicon Valley) compared to a company that primarily uses information technology to support a non-IT based core business function (aka MidWest).  The “MidWest” categorization is being used loosely to identify all companies where IT isn’t their core product or service.  And yes, for all those reading with your brains thinking “but wait, I work for a company in the MidWest that does produce software for mass retail consumption …” I am not implying your organization is somewhat minimized compared to a Silicon Valley/Bay Area firm.  Rather, I am putting forth the notion that “MidWestern” companies, by and large, tend to use IT rather than produce IT thus the demands on an IT professional are slightly askew to say, a dot-com in Mountain View, CA.  From banking to manufacturing to insurance to mining to legal services, MidWestern companies tend to be large consumers rather than producers of information technology.

Thus, as either an IT manager or an IT engineer within a typical MidWestern company that largely consumes information technology from others, the attributes associated with the successes and the challenges these roles demand from individuals vary.  As an example, the likelihood that you, as an IT engineer in a MidWestern company, will be assigned any given technical problem and within minutes of reading the problem description, you will be able to saunter over to the cube of a peer engineer that can instantly explain in exhaustive you-are-about-ready-to-pass-out detail how the entire system works and why the problem is indeed a problem because he/she wrote the system … is exceedingly unlikely.  What is more likely is any given problem involves a convoluted evaluation process akin to this:

Engineering Situation:

Engineering Boss: “Bob, can you take and run with issue number 74864”

Engineer Bob: “Sure boss” <ugh>

Engineer Bob: <thinking> Ok, Sally can’t print ARS checks.  What the heck system is ARS?  I think I’ll ping Joe in the application group, he’ll know, he always seems to be working with Finance.

Engineer Bob: “Joe, do you know what the ARS system is?”

Engineer Joe: “Bob, Joe here, nope, what is the problem?”

Engineer Bob: “Joe, something about not being able to print checks”

Engineer Joe: “Checks …. printing checks … I think I remember a check printing enhancement phase 4 ruggedization project last year.  How about pinging Alan?”

Engineer Bob: “Alan, do you know what the ARS system is?  Maybe part of some check printing project last year?”

Engineer Alan: “Geez Bob, ARS doesn’t sound like …. wait, only system I know that prints check is SuperCheckPro 2000 … you might want to hit up Gary, I think he worked on that. ARS … ARS … no, I was just the QA guy on that project for the requirements gathering phase before the RFI/RFP.  Yah, talk to Gary on the second floor”

Engineer Bob: “Gary, know anything about ARS or SuperCheckPro 2000 and problems printing checks?”

Engineer Gary: “Yes”

Engineer Bob: <thinking> Oh boy, Gary is an architect; this is going to be a challenge “Gary, do you know what could cause SuperCheckPro 2000 to stop printing?”

Engineer Gary: “Lots of things”

Engineer Bob: <ugh> “If I were to need to investigate a check printing problem, what should I look into?”

Engineer Gary: “Send me the spool dump log”

Engineer Bob: “Where would I find that?”

Engineer Gary: “Under /var/logs/cp_spool on corp_unix15”

Mary from IT Compliance walks by: “I heard you are looking into that check problem … you are going to have to run this by the SOX people, right? ya know!” Mary vanishes as quickly as she appeared.

Engineer Bob: “Thanks”  <thinking> I bet I don’t even have a login to corp_unix15 … I think I am going to have to submit an ABC4567 form for that … I need to run this by the SOX people as well … oh joy.

Engineer Gary: “Send the problem over to Infrastructure … the box can’t find the printer on the network … they are going to have to open a service request with the vendor ‘cause we don’t support that printer which requires the ARS people to do that since they manage that relationship”

Engineer Bob: <thinking> Oh joy

And most problems take way more Joe’s and Gary’s to interface with in order to have any hope of getting some sort of progress on the problem.  Plus, actually seeing the problem through to resolution, which is a whole other story!

Management Situation:

Engineering Manager: “Why did I get this automated email saying our project number 789 failed the QA8 gate?”

Project Manager: “I didn’t get that email.  Can you forward it to me?”

Engineering Manager: “Yes, here it comes … I just got out of a client milestone update meeting and it would have been nice to know this an hour ago … I just told the client we are on track for 789!  Our VP already stuck his neck out and said this project was going in and would clear the client off the corporate audit report!”

Project Manager: “Got the email … let me get into the Project Center of Excellence portal site … seems we failed an architecture review committee sign off”

Engineering Manager: “What?  We are only adding ten fields to the data table because the enterprise data architects said we had to comply with the new enterprise service bus web service update that is going to push us those ten new fields that audit and compliance claims needed to be there!  What is architecturally wrong was adding ten fields their own group told us we needed to add!”

Project Manager: “I’ll check with the requirements architect to see why we didn’t get this signoff during the design review meeting last week”

Engineering Manager: <ring> “Oh great, my phone is ringing from the change management office … they are going to give me the song and dance that I am going to miss the noon cut off window for change approval.  That is going to bring the escalation heat from the change folks.  That call is going to voice mail for now.”

Project Manager: “Seems 789 didn’t qualify for a requirements architect because it didn’t score high enough on the quality gate 2 project scorecard.”

Engineering Manager: <ring> “Oh geez, word is getting out, the product manager is calling me, she is going to remind me that marketing communications have already been sent to customers based on our go/no go meeting last week since 789 is tied to her campaign due to the release cycle.  Voicemail again to buy some time …”

Project Manager: “I know Bob on the architecture review committee, I am going to try and give him a call and see what is going on.”

Engineering Manager: <ring> “It is getting better, next call here is from that guy in compliance that is going to threaten to tell the client they are going to be on the audit list as a level red due to not having those ten fields in that table by the end of the month.  This one is totally going to voice mail.  Wait!  This is going to get a whole bunch worse … our VP is walking to my cube … he never does … I think he was having lunch with the VP of product … word spreads too quickly … stay in my cube, we are going to have to explain the situation fast when he gets here.”

This could be an IT manager’s typical day with any semblance of a planned agenda of tasks to be completed for the day now completely out the window having to sort out this project mess.

In an IT environment similar in nature to the stories outlined above, a variety of non-technical skills are required to be matched with some level of technical competence in order to survive.

This collection of articles looks at these various skills from both engineering and management points of few and with a liberal dose of humor, tries to share wisdom to navigate while retaining as much sanity as possible!