How to Report Commissioning Issues So People Act on Them

Every commissioning project runs on its issues log. When the Cx team finds something wrong, like a damper that doesn't close on alarm or a chiller that won't stage on at setpoint, it goes in the log. The issue gets a priority, gets assigned to whoever owns the fix, and stays open until someone verifies it's resolved.

Most teams are pretty good at finding issues. Where things fall apart is what happens next. The log grows, the weekly report turns into a 40-page export, and by the time anyone notices that one contractor has been sitting on 19 open issues for a month, it's a schedule problem instead of a phone call.

Below: what makes an issue report useful, when to communicate about issues (and when not to), and how to spot trends early. At the end there's a free spreadsheet template for reporting.

Start with issues that are worth reporting on

You can't get good reporting out of a messy log. Before worrying about charts, make sure each issue has what it needs.

One problem per issue. "CRAH-104 has multiple deficiencies" is three issues pretending to be one. It can't be assigned cleanly, and it can't be closed until all three are fixed. Split them up.

Enough detail for someone who wasn't there. The equipment tag, the location, what was observed, and what was expected. "Supply air temp sensor reading 3°F high compared to calibrated reference" gets fixed. "Sensor issue" gets a phone call asking what you meant.

One responsible party. Not "Mechanical/Controls." If you don't know who owns it yet, that's worth its own conversation. Issues with two owners tend to have zero.

A priority that means something. If every issue is High, none of them are. The best fix I've seen is tying each priority level to a target number of days to close. A critical issue might get 3 days, a low one 30. Now the priority is a commitment you can measure against.

Real dates. Date opened and date closed. By date closed, I mean the actual date the issue was closed, not the date it was "closed" in the system. Without both, you can't measure how long anything takes, and most of the useful analysis goes out the window.

Statuses with clear meanings. Everyone on the team should know what "Ready for Verification" means and who acts next. It also helps to have a status for voided or duplicate issues, so they stop inflating your counts.

When to communicate (and when the log isn't enough)

An issues log is a record, not a notification system. Putting something in the log doesn't mean anyone read it. Match the channel to the urgency.

Right away, directly, in person or on the phone:

• Anything involving life safety or risk of equipment damage
• Anything blocking a scheduled test, especially one with the owner or a vendor rep on site
• Anything that puts a critical path activity at risk
• Anything that will cost real money if it isn't caught before the next trade covers it up

Log these too, but don't wait for the weekly meeting to bring them up.

Weekly: the regular status report. This is where the charts below earn their keep. Show the shape of things (what's open, who owns it, and whether the backlog is growing or shrinking) rather than walking through every open issue. Then spend the meeting time on the handful of issues that need a decision.

At milestones: before starting functional testing, before integrated systems testing, and before turnover. Ask one question: what's still open that should block us from moving forward? Walking into functional testing with 60 open installation issues usually means you'll be retesting.

Whenever a trend shows up: the moment you notice a pattern, not when the next report is due. More on that next.

How to spot trends before they become problems

Individual issues are the work. Trends are where the real risk is.

The backlog stops shrinking. Plot issues opened and closed each week, along with the total still open. Early in functional testing it's normal for the open count to climb, since you're finding things faster than people can fix them. But if it's still climbing three weeks before turnover, you have a closeout problem. This is the single most useful chart in commissioning.

Old issues pile up. Group open issues by age: under a week, one to two weeks, two weeks to a month, one to two months, and older. Anything past 30 days is almost always stuck on something: a submittal, a vendor visit, a design question nobody has answered. Those issues need an owner and a date, not another week in the log.

One party's share keeps growing. Every contractor will have issues. That's what commissioning is for. What matters is whether they're closing them. A contractor with 33 issues and 4 open is doing their job. A contractor with 32 issues and 19 open is where your schedule risk lives. Look at open and closed together so the conversation stays fair.

The same issue keeps showing up on the same equipment. This one is especially valuable on data center projects, where you might have 40 identical CRAH units or dozens of PDUs. If the same defect shows up on the first five units, you have one systemic issue, probably in the submittal, the factory, or the installation detail, and it's about to become 40. Catch it early and it gets fixed once.

Installation problems during functional testing. Break issues down by the commissioning level where they were found. Some installation issues showing up during functional testing is normal. A lot of them usually means the installation checks weren't really done, and functional testing is now doing double duty.

Priorities that don't move faster. Compare the average days to close for each priority against its target. If critical issues take about as long as low ones, the priority field isn't changing anyone's behavior.

Issues waiting on the Cx team. If a lot of issues are sitting in "Ready for Verification," the bottleneck might be you. It's a good reason to schedule a verification sweep.

Small numbers lie. A party with one closed issue that took 20 days isn't necessarily slow. And a contractor with a big scope will have more issues than one with a small scope. Look at rates and trends over time, not just raw counts.

Six charts that answer these questions

You don't need special software for any of this. Six charts cover most of it:

1. Open issues by priority. How much of what's open is actually critical.
2. Open issues by system, largest first. Where the problems are concentrated.
3. Open vs. closed by responsible party. Who owns the open work, and who's closing things.
4. Open issue aging by priority. What's stuck, and how important it is.
5. Opened vs. closed by week, with the open backlog. Whether you're winning.
6. Average days to close vs. target, by priority. Whether priorities mean anything.

Put those at the top of your weekly report and you'll spend less time presenting the list and more time making decisions.

Get the free template

We built a free issues reporting template that does all of this with plain spreadsheet formulas. No scripts, no add-ins, no account. It works in Excel or Google Sheets.

What's in it:

• An issues log with the columns you need: dates, system, equipment type and tag, issue type, priority, responsible party, status, and Cx level. Days open, aging, and past-target flags are calculated for you.
• A setup page that builds itself. Paste in your data and every status, priority, system, and party shows up automatically. You mark which statuses count as open, closed, or ignored, and set a target number of days for each priority. That's the only setup.
• A dashboard with all six charts above.
• A deep dive page where you can filter by priority, system, equipment type, issue type, Cx level, and date range, and see who has the largest share of issues, who's slowest to close them, who has the most past target, and where each party's issues are concentrated.
• A data check that flags missing or text dates, closed issues without a close date, and issues with no owner, plus a reconciliation that shows exactly where every row went.

It comes loaded with 150 sample data center issues so you can see everything working before you touch it. When you're ready, clear the sample data, paste in an export from your Cx platform, and the charts build themselves. It's set to handle up to 5000 issues as well. If you need more lines, copy the formulas to the extra rows.

Download the template

Most of the trends in this article can be spotted in a spreadsheet if you know where to look, and this template will get you further than most projects go. But your issues data holds more than that. The harder patterns, like the same defect creeping across 40 identical units, a slow slide in one contractor's close rate, or installation issues still surfacing during functional testing, take more than a spreadsheet to catch early. That's what we're building CxLens to surface. If that sounds useful, we'd love to talk.