Evolve FM is now Zenith. We’ve brought the product under our company name. Same software, same team — new name as of September 1, 2026.
Book a demo
Zenith · Projects & Shutdowns

The project percentage nobody maintains.

In most project registers the “62% complete” is a number a person typed, and it was true on the day they typed it. In Zenith a project is a window over a list of work orders, and the percentage, the cost, the urgency, the buildings and the forecast are all counted from those jobs at the moment the screen draws. Two things are stored — the budget and the type — because nothing in a maintenance system knows them. Everything else would only be a figure somebody had to remember to update.

Book a demo Where this build stops
Six statuses · Derived progress & cost · Building-grouped schedule · Readiness gate · Bilingual EN / FR
Two stored
The budget and the type. Every other figure on the register is counted from the work orders in scope, so the plan and the actual cannot drift into agreement by accident
Six statuses
Planned, Awaiting Approval, Active, On Hold, Complete, Cancelled — each a place a real project genuinely sits, with guarded transitions between them
Twenty points
How far spending may run ahead of progress before the register says so — while somebody can still act, rather than after the overrun
Zero phases
No work breakdown, no milestones, no dependencies. The schedule groups by building, because that is a fact the jobs already carry
The model

A project holds references, not copies

A shutdown is ordinary work with an extraordinary constraint: it all has to happen inside one window, on equipment that is only down once. The jobs keep their own lifecycles, their own history and their own coding — grouping them must not touch any of that, because in two years the reliability figures read the work orders, not the folder they sat in.

  • The scope is a list of work order references. Nothing is copied into the project, so a job's status, dates and cost stay the job's own.
  • A job may sit in more than one project — a pump that appears in both the pump programme and the reliability push is one job, counted honestly in both windows.
  • Detaching a job does not touch the job. It leaves the folder; it keeps its history, and any other project still claiming it keeps it.
  • A window needs a site. A project with no site is a window on nothing, so it is required and validated against the location tree at creation.
The portfolio

What a register can say without being told

Four cards, eight tabs and a table that sorts itself worst-first. Every column below is a question about the list of jobs, and the register answers it on read rather than asking anyone to keep it current.

Counted, not averaged

The four decisions behind the columns

  • Progress is jobs finished over jobs in scope — counted, not weighted by hours. A weighted figure reads as precision the estimates cannot support, and the unestimated jobs would silently weigh nothing and flatter the total.
  • An empty project is 0%, not 100%. An empty list has finished nothing; calling it complete is the arithmetic being clever at the reader's expense.
  • Urgency is the worst job in it, never an average. Averaging is how a project holding one emergency and nine routine jobs reports as Low — true of the arithmetic, false of the situation.
  • Exposure is the budget of the projects in trouble, not the amount they are over. A project three hundred dollars over on a million is a rounding error; one 20% into its money at 2% complete has the whole budget at stake and has overspent nothing yet.

The table sorts itself: over budget first, then outpacing, then overdue, then by end date. There is no column sort, because the order that matters is not one a reader should have to find.

The signal worth having

“Over budget” is the easy half, and the late half

By the time a project is over, it is already over. The half worth computing is the one before that: a project 18% done that has spent 60% of its money has not overspent anything yet — and is going to.

Spending against progress

A twenty-point gap, at any stage

The test is a percentage-point gap rather than a ratio. Early in a project a ratio is meaningless — one invoice against 2% complete is a thousand per cent and nothing at all — while twenty points means the same thing in week two and week forty.

  • Over — actual cost has passed the budget. Stated plainly, and first in the sort.
  • Outpacing — spend is more than twenty points ahead of progress. This is the one you can still act on.
  • No budget — nothing to compare against. Not “at risk”, and not silently treated as a budget of zero, which would report every unbudgeted project as overspent.
  • Finished work cannot outpace itself — a project that is done and inside its budget is not at risk, however the two curves looked on the way.
  • Jobs that cannot be fully priced are named, never folded in. Labour with no rate and parts with no standard cost are counted as unpriced jobs, not added at whatever the priced part came to.
Three things we did not build

Replaced by the true thing standing closest to it

