Project Controls Software Problems: The 7 That Wreck the Monthly Close, and How to Avoid Them

Why does a project controls build turn into an ERP (Enterprise Resource Planning) replacement?

The scope creep here is polite and reasonable at every individual step, which is why it succeeds so often. Somebody points out that the accounting system cannot hold installed quantities, so quantities move into the new system. Then the new system needs to price them, so unit rates arrive. Then rates need cost types, so a chart of accounts appears. Meanwhile the schedule export is missing a field, so somebody proposes holding activities natively. Six months later you are building a scheduler and a ledger, badly, and the earned value engine that justified the project is still a wireframe.

This is specific to project controls because the function genuinely sits between two systems and touches both. Nobody proposes replacing accounting on day one. They propose one field at a time.

The discipline that holds is a written boundary agreed before kickoff. The controls system reads actuals, commitments and the chart of accounts from the accounting platform. It reads activities, dates and progress structure from the scheduler. It owns four things and only four things: the mapping between your cost breakdown structure and the client work breakdown structure, the progress measurement rules, the forecast workflow, and the reporting. Anything proposed outside that list gets written on a separate page and revisited after the first release ships. Nobody needs a custom scheduler, and a controls team that builds one has spent its budget on the part the market already solved.

What goes wrong when historical cost and progress data comes across?

The migration problem in controls is not volume. It is that the rules which produced the historical numbers were never written down.

You will find, on inspection, that the March position was computed with an indirect allocation basis that changed in May and nobody restated. That two disciplines credit units complete but one of them counts surveyed quantities and the other counts batch tickets, and the difference has never been reconciled. That a control account was split in month seven and the earlier costs were journalled across in a lump with no detail. That the mapping worksheet has three tabs and the live one is not the first.

The failure mode is a migration that loads all of it faithfully and produces a system whose historical trend line is a blend of three different methodologies. Every performance factor computed from it is then a fiction, and the forecast built on those factors is worse than no forecast, because it carries authority.

The fix is to migrate less and label it honestly. Bring across the current position on live jobs with full detail, bring earlier periods across as sealed period snapshots that are readable but explicitly not recomputed, and record against each historical period which methodology produced it. Then a trend line that crosses a methodology change is visibly marked rather than silently smoothed. Expect the discovery work here to take real time with your cost engineers, because you are documenting practice that has only ever existed as practice.

Why do the Primavera and ERP integrations break after launch?

Both connections work in testing and both degrade in service, for different reasons.

On the schedule side, the break is restatusing and rebaselining. Reading an export once is easy. Maintaining a relationship with a live schedule that gets restatused weekly, rebaselined at a change order, and occasionally rebuilt by a planner who renumbered activities is not. When activity identifiers change, your links to control accounts break quietly and progress stops flowing for whichever discipline was affected. You find out at close.

On the finance side, the break is the chart of accounts. A new cost type gets created for a job, or a joint venture posts to a parallel structure, or a supplier account is recoded, and costs land outside your mapping. Because unmapped cost is a small number at first, nobody notices until it is not small.

The controls-specific fix is to treat unmapped and unlinked items as first class monitored objects rather than as errors to suppress. Unmapped cost gets a value and an owner and appears on the close checklist. Broken schedule links raise before the close, not during it. And any reconciliation should tie totals both ways: the sum of everything mapped plus everything unmapped must equal the source total, every period, or the sync fails loudly. A silent partial load is the failure that ruins trust in a controls system permanently.

What happens when rules of credit and accrual policy are not covered?

These two gaps produce the same symptom, which is a monthly meeting spent arguing about whether the numbers are real rather than about what to do.

Rules of credit are contractual, and contracts are specific. One client caps earnable progress on procurement until vendor data is accepted. Another credits concrete by cubic metre placed against surveyed quantity rather than batch tickets. Engineering deliverables carry weighted steps the client defined. A build that offers a fixed menu of standard progress methods and no way to express a contractual wrinkle sends the wrinkle straight back to a spreadsheet, and once one discipline is outside the system the close is manual again.

