15 — Organisation, authority and accountability

A cooling module can have competent mechanical, electrical and supplier engineers yet still fail at its interfaces. Each team may complete its own task while nobody has authority to decide compatibility, accept early commitment or resolve a disagreement. An effective organisation assigns decisions as carefully as it assigns work.

Responsibility means an obligation to perform work. Authority means permission to make a defined decision. Accountability means being answerable for its outcome and evidence. These are working distinctions: a person can prepare an assessment without authority to approve it, and a manager can own delivery without authority to waive a technical requirement. A useful responsibility model names the decision, its scope, required contributors, evidence and escalation route.

The operating model below assigns these rights by product, information and commitment boundary. Role titles can vary between organisations. Combining roles in a small team is possible where competence and required independence permit it; distributing them across thousands of people requires explicit delegations. Neither arrangement removes the underlying decisions.

Chief engineer and technical authorities

The chief engineer owns the integrated technical coherence of the vehicle within the programme’s agreed technical mandate. This includes resolving cross-system trade-offs, maintaining a credible technical baseline and ensuring that significant technical uncertainty reaches the appropriate decision. The chief engineer does not acquire unlimited commercial, contractual or regulatory authority through seniority.

System authorities own system-level performance and allocation. The cooling authority assesses thermal demand, available capacity and relevant verification. The electrical authority assesses power distribution, protection and electrical interfaces. Each needs access to the requirements, architecture, analyses and product configurations supporting its conclusions. An authority cannot responsibly sign a release while lacking the evidence on which adequacy depends.

Design authorities own defined product-definition boundaries. A chassis authority controls mounting definition; a harness authority controls its electrical and physical definition; a supplier may retain authority over its cooling module internals. These boundaries must be documented in contracts and internal delegations. Ownership of a model file does not by itself establish design authority.

System and design authority differ because behaviour crosses item boundaries. The radiator, fan, ducting and engine operating conditions jointly determine cooling performance. No single component drawing can own that conclusion. The system authority therefore governs performance allocation and evidence while the design authorities govern their respective definitions. Changes that cross the allocation require coordinated assessment.

Integration makes compatibility a decision

Integration owns the coordination of interfaces and the evidence that separately developed elements work together in the intended configuration. NASA’s interface guidance identifies controlled characteristics and compatibility as continuing concerns; its product-integration guidance connects configuration, integration preparation and procedures. These sources support the need for explicit interface work, without prescribing the role structure used here. NASA interface management, NASA product integration.

For the cooling module, integration identifies the mechanical mounting, coolant and electrical boundaries, brings both endpoint authorities together and records the agreed interface baseline. It also identifies who will demonstrate compatibility and at which assembly stage. Integration must have a route to prevent release of an unresolved incompatible package; otherwise it becomes a meeting service with responsibility but no effective authority.

Integration does not silently redesign either supplier’s endpoint. If agreement cannot be reached within delegated bounds, it presents alternatives to the chief engineer and programme authority. The alternatives should state performance, schedule, cost, verification and support consequences. An unresolved interface must remain identifiable rather than disappearing into a general action list.

Configuration management and information ownership

Configuration management maintains the discipline connecting identities, revisions, baselines, applicability, changes and status evidence. It ensures that decisions refer to reproducible information and that released packages can be distinguished from working data. NASA describes configuration identification, control, status accounting and verification as connected activities. Its institutional guidance is context, not a claim that this vehicle programme adopts NASA procedures. NASA configuration management.

Configuration management can reject an incomplete release package or return ambiguous applicability for correction. It does not thereby become the technical approver of a cooling calculation. The technical authority establishes adequacy; the configuration function ensures that the decision and its information can be controlled and recovered. A release signature should make this distinction visible.

Every controlled information class needs an owner for meaning as well as a system administrator. Requirements ownership includes disposition and baseline context, not merely DOORS access. Product-definition ownership includes interfaces and revision decisions, not merely NX or Capital file permissions. Manufacturing-plan ownership includes executable operations and reconciliation with engineering intent. Execution-record ownership includes the accuracy and correction history of reported physical work.

Manufacturing and procurement

Manufacturing engineering owns the translation of product definition into a feasible manufacturing plan: assembly boundaries, material and operation relationships, resources, access, sequence and required inspection. It can challenge an incomplete definition and reject an unexecutable sequence. It cannot alter technical requirements informally to make production easier. Where a different method changes the product or its assurance basis, the relevant technical authority must decide.

Production management owns execution against authorised instructions, recording progress and escalating conditions that prevent correct work. Operators and inspectors need a clear stop route for ambiguity, unsuitable material or unsafe conditions. Restart authority depends on the issue: production can resolve a resource problem within its remit, while a design incompatibility requires technical disposition.