The design for this page asked for a Gantt of phases, a “3 milestones overdue” alarm and a Risks & Issues register. None of the three exists in the product, and each would have meant a new stored structure somebody has to maintain by hand — which is the exact failure the rest of this module was built to avoid. So each was replaced by something already kept up to date by the work itself.

Phases · a plan structure to maintain

Buildings

The schedule groups by where the work actually is, read from each job's own location — the room's parent building, or the site where a job names no place. It answers what a phase row was drawn to answer: what is happening, where, and when.

grouped from locationId → parent
Milestones overdue · a date nobody updates

Work overdue

The same alarm, and it is real: jobs in the scope already past their own required-by date, counted on the day you are looking. Distinct from the project being late — a window that has not closed yet can be full of jobs that have.

early warning · the end date is the late one
Risks & issues · a register nobody fills in

Holds & delays

A hold is this product's record of a job that has stopped and why, with a reason code from the references register. Open holds only, longest-standing first. It is the issue log, already written, by the people doing the work.

days stopped · reason code · the job it is on

These are not placeholders. They are better than the things they replace for one reason: nobody has to remember to update them. But they are also not phases, milestones and risks, and if your organisation needs those three as first-class records, this module does not have them — see where this build stops.

The schedule tab

A bar prefers what happened to what was planned

Each job's bar starts at when it actually started if it has, and at its scheduled start if it has not; it ends at when it was finished, or at when it is due. A chart drawn from the plan after the work has happened is a picture of an intention, and the two diverge most exactly when somebody most needs to look.

The forecast

The last date in the scope, not a projection

Extrapolating “62% at day 44 of 128” produces a confident date built on a percentage that is itself a count of finished jobs, and it moves by weeks every time one closes. Zenith takes the latest date anything in the scope is due or was finished. When that falls past the project's own end date, the project cannot finish on time by its own plan — a statement that can be checked rather than believed.

  • Slip is counted in days between that date and the project's end date, and is zero when it is not late.
  • An empty scope has no forecast at all — the screen says so rather than printing today's date.
  • The project being overdue is a separate fact — its end date has passed, and it is neither Complete nor Cancelled.
Before the window opens, and after it should have closed

Two gates, and both of them name names

A shutdown is sixteen jobs in a four-day window, and the one without its parts is discovered on day two. Readiness asks the planner's questions before the window opens, while the answers can still change something. Completion asks a different one, and refuses.

Readiness

Five questions, per job, on a date

Every job in the scope is checked against the same five, and the answers partition the scope into done, ready and flagged. Finished jobs are counted as done rather than “ready” — the word would be backwards.

  • Is it authorized? A job still in Draft or Awaiting Approval is flagged, because it cannot be worked when the window opens.
  • Is somebody named? Nobody assigned is a flag, not a refusal.
  • Is it already overdue? Past its own required-by date before the project even starts.
  • Is its date outside the window? Due after the project ends — scope that will not fit.
  • Are parts reserved against it? A flag, not a refusal — plenty of jobs need no parts. It is raised so the planner looks once, on purpose, instead of sixteen times by walking the storeroom on day one.
The lifecycle

Six states, and guarded moves between them

Planned → Awaiting Approval → Active
Active ⇄ On Hold → Complete

A project may go straight from Planned to Active — money that has just been signed off should not have to be walked backwards. A held project restarts. Complete and Cancelled are terminal: there is no reopen in this build.

  • A one-day outage is legal. The date check is “ends before starts”, not “ends after starts”, because an outage that starts and ends on the same date is the ordinary case.
  • Cancel works from anywhere except finished. A project can be abandoned from Planned, from Active or from On Hold, and the date is stamped.
  • Scope can be edited in any live state. Attaching and detaching are not gated on status — the gate is at completion, where it changes something.
The project record

One scope, read twelve ways

The register answers “which of these needs me today”. The record answers the next question, which is “and what is going on inside it”. Every tab below is the same list of work orders asked a different question.

Scope & readiness

Every job in the window with its five answers, partitioned into done, ready and flagged. A job opens in a drawer without leaving the project.

Schedule

Bars per job, grouped by building, a month header and a today line. Each bar declares whether its dates are the plan or what happened.

Costs

Labour and materials summed from the jobs, against the budget, with the remainder as the third wedge and unpriced jobs named separately.

Resources

Who is on it by hours actually booked, overtime separated, cost split within a cent. Assigned-but-not-started reads as pending, never as zero hours.

