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.
Do you want to go in front of your boss with just your gut?
In the first article, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we dove into team capacity metrics to put some data to the hunches around who is working on what for how long.
So, you have your work request attributes and you have the beginnings of a single model of how your team does work with some numbers to show your team’s real work capacity. Now let us tackle some way to use those numbers to put some data against those attributes.
Remember from our first article the sample attributes we compiled and determined the level of control or influence you have over the request flow?
Influence:
- 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.
No Influence:
- 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
- Projects requesting engineering support = business sponsored projects that require some resource assistance from your team
Now is where your capacity metrics come in handy to try and be more predictive around the work you have no real influence over.
Production issue support
Looking back at the numbers you have collected about your production issue support, what can you say? Well, for a given time period, say an average 5 day work week, you should be able to make a data based claim as to the percentage of time your team as a whole spends on this activity. Is it 5% of your team’s total capacity or more like 30%? Taking the time captured per the previous article’s approach, you should be able to determine a percentage of total time claim that is supported by data and not just your gut. The data based rather than gut based doesn’t detract from the value you place on your gut instincts, but rather, should be re-enforcing your notions concerning the impact of this service that your team has to provide. Consider this management exchange:
Gut Only:
Big Boss: “Why can’t we make consistent traction on the FlimFlam Upgrade project? Each monthly status meeting seems to show some progress, but never the progress predicted the previous week?”
You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence.”
Gut Reinforced by Capacity Data:
Big Boss: <same question>
You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence. In fact, over the last N months, in tracking the hours the team devotes to production support issues, the data says the team, on average, is spending 30% of their time focused on production support issues. Thus, those hours are not available to the FlimFlam Upgrade project.”
I think everyone would agree that the second response has more credibility because it backs up the “gut” with data that puts real context around the impact of the higher priority work requests. Further, it suggests that only 70% of the work projected for the FlimFlam Upgrade project can actually be accomplished thus closes the gap in the Big Boss’s question around work not getting done. Said another way, a conservative maximum of 70% of the next month’s predicted work should be expected to be accomplished. So, now you can add a proactive element to your response to the big boss’s question. Consider this addition to the above response:
“I would like to propose, unless you disagree, that I contact the project manager on the FlimFlam Upgrade project and ask him/her to forecast the month forward work projection and then a second forecast showing only 70% of that projected work getting accomplished. That way, we all collectively will have the best projection of how much work will most likely get accomplished given the competing priorities of production support work.”
The data backed gut with proactive forecasting response presents a much more comprehensive answer to the Big Boss’s question than just gut alone. Plus, going forward, at the FlimFlam Upgrade project meetings, the progress (either greater than or less than 70% in this example) can be tied to the impact of higher priority work requests rather than some nebulous unknown reason that could be left to the interpretation of stakeholders. More work than the 70% got accomplished? It must be less production support work. Less work than 70% got accomplished? It is more likely to be a spike in production support and not ineffective resources or your weak management of those resources.
In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.