Governance, Roles, and Decision Rights

3.1 Building the Facility Move Leadership Team

The facility move leadership team should be small enough to make decisions and broad enough to represent the functions that can make or break the move. In many organizations, the instinct is to appoint a project manager and ask that person to “coordinate the move.” Coordination is necessary, but it is not sufficient. A facility move requires executive sponsorship, operational ownership, technical leadership, functional accountability, and a mechanism for resolving trade-offs quickly.

The first role is the executive sponsor. The sponsor is not the person who attends periodic updates and gives encouragement. The sponsor is the accountable business leader who owns the move outcome. This person protects the business case, approves material trade-offs, removes organizational barriers, and makes sure functions provide resources when the project competes with normal operations. The sponsor should be senior enough to decide between cost, timing, risk, service, and people implications without repeatedly seeking permission from others.

The second role is the move leader. This person runs the integrated move effort day to day. The move leader may come from operations, supply chain, engineering, transformation, or a dedicated PMO, but the most important requirements are credibility, follow-through, cross-functional judgment, and comfort with ambiguity. The move leader does not need to personally solve every technical issue. The move leader must make sure every issue has an owner, every dependency is visible, every decision is prepared, and every workstream is moving against the same plan.

The third role is the future-state operating owner. In some moves, this is the general manager, plant manager, distribution center leader, office leader, or head of the receiving site. This role is often underweighted. The project team may focus on moving equipment and people, while the operating owner is left to inherit the result. The future-state operating owner should have a strong voice in layout, staffing, process design, startup criteria, performance metrics, and stabilization priorities. A facility is ready only when the operating owner can run it.

The fourth role is the current-site owner. This leader maintains performance at the existing site during transition and supports decommissioning, asset preparation, employee communication, inventory control, records management, and final exit. In consolidations, absorption moves, and split moves, current-site and future-site owners may have different incentives. Governance must make those incentives explicit and aligned.

The fifth role is the functional leadership group. Engineering, facilities, IT, HR, supply chain, quality, safety, finance, legal, procurement, commercial, and communications may all need defined leadership roles. Not every function needs a full-time leader on every move, but every material function needs a named accountable person. A “shared mailbox” or “the IT team” is not an owner. A named individual with authority, capacity, and escalation access is an owner.

The leadership team should be scaled to move complexity. A small office relocation may need only a few functional leads. A regulated manufacturing move may need dedicated leadership for engineering, validation, quality, safety, operations, maintenance, supply chain, finance, regulatory affairs, customer continuity, and workforce transition. The team should not be overbuilt, but it should not pretend a complex move can be governed as a simple facilities project.

The leadership team should also establish behavioral norms early. Single source of truth: the integrated plan, risk register, decision log, and status report are the official records. No silent surprises: workstream leaders escalate emerging problems before they become missed milestones. Decisions at the right level: teams solve what they can and escalate what requires cross-functional trade-offs or executive authority. Business continuity first: cost and schedule matter, but not at the expense of safety, compliance, or critical customer commitments.

3.2 Workstream Structure: Operations, Engineering, Facilities, IT, HR, Supply Chain, Quality, and Finance

Workstreams convert the move mandate into executable work. A workstream is not simply a topic area. It is a group of related decisions, tasks, dependencies, risks, and deliverables owned by a leader. The right structure allows each function to manage detail while keeping cross-functional dependencies visible to the central move team.

The operations workstream defines how work will run before, during, and after the move. It owns process mapping, production or service continuity, capacity planning, staffing requirements, operating procedures, shift design, startup sequencing, training needs, and stabilization priorities. In a manufacturing move, operations determine how production will be sequenced, when lines can stop, and what output is required during ramp-up. In a warehouse move, operations determine receiving, putaway, picking, packing, shipping, inventory control, slotting, and yard flow.

The engineering workstream owns technical feasibility and equipment readiness. It translates operating requirements into equipment moves, installation plans, utility requirements, foundations, equipment layouts, commissioning protocols, spare parts needs, and technical risk controls. Engineering should identify long-lead items, rigging constraints, special transport needs, machine leveling, calibration, safety guarding, and restart requirements. When engineering is brought in late, teams often discover that the layout cannot support the equipment or that utility upgrades require more time than the schedule allows.

The facilities workstream owns the building environment. This includes site access, construction coordination, space preparation, docks, doors, walls, floors, racking, offices, restrooms, parking, signage, security, cleaning, waste handling, fire protection, emergency systems, and landlord or property-manager coordination. Facilities are often the workstream closest to contractors and site-readiness issues. It must coordinate tightly with engineering because equipment installation depends on building readiness, and building modifications depend on equipment and process requirements.

The IT workstream owns digital and technology cutover. This includes networks, telecom, internet connectivity, servers, Wi-Fi, access control, cameras, printers, scanners, shop-floor devices, time clocks, conference rooms, cybersecurity, user access, system configuration, and master data. IT must also coordinate with operations and supply chain on transaction readiness. A new address, warehouse code, printer location, or scanner setup can disrupt startup as surely as a delayed machine move.

The HR workstream owns people transitions. This includes employee communication, role mapping, relocation, retention, hiring, onboarding, training coordination, labor relations, severance, policy changes, attendance expectations, benefits implications, and leadership alignment. HR should be engaged before rumors fill the vacuum. In moves that require new hiring, HR must also own the hiring funnel, start dates, training capacity, and readiness of supervisors.

The supply chain workstream owns materials, suppliers, carriers, inventory buffers, shipping lanes, receiving changes, customer delivery continuity, procurement coordination, and logistics cutover. Supply chain determines how inventory will be built, positioned, labeled, transferred, counted, and released. It communicates with suppliers and carriers, updates delivery instructions, and manages temporary complexity during phased moves.

The quality workstream owns process controls, documentation, inspection readiness, certification impacts, validation, deviations, records, audits, and release criteria. In regulated or quality-sensitive operations, quality cannot be added at the end as a signoff function. It must define what evidence is required to prove that the new site can operate correctly. This may include equipment qualification, method transfer, controlled document updates, training records, supplier qualification, product release rules, environmental monitoring, or regulatory notifications.

The finance workstream owns the economic view of the move. It tracks capital spend, operating expense, one-time costs, contingency, savings, stranded cost, depreciation, lease costs, tax impacts, insurance, asset write-offs, inventory implications, and business-case delivery. Finance should help leaders understand the cost of schedule choices. A delayed utility upgrade, extra month of duplicate operations, additional inventory buffer, or expedited freight plan may be justified, but it should be visible.

These workstreams should not operate as silos. Their interfaces are where problems usually emerge. Engineering needs facilities readiness. Operations needs HR staffing and IT transaction readiness. Quality needs engineering evidence and training records. Supply chain needs system master data and customer communication. Finance needs accurate forecasts from every function. The move leader’s job is to manage those interfaces with discipline.

3.3 RACI Model for a Facility Move

A RACI model clarifies who is responsible, accountable, consulted, and informed for important activities. It is not a substitute for judgment, and it should not become a massive spreadsheet that nobody uses. Its value is in preventing unclear ownership where unclear ownership would create risk. For a facility move, the RACI should focus on high-consequence decisions, cross-functional deliverables, regulatory or customer commitments, and work that otherwise falls between functions.

The definitions should be used consistently. Responsible: the person or team doing the work. Accountable: the single owner answerable for the outcome and final decision. Consulted: stakeholders whose input is required before action. Informed: stakeholders who need visibility after decisions or progress updates. Each activity should have one accountable owner. Multiple responsible contributors are common, but multiple accountable owners usually means no one is truly accountable.

The RACI should be built after scope definition and reviewed with functional leaders. If a leader is listed as accountable, that leader must understand the expectation and confirm capacity. A RACI that assigns accountability to people who have not agreed to it creates false confidence.

Illustrative Facility Move RACI Topics

• Move charter approval: executive sponsor accountable, move leader responsible, functional leaders consulted, steering committee informed.
• Future-state layout approval: future-site operating owner accountable, operations and engineering responsible, facilities, safety, quality, IT, and finance consulted.
• Equipment disposition decisions: operations accountable, engineering and finance responsible, maintenance, quality, procurement, and asset owners consulted.
• Utility readiness: facilities accountable, engineering responsible, operations, safety, landlord, contractors, and finance consulted.
• Customer transition communication: commercial or customer service accountable, supply chain responsible, operations, legal, finance, and communications consulted.
• Supplier delivery changeover: supply chain accountable, procurement responsible, operations, warehouse, finance, and systems teams consulted.
• Workforce transition plan: HR accountable, site leadership responsible, legal, finance, operations, and communications consulted.
• Go-live readiness decision: executive sponsor accountable, move leader responsible, workstream leads consulted, affected stakeholders informed.

A practical RACI should be revisited at major phase gates. During design, accountability may sit with engineering and operations. During equipment move, accountability may shift to engineering, facilities, and safety. During startup, accountability may shift to the operating owner. The model should reflect the reality of the phase rather than remain static for the sake of neatness.

3.4 Steering Committee Cadence and Escalation Paths

The steering committee is the senior decision body for the move. Its job is not to review every task. Its job is to make decisions, remove barriers, resolve trade-offs, confirm readiness, and hold the project to the mandate. A steering committee that only receives status updates is underused. A steering committee that dives into every action item becomes a bottleneck. The right cadence and agenda keep it focused on issues that require senior attention.

Cadence should match project phase and risk. During early scope definition, the steering committee may meet every two to four weeks. During detailed planning, weekly or biweekly meetings are often appropriate. During the final move window and startup, the cadence may increase to several times per week or even daily standups for a defined period. The cadence should intensify as decisions become more time-sensitive and reduce once stabilization is achieved.

The steering committee should receive a concise, decision-oriented packet before each meeting. The packet should include overall status, key milestones, critical path, budget view, top risks, open decisions, unresolved issues, upcoming readiness gates, and any support required. Color-coded status can help, but it should not replace narrative judgment. A green status that hides a critical unresolved dependency is worse than no status at all.

Escalation paths should be explicit. Workstream teams should know what they can decide independently, what must go to the move leader, what requires the steering committee, and what requires executive sponsor approval. The threshold should be based on consequence, not politics. Safety, compliance, customer commitments, material budget changes, critical-path delays, labor disruption, scope changes, and go-live readiness issues should have clear escalation rules.

Escalation should not be treated as failure. In well-run moves, escalation is a normal control mechanism. The problem is not that a workstream raises an issue; the problem is when it raises the issue after the decision window has closed. Leaders should reward early visibility and discourage “heroics” that hide risk until it becomes unavoidable.

A good escalation path includes four elements. Trigger: the condition that requires escalation, such as a missed readiness date or a safety concern. Owner: the person responsible for preparing the escalation. Decision body: the leader or forum empowered to resolve it. Required decision date: the date by which action is needed to protect the schedule or business outcome.

Standard Steering Committee Agenda

• Business continuity status: customer, production, service, inventory, people, and compliance risks.
• Milestone review: progress against critical path and upcoming readiness gates.
• Budget and business case: spend to date, forecast, contingency, and known cost pressures.
• Top risks and issues: current severity, mitigation progress, and required escalations.
• Decisions required: options, recommendation, impact, and deadline.
• Leadership actions: barriers the sponsor or steering committee must remove before the next meeting.
  
  

3.5 Decision Log and Issue-Resolution Template

Facility moves generate hundreds of decisions. Some are small and local. Others affect layout, budget, timing, safety, customer service, staffing, permits, systems, or future operations. Without a disciplined decision log, teams forget why choices were made, revisit settled topics, act on outdated assumptions, or discover too late that a decision was never actually approved.

The decision log should be simple, visible, and actively maintained. It should not be an archive created after meetings. It should be a live management tool used by the move leader and reviewed in governance forums. Every important decision should have a clear owner, due date, status, options considered, decision made, rationale, impact, and communication requirement. The log should distinguish between a recommendation, a verbal preference, and an approved decision. Only the last one should trigger execution.

Decision Log Template

• Decision ID: unique number or code for tracking.
• Decision title: short description of the decision required.
• Category: scope, layout, equipment, utilities, people, systems, quality, customer, supplier, finance, safety, or go-live.
• Decision owner: person accountable for preparing and securing the decision.
• Approver: person or forum with authority to approve.
• Decision needed by: deadline tied to schedule or business impact.
• Options considered: practical alternatives, including do-nothing where relevant.
• Recommendation: proposed path and rationale.
• Impact: effect on cost, schedule, risk, service, people, compliance, and future operations.
• Decision made: approved choice, date, and approver.
• Follow-up actions: required tasks, owners, and due dates.
• Communication required: stakeholders who must be informed.

Issues are different from decisions. A decision is a choice that must be made. An issue is a problem that must be resolved. Many issues require decisions, but they should still be tracked as issues because they have causes, owners, mitigation plans, severity, and target closure dates. A utility delay, permit risk, failed equipment test, customer pickup confusion, or contractor safety concern should not disappear into meeting notes.

Issue-Resolution Template

• Issue ID: unique number or code for tracking.
• Issue statement: concise description of what is wrong or at risk.
• Severity: impact level based on safety, compliance, customer, cost, schedule, or operational consequence.
• Owner: person accountable for resolution.
• Root cause or suspected cause: best current understanding of why the issue exists.
• Mitigation plan: actions required to reduce impact or eliminate the issue.
• Decision required: related decision, if any, including approver and deadline.
• Target closure date: date by which the issue must be resolved.
• Status: open, in progress, blocked, escalated, resolved, or closed.
• Evidence of closure: test result, approval, completed action, updated document, or stakeholder confirmation.

The move leader should review open decisions and issues frequently with workstream leads. The steering committee should review only those that require senior action, create material risk, or threaten key milestones. This keeps governance focused while preserving detailed control below it.

Mature move teams use decisions and issues to learn. Repeated late decisions may indicate unclear authority. Repeated blocked issues may indicate resource constraints. Repeated cross-functional issues may indicate weak interface management. Governance is about improving how the move is managed while there is still time to change the outcome.