# How to determine number of resources to be allocated in a software project?

Last day I have been interviewed and the interviewer asked me as given the outline of a project, how can we determine the number of resources to be needed for the same?

I don't know to do so.

Is there any standard way of doing so? or is it based on the experience? Or how?

I am pretty new in this activity and my knowledge is zero at present .... so any clear explanation with some example(simple) will help me(and people like me) to understand this.

-
I think this would be subjective –  OscarMk Jun 29 '11 at 6:10

## migrated from stackoverflow.comJun 29 '11 at 7:49

This question came from our site for professional and enthusiast programmers.

This question is best answer by Mythical Man month

What it tells you is that there two catagory of tasks - a. partition-able and b. non-paritionable

As you add more people the partitionable work can be reduced in each step. However, the intercommunication costs grow worse for each addition, especially if each subtask must be separately coordinated with each other subtask the total permutation is ( n(n-1)/2 ) where n is a number of people.

If for a project (which is generally always the case) where communication effort dominates the reduction by parallelization is out weight by added complexity posed by required communication and hence adding more men after some point LENGTHENS, NOT SHORTENS, the schedule.

This is not to say put only 1 person for all projects but, there is an optimum point of people vs. Schedule.

There are various factors (also listed in book) but best optimization could be - for a typical 9 man month project you should have SQRT(9) people = 3.

-

This is a pretty deep topic with a lot of research in it. There's a book called Software Estimation: Demystifying the Black Art which I'm told is pretty good, though I have yet to read it myself.

As far as completion time and total man hours goes, evidence-based scheduling has given me a lot of success. Quoting myself from another answer:

Long story short, you split up the task, write down how long you think it'll take to complete each task (including interruptions like coffee breaks, bosses nagging you, StarCraft, etc.), and then time how long it actually takes you to complete some of those tasks. It's important to be blunt, and to include all your distractions -- because that's part of life as a developer, and it's a realistic factor that influences the time it takes to finish your work.

Then you can either multiply the average estimated-to-actual time against the estimated time of the remaining tasks, or you can take the error factor of your estimations to run a Monte Carlo simulation and determine the probability that you'll be done your tasks on any given date.

The end result is a graph that looks like the first one in that link, where the X axis is the finish date and the Y axis is the probability that it's finished:

I can't think of many other significant and measurable resources that'd be involved in software development, but if there are any, say, the cost in dollars of a web service used throughout development, you could probably apply this same technique with different variables to yield a satisfactory result.

-

Some steps that you can follow.

• Create the work break down structure and timeline of the project

• Get the developers' competency matrix and their unallocated time.

• Match the WBS and Developers in the matrix

• Assign developers accordingly.

-