A $500M+ construction group had grown faster than the way its companies worked together.

Engagement at a glance

• Client profile: multi-entity heavy civil and construction group
• Approved scale: more than $500 million and more than 1,000 people
• Starting issue: different processes, systems and responsibilities across the group
• Boris & Associates Inc. work: transformation roadmap, organization and decision model, ERP strategy and delivery oversight

Why had growth made the group harder to run?

Each company had learned to deliver its work, but the group did not yet have one clear way to decide what should be common and what should remain local. Leadership needed better visibility and stronger company-wide functions without turning every operating company into the same business.

Different ways of working

The same activity could follow different steps, owners and systems depending on the company.

Unclear company-wide ownership

Important work crossed operating companies, but no single owner controlled the full result.

Technology decisions were disconnected

Systems reflected local history, so an ERP decision could not be separated from organization, process and data decisions.

What did the maturity diagnostic examine?

We compared leadership expectations with the work performed across the group. The review looked at how decisions were made, where responsibilities changed hands, which processes required common control, what information leadership needed and how current systems supported or fragmented the work.

Organization and decisions

Corporate functions, operating-company roles, decision authority and escalation.

Processes and ownership

Priority work that crossed estimating, projects, finance, equipment, procurement and support functions.

Information and systems

Common data needs, duplicated tools, system ownership and ERP readiness.

What did Boris & Associates Inc. design?

The engagement turned the diagnostic into one connected plan. The organization, process priorities, ERP direction and delivery structure were designed together so that one decision would not create a new problem somewhere else.

A future organization and decision model

Clarified what the group should own, what each company should own and where decisions should be escalated.

A prioritized process agenda

Sequenced the work that had to be redesigned before or alongside technology changes.

An ERP strategy

Defined the role of the ERP and the business conditions required before implementation.

A transformation roadmap

Placed organization, process, data, technology and adoption work in a practical order.

A delivery and oversight structure

Defined how leaders would make decisions, manage dependencies and keep the program moving.

How were business decisions connected to ERP?

The ERP was treated as part of the company design, not as a separate IT purchase. Process ownership, data definitions, company structures, approvals, reporting and integration needs had to be clear before configuration choices could be trusted.

Business requirements first

Requirements came from the work and the decisions the company needed to control.

Shared data where it mattered

Common identifiers and definitions were separated from local operating details.

Implementation dependencies made visible

Organization and process decisions that could block the ERP were placed on the same roadmap.

What did leadership receive?

Leadership received a common view of the company’s starting point and a multi-year plan for changing it. The work connected the target organization, priority processes, ERP direction, decision forums and implementation sequence in one management agenda.

A maturity baseline

A fact-based picture of how the group operated and where growth was creating risk.

A clear target

An agreed direction for organization, responsibilities, processes and systems.

A sequenced roadmap

A practical order of work with dependencies and decision points.

A way to govern delivery

Named forums, owners and escalation paths for carrying the change into the business.

What can another construction group learn?

A group does not become one company by installing one system. It becomes easier to run when leaders decide what must be common, what can remain local, who owns each result and how information will move across the businesses. The ERP can then support those decisions instead of trying to make them.

Continue with the related work

Use these links to move from the client situation to the service and audience pages that explain the work in more detail.

Construction Transformation System

General Contractors

Questions construction leaders ask

These are the questions we hear most often from construction leaders facing the same operating challenge.

What should a multi-company construction group change first?

Start with decisions and ownership. The group must know which work needs common control before standardizing processes or configuring an ERP.

Can operating companies keep different ways of working?

Yes. Core controls, definitions and decision points can be common while local procedures remain different where the work truly requires it.

Is ERP selection part of this work?

It can be, but selection follows business requirements, system roles, data needs and implementation readiness. The software should not define the company by default.

Has your group become several companies that leadership must manage separately?

We can help you decide what must work as one company, what should remain local and how process, data and technology changes should be sequenced.