Its code and its status
Title, own code and progress status. This is what lets you talk about the project without listing its work orders.
Feature
Refurbishing a facility, commissioning a new site or running a replacement campaign isn’t recurring maintenance. It has a start, an end and its own budget, and it gets managed badly when it’s lumped in with the day-to-day list.
It’s a set of jobs grouped together because they share a goal, a budget and a deadline, rather than because they fall on the same asset. Replacing the lighting in twenty stores, adapting a facility to a new regulation, or commissioning a plant are all projects: while they last, they coexist with routine maintenance, compete for the same technicians, and need their own cost control. Dropping them into the day-to-day work order queue has two effects, both bad: the project gets diluted, and the cost of recurring maintenance stops being comparable across periods.
The work still gets done. What’s lost is control.
A project is a container with its own status, cost and traceability.
Title, own code and progress status. This is what lets you talk about the project without listing its work orders.
Each job is booked to the project as well as to its asset, so day-to-day work and the project don’t get mixed up in reports.
Hours, materials and travel from all its work orders added up. The figure you need to know whether the project is going well or badly.
With its own billing client when it doesn’t match the facility’s owner, which is more common in groups than it looks.
Drawings, reports, certificates and minutes attached to the project, not scattered across the work orders.
With its external reference and closing date, so cost accounting lines up without manual work.
They don’t compete, they do different things. A project is a cost umbrella: it groups work that can span several sites and several months, and lets you aggregate spend and billing under one code. A works job is a period of work at a single site, with a start and end date, that also automatically generates the daily timesheet for each assigned worker while it lasts. The practical rule: if what you need is to add up cost under one reference, it’s a project; if you also need a team to log its work every day for weeks, it’s a works job. And a works job can belong to a project.
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
The question at the end of any project — did we make money on this? — gets answered badly at most companies, and not for lack of accounting but because the hours and materials it consumed got spread out along the way without ever being tied back to it. One technician spent three days, another spent a morning, some material was bought and went through general stock, and someone made two trips. None of those four things is hard to log; the hard part is reconstructing them afterwards. When the project is the unit work orders get booked to, the real cost shows up on its own, and with it the comparison against the estimate. And that comparison is worth more than it looks: repeated across five or six projects, it shows whether the problem is in execution or in how work gets quoted, which are two very different conversations that tend to get confused as one.
Not everything that isn’t preventive or corrective is a works job. There’s a middle category that has no home in many operations and ends up disrupting the rest: the improvement you decide to make, the planned replacement of a set of equipment, adapting a site, an extraordinary inspection campaign for a family of assets. If that work gets dropped into the normal work order flow, it pollutes maintenance indicators and makes the month’s figures impossible to compare with the previous one. Treating it as a project isolates it: it has its own dates, work orders, hours and cost, and ordinary maintenance keeps being measured against itself. It’s an administrative distinction that looks minor and is the difference between reports you can read and reports you have to explain every time.
Yes, with the usual caveat about scope: it lets you organize and assign field work, generate timesheets for workers between given dates, and track hours and materials booked. What it doesn’t handle are bid items, measurements or certifications, so the works job’s financial planning will keep living wherever it lives today.
Yes, because what’s left is simply the work not yet executed within the scope. It’s direct information, not a progress estimate: how many work orders were generated, how many are closed and how many are still pending, with their hours booked to date.
The scope. A project groups work that can span several sites and several months, and lets you aggregate cost and billing. A works job happens at one site, has a start and end date, and usually comes from an accepted quote. A works job can belong to a project.
They can be separated out. Each work order is booked to its project as well as to its asset, so reports let you look at recurring maintenance without a large project distorting the period.
Yes. The project accepts its own billing client, which is a common case in corporate groups and in works jobs for developers.
Yes, with its external reference and closing date, so cost accounting lines up without redoing the allocation by hand.
In the demo we set it up and see how its cost would look separated from day-to-day maintenance.
Accessibility
Saved in this browser. Light or dark theme is set from the footer.