Quantcast
Viewing latest article 1
Browse Latest Browse All 10

Single View of the Work, Part 3

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.

Image may be NSFW.
Clik here to view.
Real work capacity in a work day = 5 or 6 hours?  Really?

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.


Viewing latest article 1
Browse Latest Browse All 10

Trending Articles