Effective Man/Days in a month

I used to work for a company that had to do something similar while we were planning our project timelines.  I used 6 hrs/day per person as working hours.  It wasn't perfect, but it was better than the assumption that you would get a full 8 hours of work out of a programmer. 

With that said, I would think that with all the PM types that are MT/CT members that they had been exposed to a method that was a bit more accurate/sophisticated.

We estimate 18 days of productivity per month per person.  "We" is a software development shop.  In a month with a lot of holidays, we'll reduce that a little, but overall it seems to work out pretty well.  It gives us a little slack for sick days and such, without needing to spend a lot of time in overhead activities to come up with an estimate.  Overall, it seems to work.

--
Dennis Sherman
6-1-2-7

Based on first- and second-hand experience in estimating and delivering software projects across many industries:  when in doubt, ask the folks who will do the work.

Best is to ask the people involved how long it takes to do whatever it is.  You will likely get, say, "three days or so for main character sketch" or "two weeks to find three voice talents, plus two weeks to record four pages of dialog, plus one to three weeks for post-production of voice assets".  Unless you're using inexperienced folks, or doing something new or unusual *to them*, they'll have a sense of how long something should take.  Make use of their expertise.

In some parts of the working world, the provider company "owns" the risk of eating excess time.  That often leads to fixed-cost contracts, with the actual estimate expanded out by some padding factor to cover inherent variability of the process of production.  In other parts, the client "owns" that risk, which likes to lead to per-piece or per-hour terms.  If you're using one or the other, that can suggest who "owns" that risk.

You might have specific work which does not take well to simply adding more bodies.  Two people might hire fifteen session musicians twice as fast as one, but rehearsals will still take a week before everyone's ready to record.  (The archetypical example is:  a baby takes nine months no matter how many people help the mother involved.)

Graphics and media for video-games (I will presume) has more independent results and a much more even cycle than the programming and game-construction, which often is over-reliant on long periods of excessive overtime.  So your instinct to presume "a day is a day is a day" is probably fine.  In those situations, I've gone with "five productive hours a day per dedicated person" as a reasonable first guess, adjusted as we measure real productivity for the team or group as a whole.  If people are not dedicated to a single project, or a single type of work within that one project, that number goes down because of having to switch.

Perhaps you'll frame it as "two weeks to deliver one draft piece of each type of deliverable", then "two weeks of delivering (the first 20% of results)", with however many people you expect you'll use.  By then, you'll have at least two weeks of real data.  Any "extra" capability means you can pull people off, or finish early and allow for more feedback cycles as the client's game evolves.  Any short-fall means you pull in people, or work with the client for a longer delivery cycle, or fewer or lower-quality pieces.  As long as someone's making results and projected results visible to the folks working, you should be able to take the uncertainty in stride.

-- Joseph (DiSC 4247)

The only way to be more accurate with estimates is to make estimates, compare to actuals, and adjust as trends appear about the difference.  For the first time through, estimating on your own, you have no way of being accurate except by borrowing others' experience in estimating.  You can also find someone who's done this sort of estimate before, and talk with them.

In my father's field of architecture, estimates can be reasonably accurate and tight because we've been building (and comparing estimates to actuals for physical activities) for several millenia.

In my field of software development of custom and unusual projects on new technologies, the accumulated experience on estimates is that they're harder than for architecture.  People's output will vary by a factor of ten or more, since there's few physical constraints like there is in building.  Variability between similar tasks is much wider, even for a single person, and there's normally much more learning to be done during the process of creation that cannot be done ahead -- exploring trade-offs, normally, but sometimes figuring out how to get an external organization's defect fixed or worked around.  So far, estimates for projects or pieces of projects are most accurately estimated like "likely six weeks, best four, worst fourteen" and "six months to two years".

The four aspects of projects you have to work with are quality, resources, scope, and time.  The work takes time to produce at acceptable quality.  Adding resources tends to take weeks to months, so expect scope to be where you have to scale back.  To do so controllably, look at Agile (in general) and Scrum in particular.

-- Joseph (DiSC 4247) 

How to improve estimates is a very different question than how many productive person/days there are in a month.

The single best article I've ever seen on this topic is at http://www.joelonsoftware.com/items/2007/10/26.html.  Following this process for 6 months reduced my variance by 20%.  Being persistent about collecting all the data needed was a bit difficult in the absence of a tool that did it for me, but well worth while.

There is a ton of literature about estimation, especially in the software industry (largely because we're not good at it).  Good reading can be found at http://www.construx.com, under Resources.  Select the Estimation topic, and you'll find a year's worth of good material.

Good luck!

--
Dennis Sherman
6-1-2-7

Its a time-honoured question ...all the way back to "The Mythical Man Month" - a classic Project Management book by Fred Brooks (1975)

The problem is that if your work was being done by workers who are interchangeable, work at a predictable speed, don't have to interact with each other, and work full-time on the project, then yes, you can get a good estimate from the number of weekdays minus any holidays and an appropriate allowance for sick days and other disruptions.

But, but, but... those assumptions work for some tasks (copy-typing or picking fruit perhaps) but usually not for graphic design or programming, or many other activities.

So that introduces variables which vary wildly depending upon your staff, your client, and the other work being done simultaneously chez vous (knowing about the likely variables may help you to estimate them, & so come up with the time estimates you need for your work):

Often, workers aren't interchangeable: It doesn't matter how many designer hours you have free right now, because nothing else can happen until a programming problem has been solved. Or we can't go any further until we have management sign-off, or copy, or assets or whatever. 

Some work is done at an upredictable speed: (for reasons other than laziness!) A designer or programmer may immediately think of a great approach, or may take time to hit on a promising line of attack, or may have to abandon an initially promising approach and start over. 

Workers have to interact: the design is sent to the client, and there is a delay while the client thinks about it. It may be irrelevant how many man hours are available at your end until the client says they like the design. Or, the client hates the design your designer loved so much, and you have to start over. Similar issues arise when work requires more than one person at your end. And that is then exacerbated by...

workers don't work full-time on the project: usually there is more than one project to do. So you ask Daphne to estimate how long a piece of work will take and she says "3 days" but that might mean "3 days if I do nothing else" and the reality is that she has a lot of other stuff to do. So either the job goes into her in-tray and the 3 days doesn't start immediately, or Daphne tries to juggle several things, making a start on this job before her other stuff is done (this can be very inefficient for creative tasks where you want the worker to think deeply about the problem until a solution is found). It's very difficult to have a workflow which keeps everyone 100% efficient: it's almost inevitable that someone will have to wait for someone else, reducing their effective man-hours on this project (that waiting time will, where possible, be used for work on other projects).

That's why no-one can provide you with a formula to take the theoretical working hours and divide by x. Or not a formula that will work for you , except by chance. You can of course keep records & figure out how many productive working hours you usually get on the project - that at least prevents you assuming that this time you'll be radically more efficient than ever before. Also, such record-keeping is a useful tool for management - what can be done to use time more effectively?

Joel Spolsky, founder of Stack Overflow and software veteran, recommends something that his internal team does called "evidence-based scheduling." It's a very data-driven approach, so it may not be helpful the first time you are doing a project like this, but it's worth taking a look at. The basic premise is that you  create a collection of "velocities" for each person on your team that does estimates. This amounts to (Estimated time / actual time) on past projects. You then essentially discount any future estimates by a random sample of these velocities to create a probability curve for when the deliverables will be met. They actually have this capability built directly in to the Project Management software that they produce (FogBugz).

For a more detailed explanation, see here. Its worth a read.

http://www.joelonsoftware.com/items/2007/10/26.html