The is the third entry in the Software Project turnaround specialist series. Cost overruns in a software project come from many places: You end up needing more licenses for the IDEs, more servers, more etc. These are the obvious and easy to manage cost overruns. I have found that the cost overrun that always creeps on you is the man hour cost.
If your organization is like most software shops you employ a good number of contractors that get paid by the hour. These employees (like all employees) get paid whether they work or not. The main difference is that if they work overtime, they get paid extra. I know this is obvious, just hang on for a minute. So, you contract a developer to do 40 hours of work. Since he or she is a contractor and you are not sure of his/hers abilities and you have a tight schedule you assign tasks to that developer that are not on the critical path.
As we all know, the main difference between tasks in the critical path and tasks not in the critical path is slack. A task in the critical path has 0 slack. Which means, that if that task is delayed the whole project is delayed. A task not in the critical path has slack. This means you have a cushion of time that the task can be delayed without delaying the project. Now, suppose that you assign task C to a contractor. Task C is not in the critical path and has 10 hours worth of slack. So, if task B that task C depends on is 5 hours late, task C is still on course and in good shape.
Let's say task B is five hours late. The contractor was not able to start task C until task B was completed and it was 5 hours late. In project management theory this is not a problem because task C has a slack of 10 hours and it is still far from threatening the project. What did your contractor do for the 5 hours he/she had to wait to start task C? Nothing. The contractor just charged 5 hours to your project without producing anything. It is not his/her fault. So now, for a task that takes the contractor 40 hours, you actually paid 45 hours. Are you following me? Multiple this by tens of contractors against many tasks not on the critical path and you are over budget, without ever making a project management mistake in theory. You kept a close eye on the critical path tasks, put your best resources on those tasks and assigned your least tested resources to tasks with slack.
If your budget was based on the sum of the number of hours all the tasks with take, plus an error margin, your budget is probably too low. You must take slack time into account for contractors (and also permanent employees). Consider the worst case scenario slack situation for each task and add the cost of that time to your budget. This problem occasionally is even more obfuscated by the fact that when contractors are not working on a particular task they charge their time to an overhead account that you don't have access to. Then, when you look at the time their worked on your tasks the numbers look good, but when finance runs the numbers they don't.
Remember if your cost are high and there is no easy answer (software licenses, servers, etc), there is a good chance that the contractor slack combo is getting you.
unit of time, story B takes 2 units. Then if you are done with user story A, you are 33% done. This is the type of logic
Posted by: Coach Outlet Online | June 27, 2011 at 09:49 PM
so good
Posted by: Dr Dre Solo | October 24, 2011 at 01:24 AM