Every task gets a Bill of Resources: a header carrying the task quantity and unit, the operations and parameters within it, and the material, labour and machine lines in a hierarchy — each with a quantity per parent, a unit and a rate drawn from the Resource master. Roll it up and you have an estimated task and project cost, sitting directly against budget, before a single hour is booked. It is the project-side analogue of a BOM.
The Bill of Resources sits between the WBS tasks and the project bill. Build it once per task, price it from the Resource master, and it drives the estimate, the procurement and, later, the bill.
A task's resource requirement is planned as a three-level Bill of Resources. The header carries the task's overall quantity and unit. The process layer holds the operations and parameters within the task. And the resource lines are the real material, labour and machine the task consumes, held in a hierarchy of parent and child — each with a resource group, a resource code, a quantity per parent, a unit and a rate. You can even assign a named user to a BOR node, so the effort behind a line is owned by a person, with notes and reference links attached where they help.
Cost estimation rolls every resource line on the BOR — quantity multiplied by rate — up to an estimated cost for the task, and rolls the tasks up to an estimated cost for the whole project. Because each project and task also carries a budget, the estimate lands directly against that budget: over, under, or on the line, before work starts. As material is issued and labour and machine time booked against the task, the actual cost builds up alongside, so estimated-versus-actual is a live comparison, not a year-end surprise.
The BOR cost analysis breaks a task's estimate down by resource, so you see whether it is the plate, the welding hours or the machine time driving the number — not just the total. Turn it the other way and the master, or roll-up, Bill of Resources consolidates the BORs across every task into the total material, labour and machine requirement for the whole project. That one view is the basis for procurement, for resource loading across the plan, and for the project-level cost estimate.
The Bill of Resources is not a planning document that gets filed away. Material is drawn from stock against the task through the shared store engine, labour and machine time are recorded, and the planned BOR becomes real consumption and an actual budget. And because every resource line already carries its group, code, quantity and rate, the same structure feeds the resource-itemised project and milestone bill. Trends and outliers in cost-versus-budget surface through Dhruv AI analytics. It is the same discipline whether you run an engineer-to-order shop or a fabrication job.
A header carrying the task quantity and unit, a process layer of operations and parameters, and the resource lines themselves — one structure per task.
Material, labour and machine lines in a parent/child hierarchy, each with resource group, code, quantity-per-parent, unit and rate.
Quantity times rate rolled up to an estimated cost per task and per project — a number you can quote and plan against.
The estimate compared directly against project and task budget, with actual cost building up from real consumption.
Cost analysis by resource within a task, so you see which material, labour or machine line is driving the estimate.
The task BORs consolidated into the total material, labour and machine requirement for the whole project — the basis for procurement.
Most project cost overruns start with an estimate no one can trace back to resources and rates. New to the idea? Read Bill of Resources and project costing.
A Bill of Resources is the planned list of material, labour and machine a task needs, built as a three-level structure: a header carrying the task quantity and unit, the operations and parameters within the task, and the resource lines themselves in a hierarchy. Each line names its resource group and code, a quantity per parent, a unit and a rate from the Resource master. It is the project-side analogue of a Bill of Materials — a BOM says what a product is made of, a BOR says what a task consumes to get done.
Cost estimation rolls every resource line on a task's BOR (quantity multiplied by rate) up to an estimated task cost, and rolls the tasks up to an estimated project cost. Because each project and task carries a budget, the estimate sits directly against that budget for estimated-versus-actual visibility. As material is issued and labour and machine time consumed against the task, the actual cost builds up alongside the estimate.
The task BOR report shows the resources planned for one task. The master, or roll-up, Bill of Resources consolidates the BORs across every task in a project into one view — the total material, labour and machine requirement for the whole project. It tells a project manager what the project as a whole will consume, which is the basis for procurement, resource loading and the overall cost estimate.
A Bill of Materials describes a standard, repeatable product — the child items and quantity-per at each level. A Bill of Resources describes a one-off task within a project — the material, labour and machine it consumes, each priced from the Resource master. Fast Project Management Software runs on the same platform and resource master as Fast Production, so a shop that also builds to a catalogue BOM shares one resource and material vocabulary across both.
Every resource line on a BOR is priced from the Resource master, where each machine, labour category and tool carries a rate along with its working hours per day, efficiency and unit. Because the rate lives on the resource, the same rate feeds the cost estimate and, later, the resource-itemised project bill — so a rate change flows consistently into costing and billing.
Live demo on your own work — your tasks, your resources, your rates and your budget. Cloud or on-premise, no generic slideshow.
