Midwest IT Survival

Build out that Gantt chart

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, we put together an initial Gantt chart that lists all the work requests and projects by work phase and indicated which team member is work on which phase. Additionally, your team review of the chart increased its accuracy and improved your team’s level of engagement. This article will build on that initial chart and incorporate work estimation sheets as well as additional work considerations.

Merge Gantt with Work Estimations

Now that you have a list of all work requests and projects with resources assigned by phases plus a quick team review, now is a good time to take all those work estimation sheets and pull the data and plug the data into the Gantt chart. But first, we need to make a few decisions around how to account for time in the day.

If you are using a Gantt charting tool that has an option for defining the work hours in a day, you will need to determine the total number of hours that reflect a true workday for your work requests and projects. As I’ve covered before in part three, realistically, an engineer doesn’t have a full eight hours in a day to dedicate exclusively to project and work requests. With team meetings, HR activities like performance reviews, 1:1’s, training, holidays, time off, etc., your real working hours in a given day maybe more like five of six rather than eight.

If you re using my work estimation template I referred to in part seven of this series, then that template has the ability to incorporate a calculation to handle the real working hours in an average workday. More specifically, the total hour calculations are raw hours where as the “duration” or “contiguous work days” calculations are where the real working hours calculations come into effect. Make sure you are clear on how you are entering your hours for estimating phase durations to make sure you aren’t over or under calculating the length of the durations.

Linking or Sequencing Work Phases

After taking a brief pause and stretching from the cramping associated with all of the data entry you have just completed, now it is time to link or sequence the work phases. Depending on the Gantt chart tool you are using, there should be a way to link the work phases you entered to reflect the workflow over time. Using our example from the previous article, the sequence should reflect that work requests get completed in the following sequence:

Planning -> Design -> Development -> Testing -> Deployment -> Post-Deployment

Below is an example from Microsoft Project that shows this example from above:

Your Gantt chart tool should have some way to indicate that although both tasks can start after the “Design” phase is complete, (hypothetically for example purposes), the Biz development can’t start until a certain milestone is reached in the UI development. Similarly, “Testing” can’t start until both Biz and UI development is completed. In this more complex example, UI is estimated to take a few days more than Biz even though UI started before Biz:

Pause and Admire Your Work

Before you start analyzing the results, first, step back and look at your first draft team resource plan in Gantt chart form. I think you will agree that you now have a single, professional and authoritative report of what your team is currently engaged on work request and project-wise.

Back to Work, Sanity Checking the Chart

Enough basking in your resource management reporting superiority; now it is time to sanity check your chart. Beyond merely double checking that all your “Testing” phases currently appear after any and all “Development” phases, look for these specific abnormalities and take some action on them to improve the quality and accuracy of your chart:

1. Do any of the same resources appear to be working on phases at the same time as phases in another work request or project?

If the answer is “yes” then don’t panic; this might not be wrong. It may reflect a resource winding down on one request and getting started on the next. But, if you have allocated a full “day” on request A and another full “day” on request B with one starting/stopping, you need to be sure that that indeed is the message you want to externally communicate. Please recall that the real goal of this Gantt chart is to “report” to external parties what you want them to see and understand about your team’s work. Thus, if you have been requested to work on two requests concurrently and the skill set needed to complete these two requests is contained within only one team member, then the overlap your report is showing is accurate. It maybe accurate but it might not be realistically achievable. There will be more on how to use this report to assist with rectifying this situation later.

1. Do any resources appear to have large gaps of unassigned work requests?

If the answer is “yes” make sure you have entered all the estimation data correctly and verified your start and end dates. This may not be an error. Rather, this may indicate that a particular resource doesn’t have any formal project of request work to handle during that gap.

Sanity Checking the Chart with your Team

Similar to the previous article, this is another great opportunity to get feedback from your team. As I mentioned prior, in addition to increasing the quality of your chart, you will enjoy the side benefits of over all increased team engagement. If your team is highly technical, asking for feedback might not immediately resonate with them on how this helps them. If you simply ask:

