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

Step 1: Identify the attributes of your team

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

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

Your Team's Work Request Attributes

Your Team's Work Request Attributes

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

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

 Make a list of the sources of work requests

Make a list of the sources of work requests

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

Production Support Issues

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

  • Company centralized help desk

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

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

Vendor product end-of-life

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

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

Vendor product upgrades

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

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

Service Strategy

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

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

Projects requesting engineering support

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

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

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

, , , , ,