Midwest IT Survival

A Single View of the Work is a powerful management capability

Well, what started back in mid 2009 as a few blog posts to capture a systematic approach to trying to get a handle on the various ways work requests come to a delivery focused team exploded into a 14,000 word, 13 part blog posting series on the topic. I managed three different delivery teams within three different companies within three different industries while this topic was being explored. The diversity of the teams, the size of the overall organizations (6 member team in 2,000 person IT department within 36,000 employees, 21 member team in 40 IT person department within 300 employees and 8 member team in 100 IT person department within 7,000 employees) and the industries (financial services, legal services and manufacturing) all helped to give me confidence to present the model described throughout this series.

Clearly the theme throughout this series is to use data where ever possible to represent all facets of the work your team is doing. In all three companies I received extremely positive feedback for the effectiveness of my approach from my management. Thus, I felt confident to share my approach with others in hopes others would find a way to adopt some of the techniques to enhance their management function.

Below is a brief summary of the key take-aways and techniques presented in each of the parts of this series in case readers missed any parts along the way or are interested in reading more about a particular topic:

Part 1

Starts the series by requesting you make a list of all the high level service delivery attributes of your team. Next, you are asked to list out the various ways work arrives to your team for each attribute that was documented. Additionally, if there was specific technology under the umbrella of services your team provides, document those and include relevant dates of version upgrades and version end-of-life conditions that represents work you know your team has to perform.

Part 2

Part 2 extends the list in part 1 to start to derive a model for how your team operates. You are asked to identify how much influence you have over each work attribute. Those attributes of which you have a high degree of influence means you are in a position to plan out the work. Those of which you have little influence means you are reacting to the work. For the attributes with little to no influence, you are requested to identify sources of predictive data such as historical request metrics and duration data to form trends. Additionally, you are asked to develop relationships with individuals and groups that are sources of work requests to assist in building work request pipelines.

Part 3

Now that a baseline work request attribute and influence system has formed, you are guided through the thought process of determining how much capacity your team has to actually deliver work. The familiar topic of an eight hour day doesn’t really mean each team member can focus eight hours on work requests is discussed to arrive at a data supported, more realistic number of hours per day to dedicate to service request work.

Part 4

Part 4 describes how to apply the numbers your collected in part 3 towards juggling high and low influences over the requested work scheduling. How to communicate this juggling by using data to your management and work requesters is also discussed.

Part 5

This part in the series describes how to take the low level numbers from the previous two parts and determine the true overall capacity your team has for doing work in a given time period. The excellent article on this pragmatic capacity planning by Peter Kretzman (http://peterkretzman.com) is also covered.

Part 6

Part 6 dives deeper into work requests that require some partial dedication of a resource on your team to a work effort and some of the nuances around safely committing to work deliverables knowing you don’t have fully dedicated resources.

Part 7

This part talks about how to integrate unplanned work requests into in flight work at a high level. Engagement models and other similar topics are also discussed.

Part 8

Now that the basics have been covered and a variety of work request patterns have been discussed, this part starts to walk you through how to build a comprehensive team resource plan.

Part 9

With Part 8 setting the framework for your team resource plan, Part 9 suggests how to sequence and represent detailed work requests. Additionally, having your team participate in the process as well as provide critical work estimation data is also covered.

Part 10

Now that the team resource plan has the majority of externally requested work represented, the addition of non-request work is covered. Topics such as “special projects” and “HR-ish” work is covered. What to include, what to not include and to what level of detail is the focus of this part.

Part 11

Now that you have a rather comprehensive team resource plan, this part describes mechanisms to help keep the plan from going stale. Additionally, how the plan improves your external perception as a manager is explored.

Part 12

This part extends your team resource plan to offer “what if” scenarios around the cost of working on a new hot priority request and how to use your team resource plan to assist with prioritization with your management and the requesters.

Part 13

This final part tackles one of the most challenging topics facing a team manager: how to justify a request for additional staff. The team resource plan is a critical tool in either forecasting forward or re-planning the past to use data to justify that staff add.

All in all, I hope you have enjoyed reading this series and found some element of it useful to you. I would appreciate any comments on the series as whole as far as its overall usefulness to you as well as any feedback around alternative approaches to topics I’ve outlined.

Focus on data to justify more staff

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 a few “what if” scenarios around handling competing priorities. This article will offer additional “what if” opportunities your plan enables you to explore surrounding team staffing levels.

“What If” Opportunities – Adding Another Team Member

Another extremely helpful “what if” opportunity is to show, with data, what adding another resource to the team would mean work delivery-wise. Every organization has a less than scientific way to permit team managers to establish business cases to justify adding more staff. Without data, a manager is left with less than optimal hunch based or eloquent prose based means of communicating the need. Now, with your sophisticated team source plan, you can either project forward or go back and re-plan history.

Project Forward – Strong Pipeline

If you have a more mature organization when it comes to planning you may very well have access to data that indicates what work your team will be tapped to do in some capacity in the coming year. This data will help you in presenting data to support your request for additional team members. Don’t fear if your organization doesn’t capture future work very effectively. The next section “Weak Pipeline” will help in that situation.

Create a copy of your resource plan and begin to add the projects and work requests listed for the coming year. Make some gross estimates as to your team’s involvement. Yes, there is indeed an art to these estimates. Involving your team members in this next year forecasting of work exercise will help to give you additional perspective as well as implicitly implicates your team members in the estimates themselves. I don’t suggest you go so far as break out your estimation templates and spend hours upon hours defining and estimating all possible details related to the future work. Rather, assigning big buckets of hours to “small”, “medium”, “large” and “mega-huge” work blobs is quite enough. Remember, your audience is your management team not the business requesters that will grasp feverishly at any dates available to them no matter how hastily concocted on a bar napkin. Thus, general estimates that can be plausibly linked to known work is more effective in achieving management buy in than overly detailed analysis.

Senior Management: “Upgrading FlimFlam next year is twice as much work as the FlimFlam disaster recovery project this year? Twice the planning? Full regression testing? Go live involves keeping the old version operational until all end users are cut over to the new version? Ok, twice as much work makes sense.”

Once you have the list of projects, using your new copy of your resource plan, start plugging in the project details using your current staff count. Next, make another copy of this future projected plan and look for skill set constraints and/or work completion dates that you know senior management isn’t going to be pleased to see. Add in hypothetical new hires with skill sets that significantly increase your ability to show a resource plan that accomplishes more work in less time. You might be surprised to see that the skill set you think you need isn’t as important as another skill set of which you figured you had plenty of capacity.

Re-plan History – Weak Pipeline

If you don’t have a strong work load pipeline outlined for the coming year, don’t give up hope. Take a copy of your resource plan from the previous year and look for where you had resource contention. Pretend you could wave a magic wand and have had additional resources join your team with those contended skill sets. Add in the number of team members you are asking for in the next fiscal/budget cycle year. Show a new plan from the previous year that indicates how much additional work your team would have accomplished given the addition of more staff. Your argument is that if you had these additional people last year, your team would have accomplished all this additional work. If next year looks to be even more work than last year then more staff is critical.

Next Steps – Weak or Strong Pipeline

Having a pipeline of new work for the coming year is a bit more powerful to present compared to re-planning  past year. But re-planning the past year is better than having no pipeline and throwing your hands up in despair and whining you need more staff] (external link to blog.brodzinski.com).

