SmartPM schedule KPIs need calculation lineage

Bind every metric to one schedule version

SmartPM's current official site presents schedule analytics, project workspaces, and a web-based Gantt using historical and projected progress. It also shows indicators such as schedule quality, compression, SPI, predicted completion, and critical-path delay. Those are provider-documented capabilities. They do not establish that a buyer's imported schedule is current, contractually controlling, complete, logically sound, or calculated from the intended version.

For every calculated metric, retain the project, schedule system, native file or extract identifier, file hash where appropriate, schedule version, baseline reference, data date, calendar set, activity and relationship population, time zone, import time, parser version, and any rejected or transformed records. Identify whether the input is the contractor's current update, an owner copy, a recovery scenario, a bid schedule, or another planning artifact. A KPI cannot be reproduced from its displayed value and dashboard date alone.

Publish the calculation contract beside the label

A metric name should resolve to a versioned definition. Record the formula, units, numerator, denominator, qualifying activity population, threshold, weighting, treatment of milestones and summary activities, calendar convention, exclusions, missing-data rule, and rounding. For a grade or composite score, disclose the component measures and combination rule. For SPI, state which planned and earned values are being used and their basis. For compression or critical-path delay, define the compared dates, path, and status assumptions.

Keep a predicted completion date labeled as a model or analytical output with its source schedule, method version, horizon, assumptions, and uncertainty where available. It is not automatically the contractual completion date, approved forecast, delay analysis, or entitlement position. A metric can help a scheduler find a question without deciding causation or required corrective action. Preserve qualified review, override, and annotation rather than allowing one colored status to stand in for the schedule record.

Make recalculation traceable and reversible

When the same project schedule is imported again, identify whether the file is a corrected copy, a later update, a recovery scenario, or a different planning artifact. Preserve the previous import, the new file hash and version, the status date, the parser and metric-method versions, transformation warnings, excluded activities, and the person or process that accepted the replacement. Do not let a reimport silently overwrite the evidence behind a metric already reviewed.

Recalculate against the frozen prior input as well as the replacement. Attribute every changed KPI to a changed activity or relationship, calendar, status date, import treatment, formula, threshold, or method version. If a reviewer accepts an override or annotation, retain its author, rationale, scope, and effective version without altering the underlying computed value. A reproducible replay lets the schedule team explain why one project-level indicator changed.

Demonstrate one metric across three schedule files

A buyer demonstration should import equivalent synthetic schedules from three supported file paths, then vary calendars, status dates, out-of-sequence progress, missing logic, constraints, actual dates, and one corrupted activity. Reproduce one quality metric, one progress metric, one compression or path metric, and the predicted-completion indicator from exports or documented calculation evidence. Inspect parsing exceptions, excluded activities, formula versions, rounding, annotations, approvals, and the history after a corrected file is loaded.

Then correct one file, reimport it under a new version, change one formula threshold, and verify that both the metric delta and the prior calculation remain explainable. Contractor Systems Index reviewed the registered SmartPM URL and its current official destination on September 24, 2026. The page supports the stated inputs, analytics, Gantt, and metric positioning. It does not establish a buyer's schedule authority, data quality, metric formula, calculation accuracy, contractual completion, delay cause, entitlement, performance improvement, outcome, or customer result.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Contractor Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.