Project Management Book

...chapter 6 continued

Here's a quiz for you.

At the start of the project pictured on the right, the project manager said the total cost would be 1000 man days: 400 man days in Stage 1 and 600 man days in Stage 2. He knows that in the past, similar projects have expended 40% of their effort in Stage 1 and 60% in Stage 2.

Stage 1 has just finished. It actually cost 800 - twice as much as estimated. So, the original estimate for the project was 1000, 800 has been spent so far - what would you say the remaining project cost will be? The most likely answer is 1200 man days. But what would some project managers say? The remaining cost will be 200: 1000 budget, 800 spent, remaining cost 200. There is a rather big difference between 1200 and 200! Always look at what has actually been spent so far and using past ratios extrapolate forwards to get a more realistic picture of what the remainder of the project is likely to cost.

Rules of thumb

Imagine this. Your developers estimate a project at 49 man months of effort, i.e. one person could do it in 49 months (about 4 years) or it would take 2 people 24.5 months (2 years) or 4 people a year, etc.

Next day you tell the sponsor it's 49 man months of effort and whatever that is in money. He says he can afford it but wants the project finished in 3 months starting from... NOW. Can you do it? Bear in mind the project hasn't started so by definition none of the team is there yet. You say you're not sure so the sponsor offers you unlimited funds and access to IT consultants - whatever you need. Can you do it? While you are hesitating the sponsor points out that in the business they handle 1000 orders a day with 10 order handlers and if they got 2000 orders a day they'd use 20 order handlers and still do it in a day. So, the sponsor says, why don't you get in 49 IT contractors in on Monday morning and do the project in a month? When you look incredulous he says: "OK, tell you what: do it in 4 months, OK?" And if you have no rationale for rebutting his suggestion you may find 4 months is now your 'commitment'.

This is another difference between process-based thinking and project-based thinking. For operational activities you can simply increase the number of people - almost infinitely - as the people are operating independently. But in a project adding too many people just causes chaos, and we all know we can't suddenly employ a huge number tomorrow - they'd have nothing to do. In a project we have to start off with a few, build up and then come down to zero at the end.

So how long would a 49 man month project take? There is a rule of thumb known as the square root rule. Express the project effort in man months, 49, and take the square root of that number. You now know why we chose 49. That would suggest an elapsed time of about 7 months. This works well as a rough guide to the minimum elapsed time of IT development projects. Could we do the project in 6 months? Maybe, if we ban holidays and work weekends. But there is a limit. And if the project spans August it may take 8 months under normal conditions because of holidays. Obviously if you choose not to use as many people as you could, the project will take longer than the rule of thumb would suggest.

If everyone knows the square root rule, including project sponsors, as soon as you say it's 100 man months they know it's going to take around 10 months to get it done. This can result in fewer projects trying to do the impossible. Of course, if your team is happy to bring their camp beds into the office and work 20 hours a day you may be able substantially to break the square root rule. But would your team do that?

The square root rule is sometimes known as the golden square rule: the average team size is roughly equal to the elapsed time in months.

Note that the square root rule gives the average team size not the maximum team size. Thus, in our 49mm project, the team starts at 0, may be 2 or 3 in the early stages, might peak at 12 during the construction stage then drop to a few towards the end before returning to 0 at the end.

In a programme of several sub-projects you'd apply the square root rule to the largest sub-project to get a rough idea of the programme's duration.

This is not a magic formula that tells you exactly how long a project will take - many factors could affect a project's duration. It is just a rough guide to the shortest duration it might be possible to do a project in.

User effort

In your experience, who estimates how many hours of user effort will be required for "IT" projects? If we are honest the answer sometimes is that nobody does. If you're the HR manager and nobody tells you how much work will be needed from your people what will you assume in your planning? A big round zero. Anything is better than a default assumption of zero.

Suppose that on past projects the relationship between IT effort and user effort had been as follows:

So, in the requirements step for every man day of IT effort there had been a man day of user effort. In the user functions design step for every 2 man days of IT effort there had been 1 man day of user effort. Having estimated the IT effort per step you could at least get a very rough idea of the user effort per step. If you can estimate the user time more accurately you should, but anything is better than a zero estimate of user time being assumed because no other number has been mentioned.

The above are illustrations of how the essence can be distilled from past projects to yield rules of thumb that will at least guide project managers to the right ballpark when doing top down estimating.

Realism

In your experience do projects end up costing less than the initial estimate or more than the initial estimate? More? Why? Why do people tend to underestimate at the beginning? Because they e.g.:

• want the project to fly
• don't allow for change
• don't allow for management activities
• don't include quality checking activities
• don't include contingency

Why do project managers sometimes leave these things out? Guilt.

Suppose that on a past project effort was actually expended as follows:

It is only reasonable to assume similar expenditures on the next similar project and therefore to include these things in the next project's estimate. But please add those percentages up - what do they come to? About 50%. You must now go to your sponsor or Board of Directors with your estimate breakdown, 50% of which is change, quality, contingency... At this point even the most experienced project managers begin to feel guilty that they are padding the estimate and what do they do? Shut their eyes hope those things will go away and leave them out of the estimate. If you leave all of those things out the project is going to cost roughly double your estimate.

How might we make project managers be realistic and include the appropriate factors in their estimates? Make them personally accountable for the estimate they give at the start of each stage. At the end of the stage independently measure the actual cost and the closer it is to the estimate the bigger the project manager's next pay rise - and we may even pay him a bonus. And if the actual is miles away from the estimate...

...next

Privacy Policy and Cookies