Manager: Does this look right?

Highly Technically Focused Team Member: Yah, sure.

You may need to pull information out of them through more probing questions or consider challenging them on specific data in the report that looks a bit suspicious. Consider:

Manager: Does this look right?

Same Team Member: Yah, sure.

Manager: Ok, it looks like you are working on request 7648 and 7653 at the same time and from your estimates, it looks like both will be done next Friday.

Same Team Member: I can’t do them both at the same time.

Manager: Ok, which one makes sense to work on before the other?

Same Team Member: Oh, I have to do 7653 first since I’ll tweak the solution from 7653 to complete 7648.

Manager: So you need to work on 7653 first, exclusively, and then you can begin work on 7648?

Same Team Member: Yes.

Manager: Great, I‘ll adjust the chart to show that.

Based on the above exchange, adjusting the chart to show request 7653 starting and then ending before 7648 will now more accurately communicate what this team member is working on when and at what date specific work items are estimated to be completed. Additionally, you can note the technical dependency the one request has on the other in order to communicate that externally to interested parties. Lastly, the team member now leaves that conversation with a sense that the boss cares to an increased degree what he or she is working on. Hence another additional up tick in engagement from that team member.

At this point, you should have a rather accurate, through team review, Gantt chart reflecting all the major external work items your team is engaged on. In the next article, I’ll suggest ways to include internal work items like vacations and special assignments that involve your team’s time with considerations on how to reflect that work in amongst the external work in flight to give a even more complete view of your team’s work.

Drag your team into resource planning

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, we put together a way to capture work estimation data in a standard format from your team including the benefits to such an approach from a team management perspective. This article will describe how to use the work estimation template for more effective resource planning. I will describe a sequential approach to use the work estimation template data and build a comprehensive team resource plan.

Single Team Resource Plan – Building a Plan

In order to build a resource plan we will steal a data presentation format from Project Management called the Gantt chart. A Gantt chart provides a structured way to represent work break down structures in order to show task start and end dates plus the sequence of tasks with their associated dependencies and assigned resources among other things.

You’ve probably run across project managers on projects creating Gantt charts to a varying degree of detail and not immediately thought this charting could be useful to represent a single view of the work your team is doing. There are various tools, both commercial and open source, that can be used for creating such charts. With a the plethora of choices available to you I would strongly encourage you to leverage whatever your company standard project management tool is for Gantt chart creation. The value of using the same tool as everyone else is to produce a Gantt chart that style-wise is similar to others in your company for easy consumption by your audience. Alternatively, you could ask project managers you work with what they use. Also, feel free to search the Internet for “Gantt chart software” and explore the myriad of choices.

Determine Common Work Request and/or Project Phases

To begin, first determine the best mix of the your company’s standard project management methodology terminology for project phases (“Visio and Scope”, “Pre-Planning”, “Design”, “Development”, “Testing”, etc.) and assign each one a unique color. Below is a sample list phases I will use as an example:

Pink Planning

Purple Design

Red Development

Green Testing

Blue Deployment

Yellow Post-Deployment Support

Remember, the goal of your Gantt chart style resource plan is to easily communicate externally what your team is working on. The more similar the terminology to what everyone else uses the easier for your management and work requesters to quickly grasp what you are trying to communicate. The consistent use of colors for the various project or work request phases helps to easily and visually determine what phase a project or request is in at any given time.

Determine Unique Work Engagements

Add in any unique team work engagement model terms you see benefit in calling out. An example would be if during the formal project “Development” phase your team has a pool of people that can do user interface development as well as another pool that work on business logic component or service development. Try to use as close a naming convention as possible to what the standard project methodology uses. As an example:

Light Red Development – UI

Dark Red Development – Biz

In the case that you have people that can actually work in both groups, using my example above involving UI and Biz development, this resource reporting approach will clearly show who is working on what when. Additionally and possibly more important is the ability to conduct “what if” analysis when a higher priority request arrives. There will be more on the “what if” possibilities later in the series.

