Drop everything and make project "X" the top priority!
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 unpredictable requests for 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 first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, I described how to keep your plan from going stale as well as the benefits to you as a manager for making resource plan a prominent source of data in all your delivery commitment discussions. This article will offer various “what if” opportunities your plan enables you to explore.
“What If” Opportunities – Drop Everything and Work on X
After all the work up till this point in building and maintaining your plan, here is where you can experience some real power of your team resource plan actually making your life easier. Consider this incredibly typical work scenario:
Senior Manager: The VP of Operations just told me the new FlimFlam upgrade project needs to start immediately and is now the most important project for everyone in the department to be working on.
Manager: No problem. Upgrading FlimFlam requires my team members Bob and Sally to be engaged to make system changes. I’ll let them know the new priority and I’ll communicate to the requesters/sponsors of what they are presently working on that their requests have been bumped in priority.
<Conversation continues>
During this conversation, by getting out your resource plan, you can easily identify what work Bob and Sally are presently engaged. You can share with your senior manager the impact of the priority change he or she is mandating. Before we go too far, there are some subtleties to this specifically structured response that I would like to call out:
1. You aren’t saying “No”.
Clearly, your manager is making a demand not asking a question. Thus, saying “No” isn’t an option just because it causes massive changes to your brilliantly crafted resource plan. There might be situations where telling your manager “No” is the right response, but I believe the majority of situations are best handled without a direct “No” as the immediate answer.
2. While agreeing, you are sharing the “cost” or impact of the shift in priority.
In a polite manner, you are agreeing to the request. But at the same time, you are sharing the “cost” or impact of what current work in flight will be paused and thus delayed as resources are shifted. In a non-threatening and non-confrontational way you are allowing your manager to get an appreciation for what work he or she is implicitly approving can be delayed. This subtle phrasing also allows your manager to consider if the “drop everything and work on X” is truly that important. You have allowed your manager to save face and possibly engage in a more detailed dialog around how to slot this new work in with existing work. In general, allowing your manager, the individual with the most direct impact on your paycheck, to save face and achieve their objectives as often as possible is always a good thing.
“What If” Opportunities – “Cost” of Working on Y
Another “what if” scenario that your resource plan can help you with is assessing the impact of asking resources to work on side or “special projects”. As an example, many times during the year pops up the potential need to know what features a new version of a system provides compared to the current. Another example would be a new technical capability that sounds on the surface to benefit your team but someone needs to dig into it to determine how much real benefit. Yet another involving software development teams is re-factoring existing code because what was put in production works, but really needs to be changed to meet standards/guidelines/ enterprise re-usability, etc. If your team is delivery focused, everyone is probably fully allocated to business work according to your plan thus asking anyone to put some time into a “special project” is going to add stress to that individual’s ability to meet their committed delivery dates.
Your resource plan gives you the ability to consider the impact of, say, adding some number of hours per week to a particular team member’s workload. There might exist enough slack time on a particular assignment within a project or work request to absorb those additional hours. If not, there might be the opportunity to contact the work requester and confirm that extending the delivery date by a few days is acceptable. Alternatively, you can schedule a few days/weeks of contiguous time after a delivery date for a particular resource to be dedicated to the “special project”. This way, you can work the “special project” assignment into that resource’s normal workload and delay uncommitted additional work items until the task is complete. This effectively treats the “special project” just like any other work request or project task forcing other tasks to be schedule around it. This gives you the ability to time box the “special project” with your team member so they can focus on this work without distraction as well as give them a clear end date when they need to have their work completed.
At this point, you have a few “what if” scenarios attributed to your team resource plan. In the next article, I’ll suggest more “what if” opportunities your resource plan possesses particularly around staff leveling.
