Midwest IT Survival

What do I work on now?

Have you ever stepped back and observed a [maybe yours?] MidWestern IT technical team and wondered why all the engineers seem legitimately busy, yet there doesn’t appear to be a proportional amount of production (or test, or QA) project changes and/or deployments?  Phones are ringing, emails are being sent, multiple instant message chat session windows are open, requirements and design documents are being revised and shared but environment changes aren’t being implemented.  Sure, your organization maybe large enough that duration from project kick-off till the first production deployment could be over a year and a half or more.  In a past life, I was responsible for a web customer product wide single sign-on system that once we completed a system upgrade of some sort, we had to immediately kick off a project to begin the next upgrade because the software and OS refresh cycles were averaging 1.5 years from start to finish.  Yet, have you ever considered that your resources might be getting thrashed with too many concurrent requests from too many sources without any easy mechanism to determine what to work on first, next and what can be put on hold?

I consider team member resource thrashing to be equivalent to an application server that is being overwhelmed with requests from many clients (such as web servers in a web tier).  If you have ever observed high volume systems, such as heavily used Internet web applications, there is a threshold of total requests at which the system can no longer service all the requests and disasters occur.  As the client request count rapidly approaches this threshold, the application servers continue to spin up more threads to assign to each request.  The closer to this threshold, the more CPU cycles are expended in starting, pausing and managing the threads themselves and not the work the threads need to do to actually complete the original work request itself.  The thread count climbs, the CPU cycles to manage that thread count climb and the whole system eventually falls over and the tough job of recovery under extreme load begins.

This thread thrashing is analogous to team resource thrashing.  There clearly is work for the team to be doing, but so many disparate requests are coming into the resources on the team that every team member is barely able to get someone off the phone with one request before an email arrives with additional requests.

Now, I can’t take full credit for this succinctly brilliant assessment of a common large corporate IT occurrence.  In a past professional life, my wise senior manager was astute enough to identify this depiction during a production issue.  The enterprise service my team was troubleshooting was causing performance issues across a number of highly visible customer web applications.  Many teams were demanding status, asking random technical questions and posing endless theories of the few resources on my team as to why the systems were behaving as they were.  We could barely get any real technical analysis completed as we had to appease this growing horde of interested bystanders otherwise risk being cast negatively as “non-partnering”.  The resource thrashing assessment as a barrier to what they ultimately wanted: answers caused the external groups to take some pause.  This allowed us to dig in, really figure out what is wrong and fix it.

I’ve written a series of articles on making it a priority to establish a single view of the work for you team in order to be able to do effective resource planning.  But in the process of determining the single view, also count up how many different work request sources exist.  You may be surprised to find in excess of eight, nine, ten or more ways work can be requested of a single resource.

So what is the big deal?  If someone is getting ten different sources of requests for work, how does that someone figure out what to work on and what can wait?  Most likely, the “squeaky wheel gets the most grease” adage takes over.  Additionally, many project failure assessments find that excessive multitasking can cause key deliverables to missed or delivered below quality.  (Third most frequent cause of IT project failure in a survey by Steve McConnell with construx.com)

What can you do to improve this situation?

Draw a picture

One of the first things you may want to seriously consider doing is to sit down with the individuals on your team and draw up a picture of all the work request sources.  Peer management maybe generally aware that this resource thrashing is going on, but present them with a picture of just how many sources and it makes a bigger impact.  By making the problem more visual, it sets the tone for why external groups requesting work aren’t getting the expedient service they are expecting.

Identify prioritization mechanisms

Another thing you can do is identify the most critical groups and start a dialog to establish a means of prioritizing work requests.  Is it the project management office that is feeling the most pain from not having a predictable resource model nor consistently met delivery timelines?  Get your single view of the work in front of them and the companion back log of requests and get them to help prioritize.  Setup a re-occurring meeting to bring revised views of the work requests for consistent re-prioritization and the winds of “this is hotter than any other project” blow regularly.  Is it direct product managers or business stakeholders that have to work directly with IT that are frustrated?  Do the same thing as with a project management office, just be prepared to have to cautiously identify other business groups that are claiming higher priority and be prepared for some grandstanding or other self importance postulating as the business groups with the most impact on the bottom eventually rise to the top of your list.

I would like to re-stress, it may seem like a lot of data gathering and schedule building, but I’ve never seen this type of team resource thrashing challenge get solved by any magic external group or process.  As an IT manager, you may have to roll up your sleeves and did into the scheduling data.  Finally, this isn’t a “fire and forget” exercise.  Be prepared for having to repeat this data true-up on a regular basis to continue to establish a more clear prioritized path forward.

Anyone have any other tips on how to get in front of a team of thrashed resources?

No related posts.