Procore Implementation for a Major Energy Infrastructure Project

How Knight Solutions got AGL's Pottinger project running inside an existing Procore account that wasn't built for it.

A new project that didn't fit AGL's existing Procore account

When you've already got Procore running across the business, there's a fair assumption that a new project just drops into the same setup as everything else. And most of the time, that's pretty much what happens. Pottinger was one of the ones where it didn't.

AGL already had Procore in place, with a Construction Delivery Team and a way of running projects that suited the work that looked alike. Pottinger sat outside that, different project, different team structure, so the setup had to be built to fit it rather than borrowed from what was already there. At the point Knight Solutions came in, the project hadn't been set up in AGL's account yet, and the team was still working through internal access approvals before anyone could even be provisioned.

Knight Solutions was brought in to set Pottinger up inside AGL's existing account and run admin support across the first three months.

Why setting up Procore for this project took more than turning it on

The thing people tend to underestimate is the gap between having Procore and having it set up for the project actually in front of them.

On a mixed-asset project, for instance, you can't just carry over a document naming convention from another job and hope it holds, it has to be worked out for the assets you've actually got, or down the track you're hunting for documents that are technically all there, just filed in three different logics. The Environment team needed recurring action plan templates set up in Procore so the same checks fire on a schedule rather than living in someone's head.

And before any of that, getting people into the system wasn't a quick add. Because the project sat outside the usual structure, it took a comms matrix and individual identity requests, each raised and approved against the Pottinger project team, before anyone could be provisioned. So there was a coordination dependency sitting right in front of the setup work: you're sorting out who's even allowed in before you can properly get the team going.

A decent chunk of this, then, was less about the software and more about the operating setup around it, who gets access, how things are named, what runs on a schedule. That part's not unique to AGL. It just gets more visible on a project that doesn't match the template the rest of the business runs on.

How Knight Solutions configured Procore for Pottinger

The build ran on PM Pro with Document Control, Quality & Safety, Project Financials and Invoice Management, with the recurring action plan templates layered in for the Environment team.

The sequence was deliberate: scoping in early October, a kickoff with the core group late in the month, a dedicated session to work through the action plan templates, then tool induction and rollout in mid-November. The whole thing was scoped to run around twelve weeks, with three months of post-setup support (PAMS) on the back of it and check-ins running through December.

Why we staged the Procore rollout

One thing worth saying, the rollout wasn't a single switch-on. The kickoff was kept to a smaller group rather than getting the whole team in a room on day one, with the wider sessions following once the structure was actually bedded in.

Part of that was practical: training a couple of dedicated Procore champions inside the team so the knowledge didn't all sit with us. And part of it was just that a project like this tends to go better when you let it settle in stages rather than flipping everything on at once.

Pottinger up and running inside AGL's Procore account

By the end of the setup, Pottinger was running inside AGL's account, the modules were configured around the project's own structure rather than the standard one, and the champions were trained so the day-to-day knowledge sat inside the team. The three months of post-setup support ran on from there, with the check-ins keeping things moving while people got used to the tools.

Looking back at it, a fair bit of the work was the operating setup around the software rather than the software itself, the access approvals, the naming, the templates that run on a schedule. On a project that doesn't match the rest of the business, that's usually where the time goes.

When a project doesn't fit your existing Procore setup

If you've got Procore across the business but there's a project that doesn't fit the standard setup, different structure, mixed assets, a team that sits outside the usual delivery model, that's pretty much the situation this was.