* The Business of Software

A community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

This community works best when people use their real names. Please register for a free account.

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Man Days Calculation. Any Ideas?

Hi folks.

Our client asked us to provide man-days calculation for one of our project. We used to sell software product (until now). This is our first project and we haven't asked to make man-days calculation before.

- What do we need to consider?

- Do you know any man-days template (table template)?

TIA
mISV Send private email
Thursday, May 03, 2007
 
 
Do you really need a template?  How many people are you and how long do you think it will take you to complete the project?
Marcus Tettmar Send private email
Thursday, May 03, 2007
 
 
6 hours = 1 day
1 person @ 6 hours = 6 man-hours = 1 man-day
2 people @ 6 hours = 12 man-hours = 2 man-days

Adjust hours per day as appropriate, but remember that the only way to get 8 hours production is to have a work day that is longer than 8 hours and that going past about 10 working hours per day or past about 50 hours per week doesn't gain you much, if anything.
Ron Porter Send private email
Thursday, May 03, 2007
 
 
Try another approach. Say this our budget and that will last X weeks. Let's see what we can get done it X weeks? Have one week iterations with a shipped system every week. Work with the customer to create a backlog and select the highest priority stories for the first sprint. Create smallish stories. Get a feeling a reference for your velocity and you'll be able to estimate better. More importantly you'll be working closely with your customer to deliver working software. Try to convince them this is a good thing and they'll end up with something better.
son of parnas
Thursday, May 03, 2007
 
 
I don't understand why a client wants that sort of information from you..it shouldn't matter to them.  All they should be concerned about is when you promise to deliver the project.
DanH Send private email
Thursday, May 03, 2007
 
 
You could also look into CoCoMo Modeling of your project.

http://en.wikipedia.org/wiki/COCOMO
http://www.softstarsystems.com/overview.htm
http://www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html

This metric may take some time to understand and isn't perfect, but it does give you perspective. Also for a client,  it looks fancy.
pete Send private email
Thursday, May 03, 2007
 
 
"I don't understand why a client wants that sort of information from you..it shouldn't matter to them.  All they should be concerned about is when you promise to deliver the project."

There may be accountability issues. Your client may have to prove to someone that they have paid a reasonable price for this work, in which case they need to know how much time you think it will take.
DJ Clayworth
Thursday, May 03, 2007
 
 
I'm reading http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 by Steve McConnel at the moment, and recommend it (or at least I recommend the first third of it, which I've read so far).
Christopher Wells Send private email
Thursday, May 03, 2007
 
 
I second Christopher's recommendation.  It may not help you immediately with what you've been asked for, but it will let you know some of the gotchas and prepare you for the next time.
a former big-fiver Send private email
Thursday, May 03, 2007
 
 
"Your client may have to prove to someone that they have paid a reasonable price for this work, in which case they need to know how much time you think it will take."

But that's not how business works. Your customer doesn't need to know your costs and other proprietary information. Take whatever price you quoted them, divide it by $20 and tell them that's how many man hours it'll take. They'll think they're getting a huge bargain.
Brian
Thursday, May 03, 2007
 
 
"Your customer doesn't need to know your costs and other proprietary information."

Government contractors are required by law to provide this information.

More to the point, you're forgetting that while some jobs do need to be done by a deadline, other jobs just need to get done period regardless of how long it takes. This kind of information is useful when deciding whether to throw more money at the problem and get it done sooner, or bite the bullet and sweat it out.

