Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Hours or Units

7 replies [Last post]
Rashid Iqbal
User offline. Last seen 16 years 51 weeks ago. Offline
Joined: 3 May 2005
Posts: 94
Groups: None
I have always been a fan of entering the resources as units and not in terms of budgeted hours against each activity for the schedules that were to be used for Time management (not for efficiency analysis).
I liked it due to the reason that in Time Management we are interested in deployed resources and not the theoretical hours that need to be spent. Moreover, loading resources as units always allowed me, to produce neat reports showing the ‘number’ required on timescale. As the resources were in units so there was no confusion which otherwise (loaded in hrs) would have been there due to a few activities working 20 hrs while the other 10 hrs. Similarly if the circumstances not allowed me (integrated schedules) to introduce contingency in terms of off days in calendars, I could simply increase the duration and could keep the UPT equal to units deployed.

Now a few days back I saw a requirement of a client to report units and budgeted hours both on timeline for an integrated schedule. Knowing that the contractor have to use predefined calendars and so will not have the privilege to develop contingency incorporated calendars, the first question that came to my mind was as to how to load both units and hrs in activities adjusted for contingencies.

Your comments would be highly appreciated.

Replies

Edgar Ariete
User offline. Last seen 5 years 26 weeks ago. Offline
Joined: 17 Jul 2005
Posts: 184
Trevor,

Top-down, or bottom-up, what’s the big difference? Isn’t it always bottom-less? (otherwise claims consultants will not exist).
Trevor Rabey
User offline. Last seen 1 year 18 weeks ago. Offline
Joined: 29 Nov 2005
Posts: 530
Groups: None
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.
Francis Moyalan, ...
User offline. Last seen 4 years 46 weeks ago. Offline
Joined: 12 Feb 2005
Posts: 105
Groups: None
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
Trevor Rabey
User offline. Last seen 1 year 18 weeks ago. Offline
Joined: 29 Nov 2005
Posts: 530
Groups: None
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?
Trevor Rabey
User offline. Last seen 1 year 18 weeks ago. Offline
Joined: 29 Nov 2005
Posts: 530
Groups: None
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.