Pulling it Together

Lastly, consider adding some fudge factor for unplanned work that you know always pops up every year. One way to project forward for the unknown is to look back over the previous year and note all of the work that appeared out of no where. If you can articulate how you arrived at a percentage of unplanned versus planned work, you can apply that percentage to your next year plan. Make sure you can confidently explain how you derived that unplanned estimate that is based on a guess based on a whim. If you don’t feel confident you can stand behind your guess at unplanned work, don’t add it explicitly to your plan. Rather, just verbalize the plan you are presenting assumes there is no additional work hitting your team next year than what is already known. This conservatism will help offset any weaknesses in your existing projections. I’ve found that if you go into a meeting with senior management asking for additional staff and you have wild guesses based on wild guesses in your data, the value of the data diminishes to the point that senior management begins to lose confidence in your pitch overall for more staff. Rebuilding that confidence can be insurmountable.

Now, with more confidence based on your new plans, meet with senior management to share your reports:

Manager: “Looking forward to next year, I took the next budget year project pipeline data and based on currently known request scope, projected out work for next year based on my current team and their skill sets. What concerns me is that with all the business projects and their early start dates, the FlimFlam upgrade project looks like it can’t finish any earlier than the end of Q3. With Sally and Bob in demand on those business projects as well as the upgrade project, by adding another team member in early Q1, it allows the new team member to pick up some of those less complex business projects. This frees up Bob and Sally, and as I am showing on this alternative team resource plan, the FlimFlam upgrade project can start as early as late Q1. Thus, realistically the upgrade could be completed by end of Q2 rather than Q3. Additionally, these other business projects would complete months earlier as well since Bob and Sally can’t work on more than two projects at a time before quality is so poor and thrashing stresses commitment dates. That additional team member can significantly smooth out the spike in that skill set need for next year. Plus, we both know Sally and Bob have been in demand the last two years with work having to be scheduled around their commitments …”

With data in hand, this conversation is much more fact based compared to “I need more people because my gut says so.”

If you ultimately don’t get your staff add don’t be completely discouraged and give up on using your resource plan as a forecasting “what if” tool. If you’ve laid out the next year of work to your boss without the granting of additional FTE and people start complaining about your resources not being as available as they desire, you can take comfort that you made your boss aware. Thus, when his or her phone rings with people complaining because you can’t meet their needs, he or she shouldn’t be surprised. By presenting your boss with plausible data that he or she can’t support with more staff implicitly holds your boss accountable and you a bit less for the service availability complaints. Of course, you need to constantly look for ways to squeeze as much efficiency out of your resources and processes as possible. You don’t get a free pass as a manager to goof off just because your boss didn’t immediately provide you a new hire opportunity given your masterpiece of work load projections.

Additional “What Ifs”

There are certainly more “what if” possibilities you can do with your team resource plan. It can be very effective at communicating commitment deliverables and dates to project managers. It can help clearly articulate the schedule impacts related to multiple approaches to completing different goals within a project. “Adhering strictly to the architecture and delivery guidelines, these blobs of work look to start and end according to plan X. Being permitted to deviate from these specific delivery guidelines allows these blobs of work to be starting and ending according to plan Y.” It can help show what the impact is for doing certain tasks before other tasks to help others prioritize requests. There are many benefits to creating and maintaining a team resource plan. The next article will summarize all of the main points captured in this 13 part series of a structured team management strategy entitled “Single View of the Work”.

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.

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?