The Project Attached to Nothing
A project here can be attached to any other record in the system — the machine being overhauled, the building being fitted out, the contract it delivers. The attachment point exists, the way to read it exists, and nothing in the product has ever filled it in.
Most projects are about something. Not about a customer, though there is usually one, and not about a department, though it owns the work. About a thing: this machine, this building, this vehicle, this contract, this site.
That thing is very often already a record in the same system — an asset with a service history, a property, a piece of equipment with a custodian and a location. The project is the work being done to it.
Here, a project can hold a link to exactly that. The link accepts any kind of record, it is optional by design, and there is a defined way to follow it. It is empty on every project ever created, because nothing in the product ever writes it.
What a project can say about itself today
Quite a lot, and it is worth being fair before naming what is absent. A project has a name and a code, an owner, a department, a customer, dates, a money budget and an hours budget, a cost rate and a bill rate, its own status columns, milestones, and a task tree beneath it. Its actual cost is assembled from four real sources — logged time, purchases, expenses and stock issued to it.
What it cannot say is what it is being done to. The customer field answers who it is for. The department answers who is doing it. Neither answers the question a maintenance manager, a facilities team or a fit-out contractor asks first.
Who it is for, who is doing it, and what it costs. Not what it is about.
The contrast that makes this odd
The product already has this idea and already implements it — one level down. A task can be linked to another record, and that link is real and used: a support ticket becomes a task and the two stay connected, so the work and the request that caused it are one story.
So the mechanism is not missing and the concept is not foreign. It was built where it was needed most urgently, at the task level, and the same attachment on the project was left where it started — declared, waiting, and never wired to a screen.
That is an extremely common shape in software, and it is worth naming because it looks like a decision and is usually an ordering. The task link had a driving use case with somebody asking for it. The project link had a design and no queue behind it.
What it costs in practice
The cost is not in the project. It is in the thing the project was about, and it is paid at the moment somebody looks at that thing later.
- Open the asset and ask what has been done to it. You get its movements, its custody history and its maintenance trips. You do not get the overhaul project that consumed three months and a budget, because the project does not point at it.
- Open the building and ask what the fit-out cost. The costs are all correctly recorded — against the project. Reaching them from the property means knowing which project it was, which means asking somebody who remembers.
- Ask what this machine has cost us over five years. The maintenance trips are on the asset. The project costs are on projects. There is no join, so the answer is assembled by hand or not produced.
In each case nothing is lost and nothing is wrong. The information exists, in full, correctly. It is simply reachable from one direction only, and the direction people ask from is the other one.
Why this shows up sharply in European operations
Because so much project work here is asset work rather than delivery work. Plant overhauls, building refurbishment, equipment replacement programmes, energy retrofits, vehicle conversions — projects whose entire justification is a specific physical thing with a long life and a file.
For a business like that, "what has this asset cost us and what has been done to it" is not a report. It is the central question, asked whenever a replace-or-repair decision comes round, and it is exactly the question a project unattached to its asset cannot help with.
Working round it, and doing it consistently
-
Put the identifier in the project code
Not in the description — the code. A project coded with the asset tag or the property reference is findable by searching for that reference, which is the whole of what the link would have given you.
-
Pick one convention and write it down
The workaround only works if it is uniform. Half your projects carrying the asset tag and half carrying a free-text description is worse than neither, because it produces a search that looks complete and is not.
-
Record the project reference on the asset too
In whatever note field it has. It is duplication, it is the direction people actually ask from, and it takes ten seconds at the point where you already know the answer.
-
Do it at the start, never at the end
The connection between a project and its subject is obvious on day one and archaeological by month six. This is the single highest-value habit on the list.
Three questions for any system running asset-related projects
Can I open an asset and see the projects done to it?
What you will hear
Often a yes about maintenance records.
How to read it
Maintenance records and projects are different things, and the answer usually covers the first. Ask specifically about a project with a budget and a task list, not a service visit.
Can a project be attached to a record rather than described in words?
What you will hear
Varies.
How to read it
This is the question. A text field naming the asset is a convention; a link is a fact. Only the second survives a rename, a typo, or the person who set the convention leaving.
What has this machine cost us in total, including project work?
What you will hear
Two numbers from two places.
How to read it
Ask them to produce it in one view during the demonstration. Almost nobody can, and it is worth knowing that before you build a replace-or-repair process around the assumption.
What AWRA OpsHub does today
- A customer and a department on every project, both real links, driving reporting and access.
- Task-level links to other records, so a support ticket that became work stays connected to the work it became.
- Actual cost assembled from four sources — logged time, purchases, expenses and stock issued to the job — with issued stock costed at the moment of issue so a closed job costs the same twice.
- Money and hours budgets with consumed percentages, so a project reports against both of the things people budget.
- Milestones, a task tree and per-project status columns, so the plan is shaped rather than a flat list.
More we can add to your workspace
- A link from a project to the record it is about — the asset, the property, the vehicle or the contract — filled in from a screen.
- Projects listed on the asset they were done to, which is the direction the question is actually asked from.
- A total cost of ownership view combining maintenance history and project cost for one asset.
- A project raised directly from an asset, carrying the link at the moment it is created rather than needing it added.
Where we point you to a specialist
- A project stays the unit of cost and we would keep it that way. Attaching costs directly to an asset instead would produce a register that is expensive to reconcile and a project view that has lost half its money.
- Whether an overhaul is capitalised into an asset's value or expensed is an accounting judgement for your accountant and your auditor. We would carry the link and the costs; the treatment stays yours.
- We would decline to infer the link from a project name or code. A convention that usually holds is exactly the kind of thing a system should not turn into a fact, because the cases where it fails are invisible.
The project-to-record link, projects shown on the asset, and a total cost of ownership view are one piece of work we can scope and quote on.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe short version
A project that knows its customer, its department, its budget and its costs and does not know what it is about is answering every question except the one an asset-heavy business asks. The attachment point is already there and already readable — it has simply never been connected to a screen, because the same idea was built one level down where somebody was asking for it. If your projects are mostly work done to things you own, check whether you can get from the thing to the work, and not only the other way round.
Try it from the other direction
Pick the most expensive machine or building you own and try to list every project done to it in the last three years. If that takes more than a minute, the connection is living in somebody's memory rather than in your system.
Talk to us about projects and assets