IT resources have capacity constraints just like a 5-pound sack has a limit to how much sugar it can hold.
You may get extra ounces of sugar in the 5-pound sack by stacking sugar up above the top rim of the sack, but eventually it spills over.
All IT resources, , , staff, systems, networks, etc. have limits. One of the keys to managing IT effectively is understanding the capacity of your resources and their limitations. You must understand both what your capability is as well as how much you can do to manage your client’s expectations.
Let’s look at an example using a programming team. Each programmer has a certain capacity for developing new code in making software changes and new enhancements. In order to determine your “programming capacity”, you need to quantify how many hours of new code each programmer can produce in a month.
A typical month has four, 40-hour weeks with roughly 160 work hours. If a programmer were 100% productive in producing new code, he would deliver 160 hours of code per month, , , but then you have meetings, training, vacations, holidays, and other disruptions to a person’s productive output time.
I’ve always used 120 hours per month as a bench mark of what I think a programmer will produce. Some months will be more, , , and some months will be less, , , but over the course of a year, a programmer will average about 120 hours of productive code a month.
If you have 6 programmers, your programming capacity is 720 hours of programming per month (6 x 120 = 720) assuming all six have the ability to work on the same business applications.
Once you establish your team’s capacity, you can look at the programming backlog, , , i.e., the list of outstanding requests. If each of the requests are estimated for number of programming hours needed to complete the request, you can more easily manage expectations of how much can be completed each month.
If the backlog contains an estimate of 2,900 hours of programming requests, you have a 4-month backlog (2,900 hrs. / 720 hrs capacity per month = 4.03 months to complete).
Ultimately, you don’t care what you work on assuming the department managers and users are establishing appropriate priorities. How you use the “5 pound sack” of programming capacity is not as relevant as ensuring all understand that there is only “5 pounds of capacity” to go around.
Caution when working with a new team
Until you gain experience in working with a programming team, use 100 hours per month per programmer as your estimated output. You do this to position yourself and the team to over deliver. No one gets upset if you deliver more than expected. As you gain experience with your team, you can raise the expectation to 120 hours per programmer per month.
Another reason for doing this is that if the team has a poor quality issue, you will spend some time fixing many of the programming changes they make until you get the quality issue fixed. The hours these fixes require don’t count when a user looks at “effective output” of new code each month.
ITLever™ 