Hours or Units

Trevor,



Top-down, or bottom-up, what’s the big difference? Isn’t it always bottom-less? (otherwise claims consultants will not exist).

Francis, I gave two examples, but here is another.



Suppose I want to go for a holiday in Europe and I only have $X, but I think it is probably feasible because I did it 5 years ago for the same, or the travel guide says it can be done, and anyway I can adjust what I do there to fit into my budget. Maybe it gets broken down, but not into much detail.

That’s how I see Top-Down, risky.

But if I make list of all of the hotels that want to stay at and art galleries and castles that I want to see, etc, being sure not to leave any out, such as food and fuel, and add them all up then I know what it will take to do what I want to do. I see that as Bottom-Up, still an estimate but much more likley to be reliable.



Of course they never match and what happens next can take several routes.

Hi Trevor,



I would like to know the terminology you have used in estimating, especially " Top down and Bottom Up Estimating",



Can you please explain this so that i can read and comprehend your mail properly,



Thanks,



Francis

Trevor,

I agree with almost everything in your post except your attitude to quantity based estimates. In most cases quantity based estimation of activity duration is most natural and precise. Besides there is a need for company standards in estimating duration of typical activities. These standards are usually based on the corporate production rates.

Tbere is also a need to calculate necessary contingency reserves but this is another story.

Regards,

Vladimir

I think the question touches on how the initial estimating or budgeting is done, and the consequences of that.



In "quantities based estimating", Hours (ie man-hours) are calculated from unit rates such as hours per tonne for structural steel tanks or hours per m3 for concrete. There might be various rates for different types of product such as ground slabs and suspended floors. Rates and the breakdown come from the company project history or the big book of Rates.

Rates may be divided into trades so eg (just making it up):



100m3 of concrete

10 hours of setting out @ $100/hour

20 hours of formwork assembly @ $50/hour

20 hours of reinforcing steel assembly @ $55.88/hour

10 hours for concrete pouring @ $15/hour

10 hours for finishing @ $80/hour



Rates may or may not include the wood and steel.

This often is used for early tender cost estimates and for arriving at the tender price/bid. It is quick and easy because it allows price to be derived from great big measurable quantities of the overall project rather than built up from the detail of the Tasks. Of course, this type of estimating says nothing about the overall timing/schedule/programme, and one of those is required for the tender, so an un-resourced, un-costed programme with very long bars and not many Tasks is put together, the main thing being to show that the project meets the client’s (usually arbitrary, top-down) completion deadline.

If there are resource assignments at this stage, it is usually just enough generic ones to generate an early (ie rough) hours S Curve to stick in the tender, and the hours are made (forced) to produce totals which match the previous hours budget estimates. Often this is not easy because the Quantities Breakdown Structure which was used by the estimator/QS does not map directly to the WBS which is a more natural description of the scope and methods. In the example above, there may be 3 or 4 setting out Tasks which haven’t been identified yet and they might have different durations and different resource assignments. It may be thought necessary to let the QBS drive the structure and content of the WBS, even though a different WBS might be a more natural fit to the project for schedule purposes. At this point, there is nothing in the programme about Costs, which might be regarded as un-important at this stage since it has already been dealt with previously and separately by the estimator.



The next thing that usually happens is that the contract is awarded and there is an urgent need to detail the programme. Bottom Up meets Top Down, something has to give. As the scope is chopped up into smaller, shorter Tasks and less generic resources are assigned, and the predecessor logic is improved, it becomes harder to make (force) the Bottom-Up Hours estimate to match the Top-Down estimate. Inevitably, as detail is improved, it is discovered that the quantities based Hours estimates are too low, which means of course that the bid is low. Also, usually, the project won’t easily fit into the time deadline (not without a few tricks like FS links with negative lag). The price and the deadline constitute the box that the project has to fit into, and are by now enshrined in the contract, but it is already bursting out.

So even though it looks like a whale in a sardine can, it is made to look like it fits and handed over to the client on day 10 as required and becomes the "approved contract programme".



I don’t like/trust quantities based estimating

I don’t like/trust Top-Down Hours estimating

