What AGL were trying to solve
AGL is an energy business, and inside it sits a construction function that runs major works of its own. That's already a slightly different starting point to a lot of what we see, plenty of the teams we work with are builders or head contractors, whereas AGL sit inside a much larger organisation, commissioning and running their own works.
When the conversation started, they were after a consolidated project management system. A fair bit of their information lived in separate places, site photos, drawings, QA records, surveys, inspections, defects, maps, and none of it really talked to each other. So part of what they were weighing up was whether Procore could pull that together, and whether it was the right fit for the kind of work they do.
Working out what fit, before switching anything on
The first real piece of work wasn't setup. It was working out what AGL actually needed, and being honest about it.
We went through a proper fit assessment, reviewing the product lines against how they work, and lining the proposal up with what genuinely earned a place. A handful of Procore's product lines looked good on paper but weren't going to earn their keep on day one. So instead of switching everything on, we walked through what to set up now and what to treat as future capability, the sort of thing you grow into once the basics are bedded in.
Some product lines earned a place straight away. Others were better left as future capability, turned on when there's a real operational need, not just because they're there.
That restraint matters more on a rollout this size, because every extra tool you switch on is another thing the team has to learn.
Rolling it out across the function
Once the scope was settled, we rolled Procore out across the function using our Launch approach. This wasn't a single team getting set up, it was a detailed, enterprise-wide implementation, with a fair few moving parts.
The core of it was the day-to-day project and document management, quality and safety, project financials, and invoicing, the tools the function would actually live in. We ran it as a managed piece of work, a project manager on our side, an overall Gantt mapping the sequence and timing, synced into Procore so everyone could see where things were up to, and structured check-ins as it went.
There's also the commercial reality of getting something live inside a big organisation, agreements, supplier onboarding, the internal process that comes with an enterprise. It's part of the job, and it's part of why a rollout at this scale takes longer and needs more coordination than a single-team setup.
Pushing document management hard
One part worth calling out on its own: this was the most intensive use of Procore's Document Management we'd ever taken on. AGL's document requirements were serious, and we pushed that side of the product about as hard as we ever have to meet them.
This was the most intensive use of Procore's Document Management we'd ever done.
Adding to it while it was still going
As the implementation was nearing completion, AGL asked us to add scope on top of the original rollout. Some of the original items were no longer needed by that point, and some new support was, so the scope flexed both ways as the picture got clearer. That's normal on a piece this size: you get into the detail and the real priorities sharpen up. Part of that added scope was extending Procore to further parts of the business, and starting the conversation about who was going to keep the account healthy once we'd finished.
Getting it set up is one job. The rollout is another.
Once the setup was finished, AGL asked us to stay on and support the rollout and change management, effectively keeping a hand on their Procore account, managing and refining it based on how it had been configured and the thinking behind it.
This is the part I'd slow down on, because it's where a lot of the real work sits. Setting Procore up is one process. A team actually using it every day is another.
Half the success is the buttons and dials. The other half is people.
You can have a beautifully configured account, and on day one the team is still looking at a list of Procore tool names they've never had to use. Construction makes that harder than most, the office and the site are separate places, sites open and close, people move between jobs. So getting a group genuinely using a system takes more than access.
By this point the environment was a broad one, project and document management, quality and safety, financials, invoicing, and more besides, which is exactly why an experienced hand on the account earns its keep. The more you've turned on, the more there is to keep aligned as the business moves.
Where AGL wanted to take it
Part of what made this one interesting is that AGL weren't only thinking about standard project delivery. They were interested in linking field photos to drawings, QA documents and maps, overlaying design and survey data, and eventually carrying construction records through into how they operate the asset afterwards, with BIM, models, design coordination and aerial imagery in the mix.
Not all of that went live at once, a lot of it was the direction they wanted to grow into, which is exactly why the early restraint on scope mattered. It left room to build toward the ambitious stuff without drowning the team in it on day one.
The shape of it
Looking back, the work came in three connected pieces:
- The enterprise rollout: rolling Procore out across the function, after working out what genuinely fit.
- Added scope: more support layered on as the implementation neared completion, with the scope flexing to match the real priorities.
- Ongoing support: staying on to manage the rollout, the change management, and the account itself once the setup was done.
Each one grew out of the last. It started as one enterprise rollout and turned into an ongoing relationship.
