A contractor can standardize its own operation.
It can’t standardize every project it works on.
One general contractor may require one project management platform. Another may use something different. Project requirements change. Processes for exchanging information can change with them.
Internally, the contractor still needs its own operation to remain reliable.
That creates an important question:
What should stay standard when the environment around the company keeps changing?
Construction companies need consistency, but they also need enough flexibility to work within project requirements they don’t completely control.
The challenge is knowing the difference between variation the work requires and variation the company doesn’t need.
Every Project Doesn’t Operate the Same Way
Construction companies work across different projects, customers, general contractors, project teams, requirements, and technology platforms.
A specialty contractor may have an established way of managing a particular process internally while a general contractor requires information to be entered into its own project management system.
Another GC may use a different platform.
Another project may introduce different requirements.
Even when the work being performed is similar, the way information moves between companies can change.
Some of that variation is simply part of operating in construction.
Trying to eliminate it all isn’t realistic.
What matters is understanding:
What does our company need to do consistently even when the project requires us to work differently?
Different Doesn’t Automatically Mean Inconsistent
Standardization doesn’t require every project to follow exactly the same steps in exactly the same application.
Sometimes a process has to change because a GC requires a particular platform.
Sometimes a project has requirements that don’t exist on another job.
Different roles may legitimately interact with information differently.
Those differences don’t automatically mean the company lacks standards.
The important distinction is between necessary variation and unnecessary variation.
Necessary variation allows the company to meet the requirements of the project.
Unnecessary variation forces people to reinvent something that could reasonably remain predictable.
A company can become too rigid where flexibility is required.
It can also become unnecessarily inconsistent where a standard could make the operation more reliable.
Separate What You Control From What You Have to Accommodate
A contractor doesn’t control every system or process it encounters.
If a GC requires a particular project management platform, the contractor may need to work within it.
If another GC uses something different, the contractor may need to adapt again.
But those external requirements don’t necessarily have to define the contractor’s entire internal process.
Consider a general example involving change information.
The method for submitting or exchanging that information with a GC may vary from project to project.
Internally, however, the contractor may still need to know:
What information does our company need to capture?
Who is responsible for it?
How do we know its current status?
Where does the company’s project record belong?
Who else inside the company depends on that information?
The way information moves outside the company may change from one project to another.
The external path may change. The internal business requirement may not.
That gives the contractor something it can make predictable even when it can’t standardize the entire process.

Decide What Actually Needs to Be Standard
Not every part of a process needs to be performed exactly the same way.
The parts that create reliability deserve closer attention.
In one process, the standard might define the information that needs to be captured.
In another, it might establish where the company’s project record belongs.
It could define responsibilities or a required handoff.
It could establish access and security requirements.
And sometimes the individual steps themselves matter.
A security control may need to be followed consistently.
Certain information may need to be captured in a particular way.
A handoff may need to occur before another activity.
A project record may need to be maintained in an established location.
The standard depends on what the business needs the process to accomplish and where consistency matters.
Identify the parts of the operation where consistency creates reliability.
Once those are understood, there can be more flexibility in the parts of the process where variation doesn’t interfere with the outcome, another person, or the company’s requirements.
Existing workarounds can also provide useful clues. If several employees have developed their own ways of handling the same requirement, it may be worth asking whether the standard adequately supports the work.
A standard should make the operation more reliable, not prevent the operation from learning.
Standardize the Requirement Before the Application
Technology is often where standardization becomes visible.
Use this application.
Save files here.
Follow this workflow.
Use this template.
Those standards can be valuable.
But an application isn’t the business requirement.
If the company needs to maintain a reliable project record, first understand what that record needs to contain and where the company expects it to be maintained.
If information needs to reach another role, understand the handoff.
If company or project information needs protection, understand the security requirements that need to apply.
Then determine how technology should support those requirements.
Sometimes that will mean standardizing on a particular application.
Sometimes employees will need to work in another company’s system while still maintaining an internal process.
Sometimes the technology already in place may support exactly what the company needs.
Standardization doesn’t always mean using the same application for every project.
It means knowing what needs to remain consistent even when the technology around the process changes.
Technology Should Support Consistency and Flexibility
Construction technology has to operate in both worlds.
A contractor needs enough consistency that employees understand where important information belongs, how key processes work, what standards apply, and what the company expects.
At the same time, employees may need to interact with different external systems and project requirements.
Technology should help the company maintain that internal consistency while adapting to different project requirements.
That may mean predictable internal locations for information.
It may mean consistent access or security standards.
It may mean templates, workflows, permissions, or automation where they make a process more reliable.
It may also mean recognizing when an external project requirement legitimately changes how someone has to work.
The objective isn’t to force every project into the same technology.
It’s to create enough consistency inside the company that necessary variation outside the company doesn’t create unnecessary variation inside it.
Standardization Supports the Construction Technology Framework™
The Construction Technology Framework™ provides a way to look at where consistency and flexibility matter across the operation.
Connect Teams
Are communication and information handoffs predictable even when project requirements vary?
Support the Field
Can field teams adapt to different project requirements without losing access to the processes and information they depend on?
Manage Project Information
Does the company have clear expectations for how important information is captured, organized, maintained, and found?
Reduce Risk
Do security, access, documentation, and other important standards remain consistent where they need to?
Keep Projects Moving™
Can people adapt to project requirements without unnecessarily reinventing how the company works each time?
The Framework doesn’t require every project to look the same.
It helps identify where technology and process need to remain reliable even when the environment around them changes.
Consistency Doesn’t Require Every Project to Be the Same
Construction companies need to adapt.
Different projects will have different requirements.
Different general contractors may use different systems.
Different situations may require different ways of working.
That’s part of the environment contractors operate in.
But necessary variation doesn’t mean everything inside the company has to change with it.
A contractor can still decide what information it needs, what processes need to be predictable, what standards need to apply, and where employees need enough flexibility to meet the requirements of the project.
The goal isn’t to make every employee, every project, or every application work exactly the same way.
It’s to make the important parts of the operation reliable even when the environment changes.
Standardize where standardization creates reliability. Customize where the contractor’s operation requires it.
That’s Construction First. Technology Second.
Better Decisions Keep Projects Moving™.
Find the Right Balance Between Consistency and Flexibility
The Construction Technology Review™ looks beyond individual applications to understand how your people, processes, project information, and technology work together.
Using the Construction Technology Framework™, M-Squared Networks looks at where consistent standards can make the operation more reliable, where project requirements create necessary variation, and whether technology is supporting both.
The objective isn’t to force every project or employee to work exactly the same way.
It’s to understand what needs to remain predictable inside your construction company and where the operation needs enough flexibility to adapt.
Take a closer look at what should be standardized and where your construction company needs room to work differently.
