Choosing Project Controls Software: A Practical Demo Checklist

Start with a decision your team needs to make

A project controls software demonstration should answer a real question: can the team find the current information, explain what changed, and record a decision that another person can follow? An attractive dashboard is only one part of that test.

I’m Ryan Lippmann, a construction project manager and the founder of TuneView. My construction background and software work inform the questions below. This is a way to evaluate a tool against your own workflow; it is not a ranking of vendors or a claim that one product suits every project.

Start by choosing one recurring task. It might be updating a completion forecast, reviewing a potential change, or preparing an owner report. Write down who supplies the information, who checks it, and who needs to act on it. Use that task throughout the demonstration.

Bring a small, representative set of records

Use an anonymized sample that includes a schedule update, a cost report, and an unresolved change. Keep the reporting dates visible. Include one incomplete record so you can see how the system handles uncertainty.

Ask the demonstrator to load your sample rather than relying only on a prepared dashboard. Check whether activities, cost categories, and change identifiers stay recognizable after import. Where a mapping is required, record who will maintain it when a new phase or subcontractor is added.

The useful output is a short list of transformations: which fields were renamed, which records were excluded, and which totals need reconciliation. A successful import message does not answer those questions.

Test one change from entry to forecast

Here is an illustrative test: an equipment selection is unresolved, its release date affects a later installation activity, and the cost proposal is still being reviewed. These are sample conditions, not an account of a particular project.

Enter the issue and check whether the tool keeps potential cost separate from approved cost. Follow the link to the affected schedule activity. Then update the decision date and inspect what changes in the forecast.

Ask for the previous value, the person who changed it, the time of the change, and the supporting record. Check whether a reviewer can reproduce the report as it stood before the update. A history of edits is useful only if the team can find and interpret it.

Try the field and owner views

Have the person who will supply field updates try the entry process. Can they identify the right activity, attach a record, and explain a constraint without duplicating information in several places? Count the steps that would recur every reporting cycle.

Next, have a reviewer use the report to answer three questions: what changed, what needs a decision, and when is that decision needed? Check whether the report shows its reporting date and identifies missing information. An empty field should not quietly become a reassuring zero.

Test permissions with sample accounts. Confirm which roles can edit forecasts, approve changes, and issue a report, and whether the record distinguishes those actions.

Take the information back out

Export the sample records and the issued report before ending the demonstration. Check the files with the tools your team already uses. Confirm that identifiers, dates, notes, and links to supporting records remain usable.

Ask how attachments and revision history can be retrieved when a project closes or the service changes. Record any manual work needed to assemble a complete handover. A readable PDF report and a usable data export answer different needs; inspect both.

Use a short evaluation record

For each requirement, record the task tested, the observed result, any workaround, the person who will maintain it, and the remaining question. Use “demonstrated,” “requires setup,” and “not demonstrated” rather than treating a presentation as proof.

Finish with a pilot on one reporting cycle before expanding the process. Compare the effort to prepare the report and the decisions it supports with the current method. Keep the original records available while checking the result.

For the operating process behind the software, see A Weekly Project Controls Review and What Project Controls Really Do. The tool should support a process that the team understands and can maintain.