Defining roles, responsibilities, authority, and the words that shape how a fiber project operates
Fiber Done Right Podcast
Listen Here: https://open.spotify.com/episode/7raxFtSyYdt0tGgCAiNFgG?si=Am1Q5_9bQ_qbk7Ns6GVu-A
I have been on a lot of projects where people were expected to perform a job that nobody had clearly defined for them.
The Project Manager had one expectation of the Construction Manager. The Construction Manager had a different expectation of the Inspector. The Inspector had their own understanding of what they were responsible for, usually based on where they worked before or what someone in the field had taught them. The contractor had another understanding of where the Inspector’s responsibility and authority started and stopped.
Everyone had a title. That did not mean everyone understood the job.
You eventually see the consequences in people’s behavior. Some people overstep because they believe they own decisions that were never theirs to make. Others hold back and escalate everything because they do not know which decisions they are allowed to make. Two people may unknowingly perform the same responsibility while another responsibility gets missed completely.
Then we start evaluating their performance.
We say someone needs to take more ownership. Someone else needs to stay in their lane. An Inspector needs to make more decisions. Another Inspector needs to stop directing the contractor. A Construction Manager is too involved in the field. Another Construction Manager is not involved enough.
Those evaluations may be correct. The first question I want answered is whether the project ever clearly established what was expected.
You cannot consistently evaluate someone’s performance against an expectation that only exists in somebody else’s head.
That is why I think roles and responsibilities belong near the beginning of a project, before we get too far into construction processes, inspection procedures, documentation requirements, or closeout. The project needs to establish how it will operate before we expect people to operate within it.
That conversation also cannot happen once at kickoff and then disappear. Projects change. New Inspectors come in. Contractors mobilize. A new Construction Manager takes over an area. Additional crews are added. Someone gets promoted or transferred from another project.
Every one of those people arrives with experience, and that experience comes with an existing idea of how their position is supposed to work.
Someone may have performed the exact same role for ten years and still need to understand how this project expects that role to operate. Their previous project may have given Inspectors more authority. Their previous customer may have handled deficiencies differently. Their previous company may have used a different escalation path.
Experience gives people knowledge. It also gives them a history they will naturally use when something has not been clearly defined.
That makes onboarding into a project more than handing someone specifications, drawings, schedules, and contact information. There needs to be an intentional conversation about how the project operates: what their role is, what they are responsible for, what decisions they can make, where their authority stops, what gets escalated, who receives that escalation, and what the important project terms actually mean.
A project should not require every new person to reverse-engineer how it operates after they arrive.
A Title Does Not Define the Job
Take the word Inspector.
Nearly everyone on a fiber construction project has a general idea of what an Inspector does. Once you get beyond the general idea, the differences start showing up.
Is the Inspector responsible for observing construction or verifying construction? Are they expected to identify deficiencies? Can they issue a deficiency directly to the contractor? Can they require the contractor to correct it? Can they stop work or prevent work from moving beyond a defined hold point?
Then the questions become more consequential. Can the Inspector tell the contractor how to correct the installation? Can they approve a deviation from the construction standard? Can they approve additional quantities? Can they accept completed work? When does the Construction Manager become involved? When does the Project Manager become involved? When does engineering need to make the decision?
The title Inspector answers none of those questions.
If the project does not answer them either, the person has to create their own answers.
An experienced Inspector will naturally use what worked on previous projects. A newer Inspector may copy the behavior of another Inspector. Someone promoted from a construction crew may bring a completely different understanding of what the position should be.
Put five Inspectors on the same project without clearly defining the position and you can end up with five different versions of the job.
When expectations have gaps, people fill those gaps with experience.
That experience might be excellent. It still may not match how this project needs to operate.
Define More Than Responsibilities
Saying, “Here are your responsibilities,” does not completely solve the problem.
There are several things I want people to understand about their position on a project.
Role: Where do I fit within this project?
Responsibility: What am I expected to do?
Authority: What decisions am I allowed to make?
Accountability: What am I answerable for?
Escalation: Which decisions are outside my authority, and where do they go?
Those pieces have to work together.
Consider an Inspector who is responsible for verifying that underground construction meets the project requirements. That sounds clear until the Inspector finds a handhole installation that does not meet the standard.
Now what?
If the Inspector is responsible for identifying the deficiency but does not know whether they have authority to require correction, they may hesitate when they should act. If they believe they can approve an alternate installation when that decision actually belongs to engineering or the Construction Manager, they may make a decision the project never intended them to make.
The opposite can happen just as easily. An Inspector may escalate routine decisions because nobody has ever told them they are authorized to handle those decisions themselves. The Construction Manager starts receiving questions that should have been resolved in the field. Those questions eventually reach the Project Manager. Decisions take longer, field work waits, and management spends time resolving issues that could have been handled at the appropriate level.
The Inspector may be doing exactly what they believe the job requires.
This is why defining responsibility without defining authority leaves the job unfinished. People need to know what they own and where that ownership stops.
Once that boundary is understood, escalation becomes much simpler.
Escalation should not mean, “Call somebody whenever you are uncomfortable making a decision.” It should identify the point where a decision legitimately moves from one role to another.
That gives the project a predictable path for decisions.
Project Control Does Not Require the Project Manager to Make Every Decision
The Project Manager owns the execution of the project. They are responsible for coordinating the work, people, information, schedule, resources, risk, and decisions necessary to deliver it.
That responsibility does not require the Project Manager to personally make every decision.
If every question eventually has to reach the PM before anything can happen, the project has become too dependent on one person. Decisions slow down as the amount of work increases, and the PM spends more time resolving routine questions instead of managing the larger project.
Good project control means people know how decisions are supposed to be made before those decisions are needed.
The Inspector knows what they can decide. The Construction Manager knows what belongs to them. The contractor understands who can give direction. Engineering knows which decisions require technical approval. The Project Manager knows which decisions actually require their involvement.
Now decisions can happen at the appropriate level while the PM maintains control of the project.
That distinction becomes increasingly important as projects grow. One experienced PM can compensate for a surprising amount of ambiguity on a small project. That becomes much harder when multiple contractors, crews, Inspectors, and Construction Managers are generating decisions every day.
Clear roles reduce the number of decisions that have to travel through unnecessary layers before someone can act.
Then We Have to Define the Words
Even with clearly defined roles, another source of variation remains.
The words we use to describe the work.
Fiber construction uses ordinary words that sound so obvious we rarely stop to define them: complete, ready, verified, approved, accepted, restored, deficiency, hold, redline, and as-built.
People can use the same word while operating from different definitions.
Take complete.
A contractor tells the Construction Manager that a handhole is complete.
What does that actually tell us?
The contractor may mean their crew has finished the physical installation. The Inspector may hear “complete” and assume the installation has been inspected. The Project Manager may use “complete” to mean that construction is finished, deficiencies are closed, restoration is finished, documentation is submitted, and the redlines are current.
Each person may have a reasonable definition. Those definitions do not describe the same condition.
That matters because projects make decisions based on these words.
If a handhole is marked complete, production may be reported. The crew may move to the next area. Restoration may be released. Quantities may move toward billing. Documentation may move into closeout. Someone reviewing the project later may reasonably assume there is nothing left to do.
The word has now done more than describe the handhole.
It has allowed other actions to happen.
That is why project definitions are more than vocabulary.
A useful definition establishes the conditions that must be true before the project can move forward.
Instead of writing:
“Complete means the work has been completed according to project requirements.”
Ask:
“What must be true before this project allows us to call the work complete?”
Maybe physical installation must be finished. Required inspection must be completed. Identified deficiencies must be corrected and verified. Restoration must be finished. Required photographs must exist. Redlines must be current.
The exact requirements will vary by project. The important part is that the conditions are understood.
Now “complete” has moved from somebody’s interpretation to something the project can verify.
The Words Should Connect Back to the People
Defining the word still does not finish the job.
Suppose the project clearly defines what verified means.
Who performs the verification? What are they required to verify? What evidence demonstrates that it happened? What happens when the work does not meet the requirement? Who has authority to determine the next action? Where does the decision go when it exceeds that person’s authority?
This is where roles, responsibilities, authority, definitions, and escalation start working together.
The role establishes where someone fits. The responsibility establishes what they are expected to do. Authority establishes what they can decide. Definitions establish the conditions those decisions are based on. Escalation establishes where the decision goes when it exceeds their authority.
That structure removes unnecessary interpretation from repeatable parts of the project while leaving room for experienced people to use judgment where judgment is actually needed.
There is an important difference between those two things.
We want experienced people making good judgment calls when field conditions require judgment. We do not need them spending that experience figuring out what the project means by “complete” or guessing whether they are allowed to close a deficiency.
Those are questions the project can answer ahead of time.
Every New Person Adds Another Interpretation Unless You Give Them a Common One
Small, experienced teams can hide unclear expectations for a long time.
People who have worked together for years develop an unwritten way of operating. The Construction Manager knows what the PM means by “ready.” The Inspector knows which decisions can be made without calling. The contractor knows what documentation is expected when someone says the work needs to be complete.
Shared experience fills the gaps.
Then somebody new enters the project.
A contractor mobilizes. An Inspector is hired. A Construction Manager takes over an area. Someone is promoted. A crew transfers from another market.
That person arrives with their own operating history.
Someone with ten years of experience does not arrive as a blank slate. They already have an idea of what an Inspector does, what a Construction Manager owns, how deficiencies are handled, when something should be escalated, and what words like “complete” and “accepted” mean.
If the project does not intentionally establish its own expectations, those previous ways of working begin entering the current project.
Do that across several contractors, multiple Inspectors, different Construction Managers, and crews coming from different markets, and the project can slowly become a collection of individual operating methods.
This is why every person entering the project needs to understand how this project operates.
The conversation may be shorter with someone experienced, but it still needs to happen.
When a new Inspector starts, do not simply hand them the inspection documents. Explain how the Inspector position works on this project, what they own, what they can decide, and what they need to escalate.
When a contractor mobilizes, establish the responsibilities, communication paths, authority boundaries, escalation process, and important definitions before those differences have to be discovered during construction.
When someone changes positions, have the conversation again from the perspective of the new role.
You are giving everyone a common starting point.
Without that conversation, people have to observe the project, ask around, make assumptions, test boundaries, get corrected, and eventually figure out how things really work.
That is a slow and expensive way to create understanding.
Start With the Areas Where Confusion Has Consequences
You do not need a hundred-page manual defining every possible interaction before construction can begin.
Start with the areas where ambiguity matters.
Look at the roles involved in executing the project. What does each person own? What are they expected to do? What decisions can they make? What are they answerable for? Where does their authority end? Where does the decision go next?
Then look at the language used to communicate the status of the work.
Which words allow work to move forward? Which affect inspection? Which affect payment? Which affect acceptance? Which regularly create disagreements?
Define those first.
Then keep that understanding alive as the project changes.
The objective is not to eliminate human judgment from construction. Construction will always require people who understand the work and can make good decisions when conditions change.
The objective is to stop wasting that judgment on questions the project could have answered before the work started.
Clear roles tell people where they fit. Clear responsibilities tell them what is expected. Clear authority tells them where they can act. Clear definitions give everyone a common understanding of the work. Clear escalation tells them what happens when the decision needs to move somewhere else.
That gives the project a common way of operating even as the people inside it change.
Use This on Your Project Today
You can test this on an active project without creating a new procedure or manual.
Pick one recurring field decision. Ask the Project Manager, Construction Manager, and Inspector separately who owns the decision, what that person can decide without additional approval, and when the decision must be escalated.
Do not explain the answer first. Compare what they already believe.
Then choose one word your project uses constantly. Complete is a good place to start.
Ask three people independently:
“What exactly has to be true before we can call this work complete?”
Compare their answers.
Finally, ask someone who recently joined the project:
“Who explained how your role works on this project, including what decisions you can make and what needs to be escalated?”
The answers will tell you more than a written policy sitting in a folder ever could. They show you how the project is actually operating today.
If the answers are materially different, you have found a place where the project is relying on individual interpretation.
Now you know where to start.
Define enough of the project that people can use their experience to solve construction problems instead of using their experience to figure out how the project itself is supposed to work.
Building the system that makes this repeatable is the work Valor does through its operational systems.
Related reading: The Roles Involved (Part 1) and The Roles Involved (Part 2).