Parts

What the scope has consumed and what is still held for it, direct purchases marked, matched to stock by the job's own code.

Tasks

Every step across every job, in order. Skipped is counted apart from done, because a skipped step carries a reason somebody had to type.

Holds & delays

Open holds only, longest-standing first, each with a reason code and the job it stopped. Lifted holds are history and stay out of the way.

Activity

One stream out of many work orders, newest first, every entry carrying the job's code — because “isolation completed” without it is a sentence about nothing.

Documents

Gathered from the machines, places, job plans and permit types the scope references — never attached to the project, so a procedure revised this morning is the one you see.

Assets

The machines the project touches and how much open work each is carrying, unioned from the jobs' own asset and covered-asset links.

Vendor visits

Who is coming and to which job. A thin link, and the tab says so — it records that a vendor attended, not what they charged.

Forecast

The last date anything in the scope is due or was finished, against the project's own end date, with the slip in days.

Published, not discovered

Where this build stops

This is the module where the gap between what the category promises and what we have built is widest, so it gets the longest section on the page. Everything above is in the product and demonstrable today. Everything below is not, and we would rather lose the deal here than in month four of an implementation.

The honest headline

This is a portfolio register, not planning software

If you are looking to replace Microsoft Project or Primavera, this is not that, and no amount of roadmap talk will make it that this year. Zenith answers “which of my maintenance projects needs me today, and is any of them spending faster than it is progressing” — from work orders that already exist. It does not build a plan.

  • No work breakdown structure, no phases, no milestones. A project is a flat list of work orders over one window.
  • No dependencies between tasks — a job's steps have a sequence number and nothing else. No predecessor, no lag, no constraint type.
  • No critical path and no float, which follows directly: without dependencies there is nothing to compute them from.
  • No baselines. The start and end dates are the only plan, they are not versioned, and nothing records what they used to be.
  • No earned value. No planned value, no cost or schedule performance index, no estimate at completion. The single spend-against-progress signal on this page is the whole of it.
  • No resource levelling or capacity planning from a project. The resources tab is retrospective — hours already booked. It will not tell you that next week is over-committed.
  • No working calendar. Dates are compared as dates and elapsed time is counted in whole days. Weekends and statutory holidays are invisible to every project figure.
Who this is right for

Maintenance projects, not construction projects

The fit is a maintenance or facilities team running shutdowns, outages, replacement programmes and rolling small works out of the same system that holds the jobs — where the value is that the project's numbers come from the work orders your technicians are already closing, rather than from a second plan somebody keeps in a spreadsheet.

  • Good fit — a four-day shutdown with sixteen jobs, checked for parts and assignment before the plant goes down.
  • Good fit — a year-long replacement programme across several buildings, where the question is whether the money is running ahead of the work.
  • Poor fit — a capital construction project with contractors, draws, submittals and a critical path. That is a different product, and we will say so on the call.
Designed around Shutdown & turnaround planning practice Derived-figure discipline WCAG 2.2 AA en-CA / fr-CA parity
Platform foundations

One fact, one place, every screen

The discipline behind this module is that a rule lives in exactly one function and a fact lives in exactly one record. That is what stops the cost on a project's record quietly disagreeing with the cost on the register two releases after anybody remembers they were computed separately.

Referenced, never retyped

The scope points at work orders, the site at the location tree, the owner at the people register. A project copies nothing, so nothing can go stale inside it.

Priced once

A job's labour cost is computed by the work order module and split here, rather than re-implemented on the project page where the two would drift apart.

Refusals in sentences

Every gate returns typed reasons, and every reason has a sentence in both languages. A blocked screen names the job and the fix.

Accessible to everyone

WCAG 2.2 AA as a build rule: real table semantics, project and bar states announced in words rather than colour alone, and focus that lands where an error refers.

Questions people actually ask

Straight answers, including the unflattering ones

