Bill of Resources (BOR) explained — the project-side BOM

What a Bill of Resources actually is

A Bill of Resources (BOR) is the per-task plan of everything a project task will consume to be completed — the material it eats, the labour it needs, and the machines and tools it runs — with a quantity and a rate against every line. Where a project is broken into a Work Breakdown Structure of tasks, the BOR is what sits underneath each task and answers the question a costing team actually lives with: what will this piece of work take, and what will it cost?

It is the project-side analogue of a Bill of Materials, but broader and built for one-off work. A repetitive factory can lean on a fixed BOM and routing that rarely change. A project is bespoke by definition, so its resource plan has to be authored explicitly, task by task, from a shared resource master of priced machines, labour categories and tools. Get that plan right and the whole project is costable, schedulable and billable; skip it and the project exists only as a quotation and a hope.

BOR vs BOM — the difference that matters

The two are cousins, and confusing them is the single most common mistake when a manufacturer first tries to run projects. A BOM is a product structure; a BOR is a work structure. The table below lays the difference out.

The practical consequence is huge. A machine or a crane is invisible to a BOM — it is not part of the product — but it is often the biggest line in a BOR. If your estimate ignores the machine-hours and the labour a task consumes, it is not an estimate at all; it is a materials list with a margin bolted on. The BOR exists precisely so that the people and the plant are costed alongside the steel. For the broader picture of where this fits, see the pillar guide on what project management software is.

The header, process and resource structure

A serious BOR is not a flat list; it is a three-level structure, because real work has operations inside it and resources inside those. Each task carries its own BOR built from three tiers.

The resource level is the heart of it. Every line names a resource group and a resource, carries a quantity per parent and a rate, and sits in a parent-child tree so a sub-assembly’s resources roll up into the assembly above it. Because each resource line is drawn from the shared resource master, its rate, working hours and efficiency are held once and reused everywhere — change a labour rate in the master and every open BOR that uses it can be re-costed, rather than editing dozens of spreadsheets. You can also assign a named user to a BOR node, so effort and cost are owned by a person, not left anonymous.

How a BOR becomes a cost

Because every resource line is priced, the BOR is not merely a plan — it is a cost waiting to be totalled. Cost estimation multiplies each line’s quantity by its rate, rolls those up to a task cost, and rolls the tasks up to an estimated project cost that can be compared to the project budget before a single hour is booked. A BOR-cost breakdown then shows where the money sits — which resource, which task — so an expensive task is visible in the plan rather than discovered in the accounts.

The same structure carries the estimate through execution. As real material is issued and real labour and machine time are booked against the task, the planned BOR becomes actual consumption, and estimated-versus-actual stays live. That is the subject of two sibling guides: project cost estimation for building the estimate, and budget vs actual tracking for watching it hold.

A worked fabrication example

Take a fabrication shop building a bespoke skid package to a customer’s drawings. The order is opened as a project and broken into a WBS: design, cutting, welding, assembly, testing and dispatch. The welding task gets its own BOR.

• Header — the welding task covers 12 fabricated joints on 4 skid frames; that quantity and unit anchor the BOR.
• Process — within it, MIG welding and grinding are the operations, each with a parameter quantity (weld length, passes) that drives consumption.
• Resource — material — welding wire and gas from the item master, each at a quantity and an INR rate.
• Resource — labour — welder and helper man-hours, priced by their rate in the resource master.
• Resource — machine — the welding set and grinder machine-hours, each with its own rate.

Multiply each line out, add them up, and the welding task has a cost. Do the same for cutting, assembly and testing, roll the tasks up, and the shop has an estimated project cost for the skid package — in rupees, checkable against the budget it quoted — before a plate is cut. Because it all rides one engine keyed to the project and task, the estimate, the material issued during the job, and the milestone bill raised at the end all trace back to the same BOR lines. Indicative INR figures are exactly that; confirm rates with your own costing team and your CA.

Why generic project tools do not have one

Most well-known project apps are descended from software task lists. They can schedule tasks and show a Gantt, but they have no concept of a resource master with rates, no material lines, and no way to roll a task’s consumption up to a cost — because they were never built to run a shop floor. A BOR needs three things a generic tool lacks: a priced resource pool, a per-task consumption plan, and a link to real inventory so the plan can become actual cost. That is why a Bill of Resources is a genuine differentiator, not a checkbox: it is the feature that separates project software built for people who build things from a to-do app with a timeline view.

It is also the bridge between the two halves of a project business. Scheduling says when a task runs; the BOR says what it takes and what it costs; and procurement and stores turn that plan into real material issued against the task. Without the BOR in the middle, those two halves never meet.

How Fast Project Software implements the BOR

Fast Project Software, built by Improsys in Pune on the shared Fast Suite platform, implements the Bill of Resources exactly as described — a per-task header, process and resource structure, with resource lines drawn from a priced resource master and arranged in a parent-child hierarchy.

The result is that a project’s plan, cost and bill are one connected chain rather than three disconnected spreadsheets — as proven in live deployments serving engineer-to-order manufacturers and fabrication and job-work shops. Pricing is indicative and in INR; see pricing.

Frequently asked questions