Skip to content
advisory Project management and town planning consultancy

How a project management and town planning consultancy got a board-ready AI roadmap and the data foundation to act on it in four weeks

4 weeks

Last updated:

Key results

  • 16 projects across 4 priority tiers
  • 5–10 hrs/week unlocked for the full team once foundation is complete
  • 3 owned deliverables: roadmap, governance analysis, board presentation

Outcomes

Efficiency gain
5-10 hrs/week identified for full team recovery once foundation data projects complete; manual reporting and document search burden quantified across delivery team
EBITDA impact
Foundation investment unlocks compounding time recovery across ~30 staff; POC and internal champion training already proceeding
IP operationalised
SharePoint architecture, contact and project master data standards, and Aconex retention framework owned independently; governance and defensibility rubric delivered for ongoing use

Tags

AI transformation roadmap Project management AI Copilot adoption Data governance SharePoint Town planning technology

Without deploying Copilot onto fragmented data, without treating AI as the first step, and without blocking quick wins behind a multi-month prerequisite.

4 weeks · 16 projects across 4 priority tiers · 5-10 hrs/week unlocked for the full team once foundation is complete · 3 owned deliverables: roadmap, governance analysis, board presentation

The bridge. Leadership came in wanting to deploy Copilot and get the team using AI. Four weeks later they understood exactly why that deployment would have failed. They had a sequenced plan that put the data foundation first and the AI adoption second. That shift is the work.

The client is a project management and town planning consultancy of approximately 30 people, based in Australia. The practice spans infrastructure delivery, development approval, and strategic advisory across multiple states, with deep project data accumulated over years of delivery work. The team was familiar with AI tooling and keen to move, but faced a barrier that wasn’t immediately visible: the data landscape underpinning their Microsoft 365 environment was too fragmented to support meaningful AI adoption.

Contacts lived in multiple systems without a canonical source. Project records were held across SharePoint, a legacy platform, and external project management tools with no consistent structure between them. Document libraries had grown organically rather than by design. Staff were searching across four or more locations to find project history, precedent decisions, and regulatory guidance.

The question they brought to SeidrLab was: “We have Copilot licences and we know AI can help us. Where do we start?”

The answer pointed somewhere else.


How we mapped 16 projects across a fragmented data and systems landscape

We ran structured discovery workshops with leadership and the delivery team, following actual workflows rather than org chart assumptions. For each process, we mapped what triggered it, which systems it touched, where it broke down, and how long each step actually took. For a team working across complex, long-horizon projects, the accumulation of small inefficiencies was significant.

The workshops surfaced four categories of opportunity. Tier 1 covered the foundation work: SharePoint architecture and information management, a unified contact and project master data standard, and a structured Aconex document retention framework. These were not AI projects. They were the data hygiene and structure work that any AI system would depend on. Tier 2 covered Copilot deployment and AI-assisted workflows: report drafting, document search, meeting intelligence, and precedent research. Tiers 3 and 4 covered deeper automation and AI-assisted analysis that would build on the foundation investment over time.

The finding that changed the shape of the engagement: without the foundation tier in place, deploying Copilot would produce inconsistent, unreliable outputs. AI amplifies what is already there. If the underlying data is fragmented and inconsistent, Copilot surfaces that fragmentation faster than it would ever surface useful content.

Key takeaway. The most valuable thing an AI roadmap can tell an organisation is what not to deploy yet, and why.


How we identified the data consolidation problem blocking all AI adoption

This was the discovery the workshops were designed to surface.

The client’s Microsoft 365 environment included Copilot licences that had not been deployed. The reason was instinctive rather than diagnosed: teams had tried using AI assistants and found the outputs unreliable. The diagnosis, when mapped properly, was straightforward: Copilot’s outputs were only as reliable as the documents it was trained on, and the document landscape had no consistent structure, naming convention, or access architecture. Different teams had organised their SharePoint libraries differently. Project folders contained documents with inconsistent naming and no standard versioning. The legacy platform held project data that hadn’t been migrated to SharePoint and wasn’t accessible to Copilot at all.