(Yes, I'm aware of the Mythical Man Month.)

For example, if you need to become SOX compliant, you really have two choices; pay for 100 developers and get it done by next year, or pay for 40 developers, get it done three years from now and pay the penalties for non-compliance in the meantime. Finding the best economical balance does require the job to be estimated in man hours or man days.

I'm just saying...
TheDavid
Thursday, May 03, 2007
 
 
+1 for CoCoMo.

Particularly when couple with something simple like Function Point Analysis to show that you've really thought about what it is that you're planning to develop.
Thomas Rushton Send private email
Thursday, May 03, 2007
 
 
"Government contractors are required by law to provide this information."

That's only for time & materials kinds of contracts, not firm fixed price. Your costs are your business. The OP's customer may be asking that to determine how much it would cost to do it themselves, but they have no idea how to go about calculating it. He'd be giving them that info for free.
John
Thursday, May 03, 2007
 
 
True.  However, there are very few firm fixed price contracts in government contracting. The Feds like to make a big show of being worried about cost overruns.

It's also worth reminding everyone that while the original poster has done various products before, this is his first project and he's being asked for man days. He thinks the request is reasonable which is why he's asking how to calculate them. That sort of implies it's not a fixed fee contract.

Err... I doubt his customer is coming to him and saying "I'm prepared to offer you $1m, but as a condition of the deal, I want to know your man days." As Brian implied, it's more likely they'd ask for a proposed delivery date rather than a labor breakdown if that was the case.
TheDavid
Thursday, May 03, 2007
 
 
"What [else] do we need to consider?"

Oh, I forgot to give an answer. Include everything except travel expenses. If you need to set up the infrastructure, buy computers, install software, train, bill them. If you need to schedule regular meetings to negotiate the requirements, bill them. Anything you have to do for them, that you aren't already doing as part of your normal business practices, it goes on the list.

I find that a lot of people expect that all you have to do is start typing code, which couldn't be further from the truth.
TheDavid
Thursday, May 03, 2007
 
 
>>That's only for time & materials kinds of contracts, not firm fixed price.

Not always.  The last project I worked on for the State of California was fixed-bid, but we still had to provide hourly reporting for the periodic billings.  Depends on the contracting entity & what governing law says about their budget.

+1 to everything TheDavid has said about gov't contracting & to the OP.
a former big-fiver Send private email
Thursday, May 03, 2007
 
 
Or maybe the client's question is just a reality check to see if the OP has any concrete idea what it will take to fulfill the contract.

Thursday, May 03, 2007
 
 
Well,

You need to estimate the software effort first. Then find how many people will work on the same to deliver the project. Then and only then the man-days will have a meaning.

Example

One Man Day = 8 hours
Estimated Software Effort = 1000 hours
Man-days for the software = 1000/8 = 125 Man days

For a one man team the Mandays are 125/1 = 125 Man days
This means one person working for 125 working days can finish the software.

For a two man team the Mandays are 125/2 = 62.5 Mandays
joyshinde Send private email
Friday, May 04, 2007
 
 
The guy asked a question and half of the respondents will question his question. I think if you do that at least first answer the question. Tell the man how to compute his man days and then rant about how stupid that is to be asked for. If he was on a medical forum and asked for a treatment would you argue his illness?
v
Friday, May 04, 2007
 
 
I've found the following approach to be very effective.  It is simple and it works.

Painless Software Schedules
http://www.joelonsoftware.com/articles/fog0000000245.html
Andre Oporto Send private email
Friday, May 04, 2007
 
 
" The guy asked a question and half of the respondents will question his question."

That's because this is a discussion forum. If this were a Q&A forum the posts would be different.
John
Friday, May 04, 2007
 
 
joyshinde> "The Mythical Man-Month" is now running across my mind...

Two people are not twice as fast as one, because there is a requirement for the two to communicate, if only to discuss status.  This communication overhead reduces the multiplier effect of adding extra staff.
Thomas Rushton Send private email
Friday, May 04, 2007
 
 
@John OK, you're right

This is how I would do it: First when you negotiate for a project you need to clarify it and by that I mean you need to get a pretty good idea about what you are supposed to do. One way to do this is to break it down in modules and screens/pages in an informal specification document that would add some detail to your project specs. Then you can go thinking about how much would it take to build the infra-structure for your project. Just think about building the first screen of each type and all the components you need. After that you can think about all the functionality, one screen at a time. Add up everything and add a generous buffer. Depending on how good you feel your estimations are you can go from 30% to 100% with the buffer. From here computing the man days is trivial.

Now questioning the question part: if you are negotiating a fixed price project, your customer doesn't need to know the way the price is computed, including the man days needed for the project. If they pay per hour/per day it is their right to know your estimation on this as they have to budget for the project or compare offers.
v
Thursday, May 10, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz