The Project Unknown Owner Problem Accountability Beyond the Register

A risk register can look healthy while the project is quietly losing control.

The column is filled. Every action has a name. Every interface issue has an owner. Every decision has a due date. The meeting minutes read as if accountability is in place. Weeks later, the same items are still open, procurement packages are stuck, construction work fronts are blocked, commissioning logic is being rewritten, and the named “owner” explains, quite reasonably, that they never had the authority, information, budget, or access needed to close the item.

That is the project unknown owner problem. Accountability exists on paper, but not in practice.

In complex capital projects, this problem is rarely caused by laziness. It develops in the gaps between organizations, phases, contracts, disciplines, and decision rights. It appears in oil and gas megaprojects, infrastructure programs, brownfield upgrades, mining expansions, utilities, marine works, shutdowns, and energy transition projects. The tools vary, but the failure mode is familiar: the register says someone owns it, while the project system gives them no real means to act.

A Name In A Register Is Not Accountability

Assigning a name is an administrative act. Establishing accountability is a management act.

The difference matters because major project controls often rely on assigned ownership. Risk registers, action trackers, interface registers, assumptions logs, decision logs, management of change systems, technical queries, nonconformance reports, readiness trackers, and punch lists all need owners. Without them, the project cannot organize work.

The problem starts when a name is confused with control.

A real owner needs several conditions to be true.

• Authority

  The person can make the decision, direct the work, accept the risk, commit resources, or escalate to someone who can.

  
  

• Resources

  The person has access to time, budget, technical support, contractors, vendors, field crews, or management attention.

  
  

• Competence

  The person understands the issue well enough to judge the right closure path or knows how to bring in expertise.

  
  

• Information

  The person can see the data, drawings, commercial terms, schedule logic, site constraints, operating requirements, and prior decisions that shape the item.

  
  

• Access

  The person can reach the stakeholders whose input or approval is needed, including contractors, vendors, operations, regulators, lenders, authorities, or joint venture partners.

  
  

• Escalation rights

  The person can raise the matter when closure is blocked, without being treated as difficult or outside their lane.

  
  

• Responsibility for closure

  The person is not merely “monitoring” the item. They are responsible for driving it to an agreed, evidenced outcome.

  
  

This aligns with how respected project management and risk management bodies define responsibility. PMI and APM guidance both stress clarity of roles, decision-making responsibility, stakeholder engagement, and governance. ISO 31000 treats risk ownership as part of an active risk management process, not a register maintenance exercise. AACE International and the Construction Industry Institute both emphasize integrated project controls, change management, and decision discipline as practical conditions for predictable outcomes. None of these bodies treat a spreadsheet entry as a substitute for management.

A simple example clarifies the difference.

A brownfield refinery project identifies a risk that tie-in isolation points may not match the original drawings. The risk register names the engineering lead as owner. That looks reasonable. Yet the engineering lead cannot authorize a plant survey, compel operations to release a unit for inspection, approve scaffolding access, or control the shutdown window. The named owner can comment, attend meetings, and send emails. They cannot close the risk.

Effective ownership would look different. The owner might be the shutdown manager or project manager, supported by engineering, operations, HSE, and the contractor. The owner would have authority to request field verification, secure access, align the work with the turnaround plan, and escalate if operations availability threatens the project critical path. Engineering still provides technical judgment, but accountability rests with someone who can make closure happen.

That is not wordplay. It is the difference between a live risk and a filed risk.

Weak Ownership Grows Across The Project Life Cycle

The unknown owner problem rarely appears suddenly. It grows as the project changes shape from concept to operations. Each phase creates its own version of paper accountability.

Concept And Feasibility Create Assumptions That Outlive Their Owners

In early development, teams make assumptions because they must. They assume plot space, logistics routes, utility availability, permitting durations, power import capacity, vendor lead times, geotechnical conditions, modularization strategies, and operating philosophies. These assumptions are often recorded in basis of design documents, cost estimates, risk registers, and decision papers.

The risk comes later. The people who made the assumptions move on. The project enters FEED with a different team. The assumption register exists, but no one is actively responsible for validating, retiring, or converting assumptions into requirements.

For example, an infrastructure project may assume that an existing utility corridor has spare capacity for temporary diversions. During concept, this is acceptable as a planning basis. During FEED, verify it. If the assumption remains “owned” by a planning engineer who has no access to utility authorities, the project carries a hidden risk. When construction starts, a temporary works package fails because the capacity was never available. The owner existed in the register. The accountable path did not.

FEED And Engineering Create Decisions That Depend On Others

FEED and detailed design generate many cross-discipline decisions. Layout freezes, design margins, equipment selection, hazardous area classifications, constructability input, marine access, controls philosophy, metering requirements, telecoms integration, and maintainability all depend on multiple parties.

Registers often assign these items to discipline leads. That can work for purely technical issues. It fails when the decision requires commercial approval, operations acceptance, regulatory input, vendor data, or client direction.

An offshore topsides project may assign an unresolved equipment layout decision to the mechanical lead. The issue affects lifting studies, escape routes, electrical routing, maintenance envelopes, and module weight. Mechanical can recommend an answer, but cannot decide alone. If the decision needs project director approval because it affects weight growth and schedule, the owner should have a defined escalation path and a decision date tied to downstream deliverables.

Without that discipline, engineering teams keep working around the gap. They issue drawings with holds. Procurement proceeds with qualifications. Construction planning assumes a best case. The register remains green until the physical work exposes the open decision.

Procurement Ownership Becomes Blurred Between Buyer, Supplier, And Project

Procurement is a fertile ground for nominal ownership. Long-lead items cut across engineering, quality, logistics, finance, contracts, expediting, customs, site readiness, and vendor documentation.

A buyer may be assigned a procurement action, but the buyer cannot approve technical deviations, negotiate liquidated damages, release milestone payments, approve shipping routes, or resolve inspection failures. A supplier may be “responsible” under the purchase order, but the project still owns the consequence of late data, late delivery, or nonconforming equipment.

On an EPC power project, a transformer vendor may deliver protection relay interface data late. The action tracker names the procurement coordinator. They can chase the vendor, but cannot judge whether provisional data is acceptable, cannot approve a design workaround, and cannot escalate the commercial position. If the issue sits there for six weeks, it may delay cable schedules, delay panel fabrication, and require field rework.

Effective ownership would connect procurement, engineering, contracts, expediting, and project controls. The owner would have authority to set a recovery plan, agree acceptable interim data, trigger contractual notices if needed, and protect the construction sequence.

Construction Exposes Whether Ownership Was Real

Construction is where false ownership becomes expensive.

In the field, unclear accountability shows up as blocked work fronts, missing permits, late materials, design queries, access conflicts, unresolved temporary works, inspection delays, incomplete scaffolding, and handover packages that technically exist but cannot be used.

A civil contractor may own a work front delay in the daily coordination tracker, but the underlying issue is the client's late release of underground services drawingscommissioning engineer is assigned the action, plus a permit condition from a local authority. The contractor can report the delay. They cannot remove it. Naming the contractor as the owner may even distort behavior, because the project begins to treat the delay as a contractor performance issue rather than a governance issue.

This is where good project directors ask uncomfortable questions. Who can actually remove the constraint? Who controls the next decision? Who has the relationship with the authority? Who carries the commercial consequence if the item is unresolved? Who has the right to change sequence?

If the answer is split across five parties, the project needs one accountable integrator, not five nominal owners.

Commissioning, Start-up, And Handover Reveal Late Ownership Failures

Commissioning is unforgiving because systems, people, documents, permits, spares, procedures, software, training, and operating readiness must converge. A missing owner during engineering may remain tolerable for months. During commissioning, it can stop start-up.

Typical examples include:

• Cause and effect gaps that no one owns across process, control systems, and operations.

• Vendor commissioning procedures that do not match installed equipment.

• Temporary bypasses with unclear removal responsibility.

• Punch items that construction sees as minor,emphasizing but operations sees as start-up critical.

• Spare parts lists accepted commercially but not validated by maintenance.

• Training matrices showing assigned owners but no confirmed attendance, competency check, or simulator availability.

• Handover dossiers submitted by area, while operations needs system-based completeness.

  
  

Operational readiness guidance from professional bodies and sector organizations, including the Energy Institute and IOGP, emphasizes preparation for safe start-up, competence, procedures, integrity, emergency response, and management of change. All of these themes depend on real ownership. A readiness tracker with names attached may show progress, but start-up risk remains if the named owners cannot close gaps across the asset, operations team, and contractor.

In a mining processing plant, for instance, commissioning may find that operations, HSE, and the chemical supplier have not approved reagent storage procedures. The action is assigned to a commissioning engineer. That engineer can draft a procedure but cannot approve operating limits, confirm chemical handling competence, or authorize SIMOPS controls. If the owner remains unchanged, the action ages while the start-up date approaches.

Real accountability might sit with the operations readiness manager, with named support from commissioning, HSE, supply chain, and the supplier. Closure requires approved procedures, trained personnel, aligned emergency response, and evidence that the plant can safely receive and store chemicals.

Conventional Registers Can Create The Appearance Of Control

Registers are necessary. They are also dangerous when they become theater.

A well-maintained register gives comfort. It has filters, color coding, owners, due dates, categories, residual risk scores, and comment histories. Senior leaders can review it in 30 minutes. That is useful only if the register reflects reality.

The danger is that registers often measure administrative completeness rather than closure power.

Common weak signals include:

Register signal	What it may hide
Every item has an owner	Some owners lack authority or access
Most actions are “in progress”	No one has defined what closure means
Due dates keep moving	The project accepts delay without escalation
Risk responses are listed	Response funding or decision rights are missing
Interfaces are logged	No party owns integration across the boundary
Actions are closed after a meeting	Closure evidence is weak or missing
Items are reassigned often	The project is searching for an owner after the fact

The issue is not the register format. It is the governance behind it.

ISO 31000 frames risk management as an integrated, structured, and iterative process. That idea matters here. Risk ownership must connect to decision-making and performance, not just documentation. PMI’s project management guidance also places responsibility, communications, stakeholder engagement, and governance at the center of delivery. APM’s Body of Knowledge takes a similar view, with emphasis on sponsorship, assurance, and role clarity. ICE, RICS, and other professional institutions repeatedly stress clear responsibility allocation, competent management, and sound records in construction and infrastructure delivery.

In other words, the evidence base points in one direction. Controls are only useful when they change behavior.

A risk register should not answer only, “Who is named?” It should answer, “Who can cause this to be closed, and how will we know?”

An action tracker should not ask only, “Is the action overdue?” It should ask, “What has prevented closure, and does the owner have the power to remove that barrier?”

An interface register should not ask only, “Which contractor owns this interface?” It should ask, “Who is accountable for integration when both sides can claim partial compliance?”

A meeting minute should not say, “Assigned to engineering,” when the real issue is a client decision, a vendor delay, an authority approval, or a commercial settlement.

The Commercial And Safety Consequences Are Real

Weak ownership feels administrative until it affects physical work, entitlement, or safety. Then it becomes a multiplier of cost and risk.

Unresolved Risks Become Accepted By Accident

Projects make conscious risk decisions all the time. That is normal. The danger is accidental risk acceptance driven by owner weakness.

If a risk remains open because the named owner cannot fund mitigation, obtain information, or escalate, the project may drift into exposure without realizing it. This can happen with geotechnical uncertainty, marine weather windows, utility diversions, hazardous material surveys, vendor qualifications, cybersecurity requirements, grid connection assumptions, and regulatory conditions.

By the time the risk materializes, the team may say, “We knew about this.” That is not enough. Knowing about a risk is not the same as managing it.

Overdue Actions Erode Schedule Credibility

A schedule depends on clearing decisions and constraints on time. Many overdue actions are not just poor housekeeping. It signals that the management system is overloaded or misaligned.

AACE International’s total cost management framework and recommended practices emphasize the relationship between scope, cost, schedule, risk, change, and project controls. That relationship breaks down when action status does not reflect true readiness. A procurement action three weeks late may become a construction delay three months later. A design query left unresolved may become a claim. An authority approval assumption may become a critical path issue.

Action-aging analysis helps you seeSomeone marks an action complete because they issued a document, not because the receiving party accepted it or field conditions whether the project closes issues at the rate it creates them. If high-criticality actions are aging while progress reports stay positive, the project has a truth problem.

Interface Failures Create Rework And Claims

Interfaces are one of the hardest ownership problems in capital projects because responsibility often sits across contract boundaries. EPC contractors, subcontractors, package vendors, utility providers, port authorities, operations teams, designers, and regulators may each own part of the answer.

An offshore campaign may need an interface between a subsea contractor, topsides modification team, marine warranty surveyor, vessel operator, and production operations. A register can name an interface owner. Yet if that person cannot align lift windows, shutdown constraints, vessel availability, and SIMOPS requirements, the role is coordination without control.

The result can be vessel standby, late permits, offshore rework, clashes in work packs, disputed changes, and unsafe improvisation.

Quality And Commissioning Suffer From False Closure

False ownership often leads to false closure. An action is marked complete because someone issued a document, not because the receiving party accepted it or the field condition changed.

Quality systems are especially vulnerable. A nonconformance report may name the subcontractor as owner, but disposition needs designer approval, client acceptance, and sometimes regulatory involvement. If the owner cannot obtain those decisions, the NCR remains open or closes on weak evidence. Later, commissioning inherits incomplete records or questionable technical acceptance.

Commissioning then becomes the place where every unresolved ownership problem arrives at once.

Operational Readiness Becomes An Afterthought

Operational readiness is not a document handover event. It includes people, procedures, competence, spares, maintenance systems, emergency response, permits, integrity management, vendor support, and asset information.

When readiness items have nominal owners, start-up teams inherit gaps that should have been closed months earlier. Maintenance cannot load equipment into the CMMS because tag data is incomplete. Operations cannot accept a system because training was tracked as delivered but competence was not verified. Emergency response plans do not reflect the final layout. Spare parts are purchased but not preserved. Vendor warranties start before systems are accepted.

Regulators and safety bodies in high-hazard sectors consistently focus on duty holder control, competence, management of change, and assurance. Those concepts require named people, but they also require the means to act. A name without authority is weak assurance.

Practical Controls That Make Ownership Real

The answer is not to abandon registers. The answer is to manage ownership with the same seriousness as cost, schedule, quality, and safety.

Define Ownership Criteria Before Assigning Names

Before assigning an owner, test whether the person can close the item. Use simple criteria.

• Can they make or obtain the decision?

• Can they access the people and information needed?

• Do they control or influence the resources?

• Do they understand the technical and commercial implications?

• Can they escalate when blocked?

• Are they accountable for closure evidence, not just updates?

  
  

If the answer is no, name a different owner or split the item into parts with one accountable integrator.

This reduces the common habit of assigning items to whoever spoke last in the meeting.

Check Authority Against The Real Decision Path

Many overdue items are not late because people forgot. They are late because the named owner sits below the decision level.

A project director should be able to look at critical items and ask, “Is this assigned at the level where it can be solved?”

For example:

Item	Nominal owner	Better accountability test
Late environmental permit condition	Environmental advisor	Who owns the authority relationship and project decision on mitigation cost?
Vendor deviation affecting safety integrity	Buyer	Who can approve technical acceptance and commercial recovery?
Brownfield access constraint	Construction supervisor	Who can negotiate operations access and shutdown priority?
Interface between rail systems and civil works	Interface coordinator	Who owns integrated acceptance across both contracts?
Missing operations training for start-up	Commissioning engineer	Who owns operational readiness and competence sign-off?

The named owner may still support the work. The accountable owner should match the decision path.

Use RACI Carefully And Keep It Current

RACI can help if it reflects reality. It can also create confusion when every organization interprets it differently.

For critical risks, decisions, interfaces, and readiness items, the project should be clear about four questions:

• Who is accountable for closure?

• Who must support the work?

• Who must be consulted before closure?

• Who must accept the result?

  
  

Avoid using RACI as a static attachment buried in a project execution plan. Update it when the project moves from FEED to detailed design, from procurement to construction, from construction to commissioning, and from project to operations.

The owner that made sense in FEED may be wrong during commissioning.

Set Escalation Thresholds Before The Crisis

Escalation should not depend on personality. It should depend on risk and time.

Set thresholds such as:

• High-risk item not progressing by an agreed date.

• Critical path action within a defined lookahead window.

• Interface issue affecting more than one contract.

• Decision required above the owner’s authority.

• Repeated due-date movement.

• Closure blocked by missing client, vendor, authority, or operations input.

• Any safety, quality, or regulatory item without clear acceptance criteria.

  
  

Escalation is not blame. It is how the project supplies missing authority.

Senior leaders should make that explicit. If people fear escalation, they will keep weak ownership alive until the cost becomes visible.

Enforce Due-date Discipline

A due date should mean the date by which closure evidence is expected. It should not mean “next update due.”

If dates move, record why. Was the original date unrealistic? Did the owner lack authority? Did another party fail to provide input? Did the project change priority? Did the item need escalation but not receive it?

Repeated due-date changes without management action signal that the register is no longer a control tool. It has become a diary.

Analyze Action Aging

Action aging shows patterns that weekly reviews miss.

Useful cuts include:

• Age by criticality.

• Age by discipline.

• Age by contract package.

• Age by project phase.

• Age by owner role or organization.

• Age by reason for delay.

• Age by repeated due-date changes.

  
  

This can reveal, for example, that engineering actions close quickly, but operations acceptance actions age for months. Or that vendor data issues are not isolated delays but a package-wide procurement weakness. Or that all authority-related actions sit with technical staff who cannot influence approvals.

The point is not to shame owners. The point is to fix the system.

Require Closure Evidence

Closure should require evidence appropriate to the item.

For a risk, closure evidence may be a completed mitigation, accepted residual risk, approved contingency plan, or formal decision to accept exposure.

For an interface, evidence may be a signed interface agreement, approved drawings, tested data exchange, completed field verification, or accepted system boundary.

For a commissioning action, evidence may be an approved procedure, test record, trained personnel, accepted punch categorization, or operations sign-off.

For a commercial commitment, evidence may be a contract instruction, agreed change order position, notice issued, or documented settlement path.

Weak closure language should trigger challenge. Phrases like “discussed,” “being managed,” “closed in meeting,” “no further action,” and “to be monitored” may be valid, but only when backed by evidence.

Reassign When the Named Owner Cannot Act

Do not treat reassignment as failure. It is responsible management.

If the owner lacks authority, resources, competence, information, access, or escalation rights, the project should reassign the item or appoint a higher-level accountable owner. Waiting for a powerless owner to solve an item wastes time and weakens trust.

Good reassignment is transparent. It records why the change occurred and what support the new owner needs.

For major items, use accountability reviews. These can be short, focused reviews of the top open risks, overdue actions, interface blockers, decisions, and readiness gaps. The review should ask whether each item has a real owner, not whether the owner field is populated.

The Questions Senior Leaders Should Ask

Project directors, sponsors, and senior leaders do not need to review every action. They do need to test whether the accountability system is real.

When a critical item remains open, the best questions are practical.

• Who is the accountable owner, and what power do they have to close it?

• What decision, resource, information, access, or approval is missing?

• Is the item assigned to the person doing the work or the person accountable for the outcome?

• If the owner cannot close it, why has it not been escalated or reassigned?

• What is the closure evidence?

• What happens to cost, schedule, safety, quality, or start-up if it remains open for another week?

• Which downstream activities are assuming this item will close on time?

• Is this an isolated issue or part of a pattern across the project?

• Has the due date moved before, and what changed as a result?

• Does the contract allocate responsibility clearly, or does the project need an integration owner?

• Has operations accepted the closure basis, or has the project closed it internally?

• Are we managing the issue, or merely reporting it?

  
  

These questions change the conversation. They shift the team from status reporting to removing constraints.

Consider a shutdown project at a petrochemical facility. The tracker shows an open action to confirm crane pad bearing capacity. The owner is a lifting supervisor. The action is two weeks late. A normal review asks, “When will this be closed?” The answer is, “Next week.”

A better review asks, “Can the lifting supervisor close this?” The answer may be no. The owner needs geotechnical records, civil engineering review, operations approval to excavate trial pits, and, if required, a budget for ground improvement. Now the project can act. It can assign accountability to the shutdown manager, bring in civil engineering, protect the crane mobilization date, and escalate if operations block access.

The action did not need more chasing. It needed real ownership.

Or take a metro infrastructure program. A systems integration issue sits between signaling, power, telecoms, and civil works. The register names the systems interface lead. The lead coordinates meetings but cannot direct contractors, approve design changes, or alter access windows. Testing dates slip because each package claims partial readiness. Effective ownership may need to sit with the integration director or delivery authority, with contractual and schedule power to force alignment.

Again, the register was populated. The project was still exposed.

The Professional Takeaway

Complex projects need registers. They provide memory, structure, and visibility. But a register is not a control unless the named owner can act.

Real accountability means the owner has authority, resources, competence, information, access, escalation rights, and responsibility for evidenced closure. Without those conditions, risks remain unmanaged, actions age, decisions drift, interfaces fail, rework grows, commercial exposure increases, and start-up readiness suffers.

The practical test is simple: if a critical item is still open, do not ask only whose name is beside it. Ask whether that person can actually close it. If they cannot, the project does not have an owner. It has a name in a register.