The roadmap made this concrete. Before Copilot deployment could produce reliable outputs, three things needed to be in place: a SharePoint information architecture that reflected how the team actually navigated project data, a contact and project master data standard that gave every record a canonical home, and a decision about which legacy data was worth migrating and which could be archived. None of these were AI decisions. All of them were prerequisites for AI to work.

Key takeaway. A Copilot deployment onto inconsistent data does not produce AI-powered work. It produces faster access to the same inconsistency. The data foundation is not the slow path to AI adoption. It is the only path.


How we sequenced foundation work before AI deployment

We scored every project on impact and feasibility and structured the output as a four-tier sequenced portfolio. Tier 1 (foundation) projects were framed not as prerequisites to endure but as capability investments in their own right: SharePoint architecture improvements would recover time immediately through better document findability, regardless of what came after them.

The sequencing logic was explicit: begin Tier 1 foundation projects in parallel with governance, start the Copilot deployment pilot once the SharePoint architecture was stable, then expand AI-assisted workflows as reliability improved. Projects in Tiers 3 and 4 were documented in full but explicitly deferred until the foundation and initial Copilot deployment had demonstrated consistent results.

The roadmap identified the five highest-priority projects for the first funding decision:

ProjectIdentified impact
SharePoint Information ArchitectureImmediate document findability improvement; prerequisite for reliable Copilot outputs
Contact and Project Master DataEliminates duplicates and inconsistencies across 4+ systems; prerequisite for CRM and AI use
Aconex Document Retention FrameworkCompliance and archive structure; makes Aconex data available for project intelligence
Copilot Deployment and Training (Pilot)AI-assisted report drafting, document search, and meeting intelligence for pilot team
Internal AI Champion ProgramBuilds internal capability and adoption momentum without external dependency

Key takeaway. A sequenced roadmap changes the conversation from “can we afford to do this?” to “which of these do we fund first?” That shift is what makes a roadmap fundable.


How we ran governance in parallel, not as a gate

The Security and Governance Analysis ran alongside the project portfolio, not before it. It addressed obligations under the Australian Privacy Principles, data classification requirements for project and client information, identity and access management in the Microsoft 365 environment, and an AI acceptable use policy framework tailored to a professional services consultancy context.

The governance analysis included a self-service Defensibility Gate that the team can apply independently to any new AI project or tool adoption, without external input. It scored each initiative against data risk, defensibility criteria, and change management requirements, and included two standing rules for every AI system: rationale logging (every AI output records its reasoning in human-readable form) and human-in-the-loop (no AI system makes a final decision without human review).

The client owns the governance framework permanently. The policy, the rubric, and the classification framework are internal documents the team can update as their AI adoption evolves.

Key takeaway. Governance that arrives after deployment is remediation. Governance that arrives alongside the roadmap is infrastructure.


What changed

Before. Staff spending 30-45 minutes per task searching across four systems for project precedent and regulatory guidance. Copilot licences unused because early pilots produced inconsistent outputs with no diagnosis of why. Contact and project records duplicated across systems with no canonical source. Leadership with no defensible, sequenced answer to “where do we start with AI?”

After. A 16-project roadmap with explicit sequencing logic, dependency mapping, and cost bands across four priority tiers. A governance baseline the organisation owns independently, including an acceptable use policy and a self-service defensibility rubric. A leadership team that moved from “why isn’t Copilot working?” to “here is exactly what we need to build before we deploy it.” The foundation build and a Copilot pilot with an internal champion cohort are already underway.


Does this fit your situation?

If your team has AI licences you’re not getting value from, and the answer to “why?” is somewhere in how your data is structured rather than how your people are using the tools: that is the problem we diagnose in four weeks.

Book a discovery call →