Accrual policy is the quieter gap and the more damaging. Supplier invoices arrive weeks after material is received, subcontractor applications lag the work, plant hire bills monthly in arrears. Report actuals as the ledger sees them and cost performance looks excellent for the first months of every job and then falls over, and nobody can separate a real problem from accruals catching up.

The fix in both cases is the same shape. Make rules of credit a configurable object per control account, with the specific quantity source named, so the earned number is computed the way the contract says. Carry commitment, goods receipt, accrual and actual as distinct states of the same cost, with an accrual policy per cost type, so incurred cost at cut off is computed rather than assumed. Neither is glamorous. Both decide whether the performance indices mean anything.

Should you build custom or configure what you already own?

A real share of readers should configure rather than build, and it is worth being direct about who.

If you have one dominant client, one mandated reporting format and a stable cost breakdown structure, buy. Hexagon EcoSys is a capable configurable platform, ARES PRISM has deep earned value heritage, and InEight covers a broad estimating through execution stack. Any of them will fit that profile and a build would be spending money to reproduce work already done well. Equally, on a single lump sum job under roughly $30 million where your cost codes and the schedule already agree and the client accepts your standard report, a well built spreadsheet is proportionate and honest.

Before building, also check whether Primavera P6 is being blamed for something it was never meant to do. P6 is a strong scheduling engine and a weak cost system, and resource loading it is a pattern that is maintained enthusiastically for two months and abandoned by month four. That is not a P6 problem. Keep it as the schedule source and stop asking it to be the earned value engine.

The build case appears when variety is the problem. Lump sum work for one client, reimbursable work for another and a publicly funded job under a mandated reporting standard means three sets of rules of credit, three cost to complete methodologies and three report formats at once. At that point configuration effort plus licences plus an implementation partner frequently exceeds a build that encodes only what your contracts actually say.

How do hidden costs get into the quote?

Five omissions show up in this category with enough regularity to name.

Discovery of your own rules. Rules of credit, indirect allocation basis and accrual policy usually exist as practice rather than documentation, and writing them down takes weeks of your cost engineers' time. It is the largest single schedule risk in a controls build and it is frequently quoted as a workshop.

Client reporting standards. Each distinct mandated format is a separate output with its own validation, and any formal earned value management system compliance regime brings documentation and surveillance obligations alongside the software.

Schedule integration depth. Reading an export is a fraction of the cost of maintaining a live relationship with a restatused and rebaselined schedule. Quotes routinely say schedule integration without saying which.

Joint venture and multi currency handling. Two parents wanting the same job presented in two chart of accounts structures, or escalation on international work, are architecture decisions rather than features, and retrofitting them is expensive.

Running costs. Budget 15 to 20 per cent of build cost annually for hosting, support and change, because scheduler versions and finance system upgrades will move under you.

What separates a build that works from one that fails here?

Four things, and the first is a personnel decision rather than a software one.

The cost engineer who currently owns the mapping worksheet has to be released from part of their day job for the duration. Not consulted, released. Every rule the system needs lives in that person's head, and a build that gathers it in a fortnightly review meeting will encode an approximation.

Second, effective dating everywhere. Mappings, rules of credit, allocation bases and forecasts all change during a job, and every one of them must be a versioned object with a date rather than a value that gets overwritten. This is the single design decision that lets the system reproduce last April's report exactly, which is what makes it useful when a claim is being prepared.

Third, start with two live jobs rather than the portfolio. The two largest active ones give you the full range of problems without the coordination cost of a fleet rollout, and they give you a real close to test against within the first quarter.

Fourth, run the new close in parallel with the spreadsheet for at least three periods, and reconcile every line before anybody stands the old process down. If the two disagree, that is information, and finding it in parallel is cheap. Finding it in a report already issued to a client is not.