Note: One final word of caution, try to avoid creating an incredibly granular work engagement list. A very log list will make keeping the chart up to date a full time job plus it will detract from the simplicity you are striving for in reporting to external parties. Let’s face it; external parties are in a hurry. They don’t particularly need nor care to know your resource A is doing a solution approach review of resource B prior to a full team design review prior to a design committee meeting. They need to know:

• What is in flight at an extremely high level of detail.
• Impacts of a new request hitting your team.

List all Work Requests and Projects

Next, adopt a work request or project naming convention as similar as possible to the one your company uses. If requests have numbers, capture those numbers. If a project has had several name changes, use the most recent but consider indicating the previous names. Enter all the requests or projects you know your team is working on at present as well as all the possible requests or projects that you are aware of that might involve your team. This will be an on going and frequent exercise thus initial list perfection isn’t required. Over time, the list will become more and more accurate and comprehensive.

Enter all your Team Members including Yourself

Most Gantt chart creation tools have a place for entering in “resources” to be assigned to work. Make sure to enter yourself in the likely event that you will be participating materially in listed work at some point.

Enter Work Phases for all the Work Requests and Projects

Yes, now it starts to get a bit tedious. For each work request or project you entered, add the standard work phases you plan to track. You maybe tempted to enter only phases you consider important to reduce the data entry. As you become more experienced at how your resource plan is used in day-to-day resource work handling you may take shortcuts. But, if you are starting out with a new team plan, I strongly suggest to don’t cut corners just yet.

Link Your Resources to the Work they are doing

Now, for each phase entered for each work request or project, enter the resources that will be performing tasks on each of the phases for all the work requests and projects you entered. Don’t worry about start/end dates of phases nor the percentage of time spent on “concurrent” activities for the same team member just yet. I’ll offer some ideas for you to consider on the level of detail and effort you may want to expend in that area.

Review with Team

Now is a great time to have your team members check your work! Consider adding a review of this list at your next 1:1 with each of your team members. You might be a bit surprised to hear what other things your team is being pulled into beyond what you have captured. As a side benefit, you should experience an up tick in engagement from your team now that they know that you care more about what they are actually doing. Plus, they’ll see that the work estimation template exercises are actually going to be used for something beyond just mindless administrivia. By the way, if a team member reports they are working on something but they haven’t previously provided a work estimation sheet for it, now is a great time to ask them to provide one for the work they think is remaining on this unlisted work request.

Now you should have the start of a Gantt chart that captures all the request and project work your team members are working on by work phase of the request or project. You’ve also vetted your chart with your team and increased your team’s level of engagement. Look for the next article in the Single View of the Work series to complete the draft of your Gantt chart by including more data from the work estimation sheets your team is completing.

“You can’t measure it, you can’t manage it.”

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, we developed some techniques to get out in front of the requests coming to your team. Now it is time to put together a way to capture that data in a meaningful way that will better reflect what work your team is doing and the impact of new work on in-flight work. This article will describe the benefits of using a work estimation template for collecting this information for more effective resource planning.

Let me start by commenting that I wrote and published the first six articles in this series around the third and fourth quarters of 2009. Since that time, I have been struggling with part seven in that I wasn’t able to succinctly capture a non-company, non-industry specific model that I felt I could share publicly with confidence. Thus, this series stalled at part six. Since that time, I’ve managed additional sets of teams in different industries and now feel I have a solution that is backed by personal experience and ready for public consumption and criticism.

The theme from this series of IT management articles is clearly that there needs to be data collected, documented and modeled to support ones management positions creditably and the ability to successfully commit to executing and delivering quality work. Through personal experience, the size of the company nor the size of the IT department significantly impacts the data model and approach I am proposing:

1. Provide structured and consistent work estimation criteria to your team members.
2. Collect that formal work estimation data into a single team resource plan.