Procurement owns commercial supplier commitments within its delegation, informed by technical requirements and programme priorities. It establishes whether a supplier notification changes an order, contract or delivery commitment. Supplier technical management owns the adequacy and completeness of technical exchanges and assessment of supplier evidence. These roles must coordinate: a buyer cannot accept an incompatible substitution solely because it is available sooner, and an engineer cannot commit the company to an unapproved commercial variation.

Programme, quality, assurance and support

Programme management owns integrated delivery planning and trade-offs within authorised scope. It makes resource and sequencing decisions using technical advice and explicit exposure. It should not approve early fabrication merely by declaring schedule priority. The decision requires an adequate technical basis, a feasible manufacturing sequence and an accountable response if assumptions fail.

Quality owns defined quality-system activities, inspection governance and nonconformance coordination. Technical disposition, contractual concession and acceptance may belong to different authorities. An inspector records whether specified criteria were met; that record does not grant permission to change the criteria. Quality needs independence sufficient to report adverse evidence without pressure to disguise it as progress.

Assurance provides challenge against the applicable assurance plan and obligations. Its remit, independence and escalation rights must be defined for the programme; no universal certification regime is assumed. Where evidence is inadequate, assurance should identify the claim, gap and consequence rather than issue an unexplained veto. Equally, programme pressure cannot substitute for evidence required by an external obligation.

Support represents maintenance access, replaceable-item strategy, diagnostics, spares and field configuration. It participates before design commitments lock these decisions in. A connector substitution may be compatible in manufacture yet create confusing service identification or unavailable repair tooling. Support therefore contributes to assessment and owns the relevant service implementation tasks, while design authorities retain the technical decisions within their boundaries.

Delegation and escalation

A delegation should specify the decision class, product and information scope, competence requirements, required concurrence, evidence, exclusions and escalation triggers. It also needs a named deputy and a way to withdraw authority when circumstances change. Access to an approval button must follow delegation rather than define it.

Avoid arbitrary universal numeric thresholds. A low-cost connector can affect critical compatibility across many vehicles, while an expensive procurement may be routine within an established specification. Delegated limits should consider technical novelty, interface impact, affected commitments, assurance obligations, uncertainty and reversibility as well as financial authority. Programme-specific financial limits belong in the organisation’s actual authority schedule.

Escalation is required when a decision crosses delegated scope, contributors disagree on a material issue, evidence contradicts the assumed basis, or an obligation cannot be met. The escalation package states the question, current baseline, options, consequences, recommended action and time by which a decision matters. It also states what work may continue while the issue is unresolved. Escalation should preserve local progress where justified without concealing the blocked dependency.

A connector dispute during a customer change

Consider a supplier replacing the fan connector while a customer hot-climate change is being assessed in DOORS. Vehicle 01 is in build; Vehicle 02 has major components ordered; Vehicles 03–04 remain in planning. The change coordinator links the notifications without assuming they have one disposition. Cooling assesses performance, electrical engineering assesses demand and termination compatibility, and integration governs both mating endpoints and installation context.

Manufacturing establishes which operations are complete on Vehicle 01 and whether replacement remains accessible. Procurement confirms supplier progress and order options for Vehicle 02. Programme management compares sequencing and exposure. Quality identifies inspection implications, and support assesses spares and service identification. The customer’s authorised representative decides any required contractual variation; receipt of the DOORS revision has not made that decision automatically.

Suppose the supplier claims the new connector is equivalent but the harness authority lacks evidence for the mating arrangement. Integration records the compatibility gap and holds the affected release. Procurement can seek the missing supplier evidence and preserve commercial options, but cannot declare technical equivalence. The chief engineer resolves a cross-system technical trade if necessary. The programme authority decides among technically defensible delivery options within its mandate.

The final decision identifies vehicle applicability and implementation tasks. Vehicle 01 might retain an authorised earlier arrangement; later vehicles might use the new one. Actual installation and inspection evidence establishes what each vehicle contains. The change closes only when its defined implementation boundary is satisfied, as explained in chapter 13.

Organisation in the information systems

NX, Capital, Teamcenter and SAP support different parts of this work, while DOORS contains customer requirements. The operating architecture needs role-scoped access, identifiable decision records, controlled delegation and traceable exchanges. These are requirements for configuration and integration, not assertions that platform installation creates the organisation automatically.

Workflow should show what each signatory is deciding. A technical approval, a release check, a resource commitment and a contractual agreement need distinct meanings even where one person performs several roles. Service accounts can transfer data but should not appear as accountable human decision-makers. Failed exchanges must have an owner and recovery route rather than becoming a dispute between system teams.

At major defence or infrastructure scale, millions of occurrences, multi-year manufacture and thousands of participants make a single central approval queue impractical. Local authorities need stable boundaries, common evidence rules and visibility of cross-boundary consequences. Periodic review of delegations, disputed decisions and recurring interface failures reveals whether the organisation is working. A responsibility chart is useful only when people can use it to obtain a timely, competent decision and recover the evidence supporting it.