I don’t like/trust Top-Down Costing

I don’t like/trust arbitrary (Top-Down) deadline targets

I don’t like resources, hours, costs, pricing etc being calculated separately or in isolation from the timing and programme.

... and especially they should not be what drives the detail programme.



I prefer "ABC", Activity Based Costing, and bottom up estimating.

I trust the Critical Path Method, which means scheduling forward from a start date and seeing where the hours, cost and finish date end up. Targets, deadlines and budgets which arise outside the plan or are arbitrary are irrelevant to CPM, not that they can be ignored.

The Tasks come first, then the durations, then the predecessor relationships, then the resource assignments (in detail, not generic), the the resource costs and Task Fixed Cost.

When I discover that my network/plan/schedule/programme is saying that my project exceeds all of the top-down targets, I note it, head towards the targets if possible, but I do not try to force it to meet them. After all, they’re early, rough and wrong. There is no point in producing a programme which appears/purports to show a project which meets all of the external, arbitrary, top-down, imposed targets at the expense of a feasible, plausible, manageable method of achieving it in execution.



Of course, discovering or proving shortly after contract award, by bottom-up, detail planning, that you should not have made all of those un-achievable promises in the tender and in the contract is still a serious problem, but that’s another story.

Rashid,

if you assigned units and activity duration is defined then hours are calculated. You can receive reports on both - hours and units. Maybe I did not understand your question properly?

Then I think we don’t disagree at all.

I don’t mind if someone wants to do Top-Down estimating of anything, Durations, Hours, Costs etc, as long as its limitations are recognised and it is not put to invalid uses such as forcing the whale into the sardine can. It’s not proof of anything such as the outcome of the execution of a plan, so much as a declaration of goals and targets, or more likely just wishes and desires, eg "I want a great big house for a little tiny price and I want it finished before my wife comes back from Europe so we won’t have to live in a hotel" or "I want my nickel mine in production before my nickel refinery runs out of ore and before the world nickel price collapses, so I don’t have to buy ore from Brazil in a rising price market in order that I can cash in on the boom, and I want it for the same price that we agreed on before I added 50000 tonnes of steel scope that my designers forgot about".

In contrast, Bottom-Up estimating is proof, or at least evidence, of such things as how it can be done, how long it takes, and how much it costs to actually build a nickel mine.

I don’t mind quantities based estimating and costing (QBE, QBC) if someone wants to do it. Depends partly on what it is being used to estimate and what it is going to be used for. Especially, the quantities associated with individual detail Tasks can be a reliable basis of the Duration Estimate, though not the only consideration. Thereafter, the Resource assignments, according to the methods, will determine the Hours and hence the Costs as outputs of an integrated Bottom-Up planning process. If these don’t match the quantities based estimates of Hours and Costs according to the rate books and the history data, then the explanantion should be found and the gap closed if possible, but the rates are more likely to be wrong than the integrated plan/programme/schedule.



But this means that there has to be in existence detail Tasks, and the quantities have to be distributed among the Tasks and the WBS, not some other, often unrelated or un-mappable (ie largely because of different levels of detail and inconsistent information about the distribution of quantities), QBS.



The programme, and the best possible WBS and the maximum detail possible at the earliest stages of estimating, must exist first, in order to be the basis of, or to dictate/direct, the QBS. Too often it is done the other way round and/or in isolation and/or separately, and this is where I have a problem with it.



Better to start with the scope and durations (based on quantities, sure) and methods of something feasible, and derive Hours and Costs from that (then see if they match desires and wishes), than to start with Hours and Costs, desires and wishes derived from nowhere really, or even derived from Quantities and rates, and attempt to shoe-horn the scope and Durations to them.



QBE/QBC and Top-Down budgets (Duration, Hours, Cost) as used in early estimating and tendering are notoriously optimistic, take little, if any, account of timing and scheduling, involve big, risky assumptions, under-estimate scope, and they get used for the wrong things at the expense of doing the right things etc etc.



None of which is intended to mean that goals, targets, wishes, desires, budgets, deadlines, optimisation, innovation and tight coordination aren’t all good and useful.