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 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.

Related posts:

1. How to Survive Your Role on a Project as a Manager, Part 1
2. How to Survive Your Role on a Project as an Engineer, Part 1