Resource Allocation

I’m going to talk about resource allocation.  This is where you (as an IT manager/CIO decide which people to combine into your team).  When I started designing software I used to estimate the software, define a deadline and then divide it by a 8 hour work day to determine how many programmers I needed.  Over the years, I’ve learned a few things.  One important issue to understand is that a mixture of different expertise can be a cheaper way to build software.

The reason why this is true is based on the fact that people must wear different hats to perform all the tasks it takes to run a software shop.  Especially if you are also attempting to provide services for existing software.  I’m going to start with a very simple example.  This is, of course, an example that I made up and it might not work in your situation.  I’ll show you how to build the numbers to determine if a different mix of people will help your projects bottom line.

Here’s what I’m starting with:

What I’ve done is setup a project that requires about 1000 man-hours of labor to complete (the total coding hours is shown as 930 above).  The total time it will take the three programmers is 600 hours (they’re all working 600 hours in parallel).  Or about 4 months (OK, it’s 3.75 months, but I’m trying to keep the numbers even).

If you’re looking at all the daily tasks listed, you’ll immediately notice that these three programmers are spending a lot of time on help desk, paper work and debugging.  So my question for this simulation is “what would happen if we replaced one programmer with a help desk/debugger guy?”

Help desk is taking about 240 man hours away from coding and debugging is taking 450 man hours.  That’s a really large chunk of production time.  Plus, it’s a little more than the 600 hours that the extra programmer is taking over-all.  I’m going to ignore the paperwork time and assume that 10% is normal for all employees of this particular department.

Here’s the new spreadsheet:


OK, so I re-tasked all the help desk calls to the new help desk/programmer and I allocated some of the debugging.  In reality, this person might not be as efficient at finding and fixing bugs as the programmers, but the numbers should still hold up.  Notice how the programmers have been able to do 1020 man-hours of coding in a 600 hour time-frame.  That’s better than the mix of people above.

There is also one more consideration here.  You will want to sink your money into some really good programmers and possibly hire an intern or maybe someone straight out of college for the help desk/debugger position.  This will be cheaper than hiring three expensive programmers.  Your project will still be delivered on time.  Also, the moral of your programmers will be high because they don’t have to deal with help-desk calls. 

Conclusion

OK, so I’ve shown a really simple example.  In more complex examples it’s possible to separate programmers by specialty.  If you can get a mix of programmers that have strengths in different fields, say interface design, business code, database design and mix them in a team where each can focus on their skilled area.  You can benefit from the strengths of all of them combined. 

Also, you might be asking yourself, “where did you get all those numbers for that spread sheet?”  I got the numbers from metrics.  Each person will enter their time into a time tracking system (computerized or on paper), then I roll up their times per week to get their average percentage.  I do this all the time for my employees so I see where their time is being allocated.  These percentages are then used to estimate how long it will take for my development team to complete a project.  It’s not as easy as saying “160 man hours / 2 people = 80 hours, errr, 2 weeks!”  You have to account for percentage of time allocated to the actual task.  The rest is what I consider waste.

 

Leave a Reply