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?

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.

, , , , ,