Formal Work Estimate

Avoid the new manager trap of believing you and only you can make accurate work estimates for your team’s services. Force yourself to delegate that work to your team members. This provides a host of benefits, including but not limited to:

1. More accurate estimate based on the skill set of the individual about to do the actual work and not your skill set.
2. Gives team members a sense of empowerment and the ability to have an element of control over their destiny.
3. Builds a capability in your team that allows you to focus on things only you can focus on.
4. Enables more bandwidth for you to be objective in reviewing estimates and providing constructive coaching feedback to team members.

As Peter Drucker (or Robert Kaplan?) is famously quoted: “You can’t measure it, you can’t manage it.”

Many technical people are great at executing technical work but they may not be so great and providing estimates for that work. Thus, one way to accomplish coaching team members is to sit down with them to talk through their original work breakdown estimates compared to the actual time it took them to complete each task. Helping a team member see where they can improve their estimation skills through data points can be extremely helpful since the likelihood future work will be based on current work is relatively high. Having that reference back to past similar work estimates contextually helps in future estimation exercises.

How does one go about creating a formal work estimation template for your team? I’ve recently written about this very topic of formal work estimation and provided a sample spreadsheet as a template for having your various team members provide data back to you in a consistent format for easy review. I encourage you to consider this article as a guide for the first part of this Single View of the Work data model and approach.

Now that your team is using a structured method for estimating work, what is the best way to compile all that data into something meaningful? Look for the next article in the Single View of the Work series to dive into how to construct a single team resource plan that builds on the formal work estimation you have your team providing to you.

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.

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.

Real work capacity in a work day = 5 or 6 hours? Really?

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 combined these two lists into a single model of how your team does work.  This article we will dive into team capacity metrics.

So, you have your work request attributes, you have the beginnings of a single model of how your team does work, now let us start to put some numbers together to show your team’s real work capacity.

Easy, each engineering resource works 40 hours a week; done.

Or … how about getting a bit more sophisticated:

40 hours – 3 weeks of vacation – 8 holidays = 36.5 hours per week or 7.3 hours per day.

Great … we are done … this was easy!

Well … there are whole companies focused on delivering this number to an organization based on their proprietary way they take into account inefficient processes, status reporting, change traffic and group/team/feedback meetings.  This article contends that 6.5 hours a day is what resource capacity planning tools generally use as a guess for effective work hours in a day.  In the very same article they further challenge 6.5 as being too optimistic and suggest 4 to 4.5 hours a day is more probable.  Something tells me if you were to approach your management with a claim that your team is really only able to do 4 to 4.5 hours of work in a given business day you would be on a fast road to picking up your last paycheck.

But at the same time, to say your team is productive on engineering activities 8 hours a day or even 7.3 hours a day would be equally unrealistic.  So how does one arrive at a plausible number?  I will venture to say it involves one part science to one part “guesstimation”.

Science:

Do you have any sort of time reporting/tracking system?  If you do, you are in great shape as far as useful data is concerned.  Before you go digging for metric gold, you should consider pinging each team member to see how they actually approach time entry.  Do they just put eight hours every day without any delineation for different projects or meetings or even lunch?  Make sure you assemble how your team is entering time before making any assumptions on the data you are mining.  You may find it helpful, after chatting with each team member, to create a time entry guide so you can help get everyone pointed in the similar direction.  After handing out the guide, start re-checking the time entry data to see if everyone is consistent or if you need to revise the time entry guide to course correct.

Guesstimation:

So you aren’t lucky enough to have a time tracking system of some kind already in place.  You could try and whip up something in say MS Excel and collect files from everyone each week.  Or, you could go find an open source product such as WR Time Tracker* or My Time Card*.  Or, instead of having to figure out a way to convince your team you really are trying to do a more scientific capacity planning exercise with real data versus being the “The Man” and wanting to track their every trip to the restroom and the coffee station, you could make an educated guess.  Try this:

