The bearing of a child takes nine months, no matter how many women are assigned. (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)

This is one of the most insightful observations made in the last 25 years on the subject of project management. It originates from 1975, and is written by Frederick Brooks in his article "The Mythical Man-Month". Welcome to the age of rocket science…

In the communication on the timing aspects of a software project, many mistakes are caused by the use of the unit man-month. Like the word says, it indicates actually "a month spent by one person". To determine the cost of the project, it is a fairly good unit: building the darn thing takes 3 man-months. You know what a guy costs per month, so you can do the math. But while the time passes, this statement will be shortened into "three months", either in written word, or in the minds of the people involved.

"How long does the project take?" "Oh, 3 months."

And then the fun starts.

"We need to finish the project sooner." "We'll add a resource. Problem fixed."

The problem with this kind of reasoning is the fact that some tasks cannot be split. Because of sequential dependence, or just because it is not possible (like the birth-thing). The trick is, that a man-month is an indicator for cost, and not for progress. So, while looking and discussing on time, be aware of this communication trap.

This may be the most valuable lesson, but it is not the only thing to consider about time at this moment. At this stage a detailed planning will not be created (luckily), but a global time-frame, with start- and end-date will surely be available, at least in the minds of the stakeholders concerned. Here holds the same thing as discussed in the 'money' paragraph: try to get a fix on 'why' these dates are chosen.

"It should then be finished because…"

• the most important manager takes a holiday (paid in advance) afterwards
• another project will start directly after it, and people are already allocated for this
• someone just yelled this date one day, and everybody uses the same mantra ever since

See if the deadline stated holds with the cause and target for this project.

You may perhaps miss something about planning and estimating stuff, this will be treated after the requirements are known (chapter "Project progress"). However, at this point in time some statements will be made about time, money and effort. If you have to rely on the input of experts for this (programmers, analysts), the best, and only thing you can do, is to talk to them and get an estimate

While doing this, focus on why they think this particular amount, is it similar to what they have done in the past, change some of the stuff you tell them, to see how that changes their behavior. But most of all, listen seriously to them, let it be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time.

Related links

Why The Customer Always Wants His Stuff Tomorrow