Multi-discipline design firms, civil and structural engineers, architecture practices. Assumes a time system, an accounting system, and a project management tool that do not fully agree with each other.
Project overrun early warning
In one line: Tells a principal which project is drifting off budget while there is still time to act, instead of at closeout.
Who uses it and when: the principal or project manager, on a Monday, on a list of six projects rather than a report of sixty. It changes one decision: whether to have a conversation with the project manager this week or at closeout.
What it does not do: it will not tell you why the project is bleeding. It tells you which one, early enough to go and find out.
Usually already there.
It runs on data your systems already capture for other reasons: timesheets get entered because payroll depends on them, and the accounting system already holds the budget. What the feature is missing is agreement, not capture. The work is making the project number mean one project in the time system, the accounting system and the PM tool, which is weeks of reconciliation rather than a data programme.
The pain: “I find out a job is underwater when the final invoice does not cover the hours we already spent.”
What it runs on
- One row per: one time entry. One person, one project, one phase, one day. Not weekly totals, not a monthly roll-up.
- Described by: employee, project, client, phase or task, calendar date, office, discipline, billable or non-billable.
- Must agree across systems: project and client. The project number in accounting, in the time system, and in the PM tool must be the same project. The client must be one client, not one row per contracting entity.
- History: you need the history, not just today’s picture. Contract value and budget move as change orders land, and labor rates change every year. Keep every version with the date it took effect.
Why it usually fails: the budget field gets overwritten each time a change order is approved, so by the end of the job the budget always matches the spend and the overrun is mathematically invisible. Second most common cause: phase codes are free text, so “SD,” “Schematic,” and “Schematic Design” are three different phases and no comparison to the estimate is possible.
Fee and effort estimating assistant
In one line: Drafts a fee and hour estimate for a new pursuit from what similar past jobs actually cost, not what they were originally quoted at.
Who uses it and when: whoever is pricing a pursuit when the usual principal is not in the room, at proposal time, on a one-page range of hours and fee by phase instead of a blank spreadsheet. It changes one decision: what number goes in the proposal before it goes out the door.
What it does not do: it will not tell you if the client will pay that number. It tells you what similar jobs actually cost, which is the number to start the conversation from.
Usually needs work.
It depends on time entries and past proposals that are already captured. What breaks it: market sector is free text on the proposal and missing from accounting entirely, so nothing lines up past jobs by type, and only the final fee survives. Nothing new has to be built. One field becomes required in both systems, and the originally proposed fee gets kept alongside the final one instead of being overwritten by it.
The pain: “Every estimate is one principal’s gut feel, and when that principal is on vacation we guess.”
What it runs on
- One row per: one time entry again, rolled up to actual hours and cost by project and phase. The estimate itself is a separate record: one row per proposal version.
- Described by: project type, market sector, client, delivery method, geography, discipline, phase, staff level, year.
- Must agree across systems: project type and discipline. The list of project types on the proposal has to be the same list used in accounting, or there is nothing to match “similar past jobs” against.
- History: you need history on labor rates by year, and you need the originally proposed fee preserved alongside the final fee. A 2021 job priced at 2021 rates is not comparable to today unless both are recorded.
Why it usually fails: the proposal system captures market sector as free text and accounting does not capture it at all, so “find me similar jobs” has nothing to match on. And because only the final fee survives, the system learns that every estimate was correct.
Submittal and RFI response drafting
In one line: Drafts a response to an incoming RFI or submittal review using the right spec section, the code edition that governs that project, and how the same question was answered before.
Who uses it and when: the senior engineer who would otherwise retype the same answer, the moment an RFI lands, on a draft response citing the spec section and the prior answer it is based on. It changes one decision: whether that engineer starts from a blank reply or a checked draft.
What it does not do: it will not confirm which code edition governs the project on its own. It drafts the answer; a person still has to check the edition before it goes out.
Usually needs building.
It depends on knowing which code edition governed a given project, and that is not written down anywhere, only implied by when the project happened. Spec sections are typed by hand too, so “26 05 00” and “Div 26” never match each other in a search. Recording the governing code edition per project is the project. The feature is what happens after it.
The pain: “The same twelve questions come back on every job and a senior engineer retypes the answer every time.”
What it runs on
- One row per: one RFI or submittal item, at one revision. A resubmittal is a new row, not an edit of the old one.
- Described by: project, discipline, spec section, jurisdiction and code edition, responsible party, date received, date answered, status, outcome.
- Must agree across systems: project, spec section, and party. The project list in the construction platform has to reconcile to the project list in accounting, and spec sections need one consistent format.
- History: you need the history. A project permitted under an older code edition must be answered against that edition, not the current one. Which edition governed which project, and from when, has to be recorded.
Why it usually fails: spec sections are typed by hand, so “26 05 00,” “260500,” and “Div 26” are three separate things. Nothing anywhere records which code edition governed the project, so the assistant confidently answers against the wrong standard, which is worse than not answering.