In given month there are 20 working days on average thus at 8 hours a day, someone could be working 160 hours in a given month.

Catalog every team member’s allotted vacation time, holidays and sick days or whatever allows an employee not to be at work.  Average across your team members (since we are guessing) and compute to total hours.  Subtract that number from 160.

Do you have a team meeting every month?  Subtract one hour per month.

Do you have a department or large group meeting monthly or bi-monthly?  Subtract that as well.

Your probably have other meetings for human resources functions or life safety or company training or design reviews or architecture reviews or committee meetings: determine those monthly and subtract as well.

Don’t forget any external training, conferences, seminars, etc., average and subtract those as well.

You may be surprised to find when you sit down and figure out all of the “corporate distractions” from doing actually hands on engineering work, you end up with somewhere between 5 and 6 hours of actual concentrated engineering work time.

Now, are you wondering why your project estimates always seem to fall short?  Have you sat down and gone through this exercise?  Even if you haven’t gone through this “guesstimation” exercise, pick a recent project that ran longer than estimated and try using a 5 or 6 hour work day instead of 7 or 8+ and see if you come closer to the actual target.

Anyone else have any tips in this area or a handy MS Excel template they can share that makes this easier?

The next article will dive into a very simple project/request capacity exercise.

*I have no direct experience with these products.  Review their terms and conditions and product feature set prior to installing and/or purchasing.

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.

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 outlined below to stop the surprises:

Step 1: Identify the attributes of your team

First, sit down and make a list of all of the request attributes of your team.  The request attributes represent all sources of work that can be said to impact your team in some way.

For a typical engineering team, I’ve identified the following example attributes:

Your Team's Work Request Attributes

• 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
• 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.
• Projects requesting engineering support = business sponsored projects that require some resource assistance from your team

Step 2: Build a list of sources of requests to the attributes of your team

Make a list of the sources of work requests

Proceed to go attribute by attribute and identify all of the possible sources of requests to your team.  Breaking down the sources based on similar pattern request frequency.  Using the example above:

Production Support Issues

Breakdown the high level sources of these requests assuming you provide IT services to company employees:

• Company centralized help desk

Or if you provide IT services in the form of a company product to end customers (such as a company web site):

• Company centralized help desk for employee operations group that services the product
• Customer call center that takes trouble calls directly from the end customer users

Vendor product end-of-life

Breakdown all of the vendor products by vendor, then product, then version and corresponding end-of-life date:

• Vendor A
  • Product X, Version 1.0, end-of-life = 12/31/2009
  • Product Y, Version 2.0, end-of-life = 7/1/2010
  • Vendor B
    • Product X, Version 5.5, end-of-life = 12/31/2010
    • Product Y, Version 7.0, end-of-life = 7/1/2010

Vendor product upgrades

Breakdown all of the vendor products by vendor, then product, then version, corresponding upgrade version and upgrade driving force criteria:

• Vendor A
  • Product X, Version 1.0 to 1.5
  • Upgrade in order to reduce the manual effort it takes to administer the system with the automation provided in the new version
  • Vendor B
    • Product Y, Version 7.0 to 7.1
    • Upgrade in order to get the ability to import documents in the XYZ format when the XYZ format becomes the company standard at the end of the year

Service Strategy

Breakdown all of the requests that consume time revolving around the strategic aspects of your team’s services and their associated time/resource demands:

• Yearly budget, Aug. thru Sept. yearly cycle
• Architectural Review Committee Meetings, 4 hours once a month every month
• Quarterly service roadmap presentations to senior management, 2 hours once a quarter plus 2 days each to prepare
• Vendor management, approximately 1 day per month spread throughout the month

Projects requesting engineering support

Breakdown the high level project engagement model that makes resource demands on your team:

• Yearly IT externally sponsored project discretionary IT project cycle
• Internal department sponsored projects
• IT sponsored projects that require changes in your services to support their projects goals

In the next article, I’ll take the attributes and the request sources and identify trends you can use to start building a work model for your team.