Midwest IT Survival

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 being outlined in this series of articles to stop the surprises.

In the previous article, we have identified the work request attributes of your team and built a list of sources of those requests.  In this next article, we will start to combine these two lists into a single model of how your team does work.

Step 3: Separate request attributes you can influence from those that you cannot

Just a note right off the bat … I chose the word “influence” rather than control or direct.  I rarely find one has complete and total control over every aspect of a particular work request attribute.  Thus, the work model needs to be flexible to handle changes even to work requests you yourself are sponsoring.

From our example engineering team in the previous article:

Influence:

• Vendor product upgrade = If you are taking the proactive step of upgrading a vendor product, then you have an increased level of influence over the scheduling details.  The most notable exception is if you are opting to make a vendor product upgrade a dependency on an external project’s requirements as I’ve outlined in the following article on this technique.
• Vendor product end-of-life = although you don’t have influence over when a vendor decides to establish an end-of-life date, you usually have plenty of advanced notice.  Knowing your product has a six, nine, twelve month life, you can proactively plan how to upgrade to the appropriate version.
• Service Strategy = probably the request attribute you have the most influence over.  Also, when the work is piling up, this is probably the attribute that gets the least attention.

No Influence:

• Production issue support = the classic “drop everything, all hands on deck” scenario that pops up when you least expect this type of work request.
• Projects requesting engineering support = If you want to continue to enjoy your paycheck, when an external project requests resource assistance, you probably aren’t typically responding with “we are too busy, come back next year”.  Rather, you need to provide each and every project that is integrating with your team’s services with some form of assistance.  Since project scopes rare stay fixed, the likelihood of having little to no involvement in a particular project will turn 180 degrees and need your services puts this attribute in the no influence category.

Step 4: Identify sources of predictive data per request attribute

Time to start identifying some metrics

Now that you have categorized you request attributes into those that pop up at random compared to those that you have some influence over, it is time to identify sources of data to use as metrics to drive the model.  Why are metrics so important?  Because as an IT Manager you need a library of complex colored charts and graphs to swamp senior management with to justify your role in the organization; more seriously, in order to make credible claims.  Proceed to identify per request attribute sources of metric data:

Production issue support

Most if not all IT shops have some product trouble ticket tracking system of some kind.  Get yourself access to whatever reporting capabilities exist and try and get as much data extracted as your can.  The data should specifically note in some way your team members’ involvement.  Can you extract patterns?  Do you see a spike of involvement at the beginning or end of the month?  Is there a customer billing cycle that has your team helping the billing department five times every second week of the month?  Can you pull any start/end times your team is involved such as the average time spent per ticket is 1.5 hours?  This is the kind of trend data you are looking for to start turning the “we keep getting surprised with all these production tickets” into “we can expect to get hit with tickets here, here and here for approximately X hours per ticket”.

Projects requesting engineering support

Unlike production support tickets, project teams requesting assistance should be less frequent in nature.  The sources of new projects and the technical scope of new projects are a bit more challenging.  I’ve found you need a multi-pronged approach to collecting this data and it is a reoccurring activity rather than say a once a year one shot deal.  First, you need to do some digging into how your organization kicks off projects.  Is there a central PMO or Project Management Office?  Are there lines of business that have their own project management teams?  Are there product managers or customer service owners that have a project management arm that services their products and services?  Is it a combination of all the above?

For a new manager, top priority in my mind is to start building this project kickoff source of information.  It is time to break out your networking skills and track down sources of project tracking data and people who are the typical working sponsors in your organization.  Get plugged into the project leads in the PM office.  Identify product managers that typically sponsor projects that impact your team and take them out to lunch to have them spill their product roadmap or strategy to you.  Determine the budget cycle of each product your team’s technology interacts with and get talking to project leads that regularly manage product enhancement projects since they are usually tapped to offer estimates and expertise during the pre-budget cycle.

Clearly, it is possible to invest a significantly large portion of your time tracking down all these people in these various roles throughout the company … especially if your company is large.  Thus, I recommend throttling your time investment in this activity.  Step back and note if you are getting useful data or just polite conversations.  If the data isn’t flowing, it is time to change direction.  On the flip side, don’t ignore this continual time investment exercise even if investigating the feature set of the upcoming release of one of your vendor software products seems more appealing to your engineering mind.  Your mastery of knowing the technical feature set of your vendor’s products will be overshadowed by the perception you are struggling to manage the work demands on your team by your management.

The next article will dive into team capacity metrics.