Is this a replacement for Microsoft Project or Primavera?
No. Those tools build a plan: a work breakdown, dependencies, a critical path, baselines and resource levelling. Zenith has none of those. What it has is a register that groups work orders you already have into a window and computes progress, cost, risk and a forecast from them. If your project exists as a plan before the work does, use a planning tool. If your project is a pile of maintenance jobs that need to happen together, this is built for exactly that.
Where does a project's percent complete come from?
Finished jobs divided by jobs in scope, rounded to a whole per cent, computed every time the screen draws. It is not weighted by hours or cost, and it is not typed by anyone. A project with an empty scope is 0%, not 100% — an empty list has finished nothing.
Can I set a budget on a project I create myself?
Not in this build. The new-project form takes a name, a kind, a site and the start and end dates. Budget, type, cost centre, owner and description are real fields on the record and are populated in the demo data, but there is no screen that writes them and no update command — so a project you create has no budget, and the at-risk story does not apply to it. This lands with the project administration screens.
What does “spending ahead of progress” actually mean?
The percentage of the budget spent, minus the percentage of jobs finished. When that gap is more than twenty points and the project is not already over budget, the register calls it outpacing. It is a percentage-point gap rather than a ratio because early in a project a ratio is meaningless — one invoice against 2% complete is a thousand per cent and nothing at all. The tolerance is twenty points for every project; it is not configurable from a screen in this build.
Why does the schedule group by building instead of by phase?
Because a building is a fact the jobs already carry and a phase is a structure somebody has to maintain. Drawing phase rows would mean adding a stored plan that goes stale the first week nobody updates it — which is the failure this whole module is built to avoid. Grouping by the jobs' own locations answers the question a phase row was drawn to answer: what is happening, where, and when. It is a real trade-off and it is the wrong one if your projects genuinely run in phases.
Can a project be closed while its work orders are still open?
No. Completion is refused, and the refusal names every open job. You either finish them or detach them — both honest, in different ways. A project completed over open work is how scope quietly escapes: the jobs stay open, the folder says done, and nobody owns the difference. Complete and Cancelled are terminal in this build — there is no reopen.
Do purchase orders or contractor invoices reach a project's cost?
No. A purchase order in Zenith carries a vendor, a storeroom and its lines — it carries no job and no project, so nothing committed on a PO reaches a project budget. And there is no invoice record in the product at all, so contractor spend never appears in a project total. What the cost tab shows is labour at real rates and materials at standard cost, both summed from lines somebody entered on the jobs. See Vendors & Contractors for exactly what the vendor side does and does not hold.
Is “Awaiting Approval” a real approval workflow?
No, and we would rather say so now. It is a status that a project genuinely sits in — planned, and waiting on money — and it is worth having as its own state because it decides who is chasing it. But there is no approver field, no spending threshold, no delegation, no approval record and no audit entry. Submit for approval and Activate are two buttons, and the same person can press them in sequence.
Can one work order belong to two projects?
Yes, and that is deliberate. A seal water pump job can sit in both the pump programme and the reliability push, because that is true of real work. Detaching it from one project leaves it in the other, and the job itself is untouched either way. The alternative — forcing a job into exactly one folder — makes the register lie about where work belongs.
What happens to a work order when I add it to a project?
Nothing. The project stores its identifier and nothing else; the job keeps its own status, dates, priority, assignment, costing and history. This matters two years later, when the reliability figures read the work orders rather than the folder they sat in. It also means adding a job to a project never changes any number on the work order side.
Who can activate, hold or cancel a project?
Anyone who can open the projects page. There are no project-level permissions in this build — access is granted by section of the site map, not per project or per action, and there is no record of who moved a project between states. If your organisation needs a project manager who can act only on their own projects, that is not in this build.
Does any of this survive a page reload?
Not yet. Every register in the platform is session state until the API and persistence layer land, and projects are no exception — reload and the demo returns to its twelve seeded projects. Everything described on this page is real, tested code with real rules and real refusals; what it does not yet have is a server behind it. We would rather you knew that before the demo than after the contract.
See it with your own shutdown

Bring the project nobody can tell you the real status of.

Bring one window, the jobs that belong in it and the number somebody committed to. We will build the project in front of you, then close a job and watch the percentage, the cost and the risk move on their own — and try to declare it finished while something is still open.

Book a demo See the whole platform
Zenith · Projects & Shutdowns Part of the Zenith maintenance & asset operations platform

Standards and regulators

Standards are named by number, title and scope only. CSA and ULC publications are paywalled — read the standard itself before building a compliance programme on any summary.