Defence and space manufacturing is not simply manufacturing. It is project execution in which manufacturing is nested inside a larger contractual, engineering and delivery scope.
A radar installation, mission-support facility, satellite integration structure, specialised ground-support system or engineered module is rarely the output of a repetitive production line operating independently of a project.
It exists because a specific project requires it.
That distinction changes the ERP logic completely.
In conventional manufacturing, the Bill of Materials (BoM) is usually the dominant structure: what components are required to manufacture a product?
In project-based manufacturing, another structure sits above it: the contractual and project scope. Depending on the commercial model, this may be represented by a Bill of Quantities (BoQ), schedule of values, contract line items, work packages or another structured scope definition.
For simplicity, this article uses BoQ as that commercial/project anchor.
The critical requirement is therefore not merely managing a BoM.
It is creating a digital chain that can translate:
Project Requirement → BoQ → WBS → Fabricated Product → BoM → Production Operations → Quality → Assembly/Installation → Cost → Progress
That is the difference between manufacturing software and a true project-based manufacturing ERP.
DANAOS ProjectVIEW ERP already models this relationship through its Project-Based Manufacturing ERP architecture, where a project BoQ can be transformed into production-ready BoMs and routings while remaining connected to WBS activities and cost codes. danaos-projects.com
What is project-based manufacturing in Defence and Space?
Project-based manufacturing is the production of engineered items specifically required to fulfil a project, contract or mission scope rather than to replenish a standard inventory of repetitive products.
This commonly overlaps with engineer-to-order and low-volume/high-complexity manufacturing.
The important distinction is economic as much as technical.
The manufactured item does not exist as an isolated product.
It exists inside the economics and schedule of the project that requires it.
NASA’s Systems Engineering Handbook reflects the broader systems-engineering reality of the space sector: development and product realization are iterative, multidisciplinary processes extending across the project lifecycle. NASA specifically highlights Model-Based Systems Engineering as a mechanism for improving product development and delivery. NASA
Similarly, European space programmes operate within the European Cooperation for Space Standardization framework, which explicitly integrates project management, engineering, industrialisation, production, maintenance and product assurance. Its configuration-management standard requires maintaining the relationship between product characteristics, approved requirements and the evolving as-built configuration throughout the lifecycle. ECSS
This is exactly why conventional departmental separation becomes problematic.
Engineering cannot finish its job and simply “throw the BoM over the wall” to production.
Production cannot manufacture without understanding project milestones.
Procurement cannot buy solely against inventory demand.
Quality cannot operate separately from configuration.
And Finance cannot understand true project performance if fabrication costs are detached from the project deliverable that caused them.
The missing translation: BoQ → BoM
This is the architectural problem that deserves more attention.
Imagine a project BoQ contains a requirement for an engineered assembly.
From the project’s perspective, that assembly may appear as one material or product required to complete one BoQ design scope.
But internally, that “material” is not necessarily something purchased from a catalogue.
It may itself be a project-based manufactured product.
That product expands into its own BoM consisting of multiple raw materials, bought-out components, consumables and semi-finished items.
- It also requires labour.
- It consumes machinery, tools and production capacity.
- It follows manufacturing operations.
- It passes through inspection and quality gates.
Certain processes may take place internally.
Others may be outsourced to specialised suppliers or subcontractors.
And when completed, the manufactured output collapses back into a single identifiable product that is consumed by the parent project scope during assembly, erection, integration or installation.
This is nested project manufacturing.
ProjectVIEW already supports the underlying logic through BoQ-to-BoM manufacturing, production phases and resource allocation and through its dedicated Materials & Production Management module. Production phases can be sequential or parallel, distinguish inputs, semi-finished products and outputs, allocate labour and machinery, incorporate subcontractors, calculate final production-unit cost and compare planned versus actual resources and costs. Danaos Projects
That creates a much richer relationship than:
Product → BoM
It becomes:
BoQ Scope → WBS Activity → Manufactured Product → BoM + Routing + Resources + Quality → Finished Product → Parent BoQ
And every layer remains economically attributable to the same project.
A manufactured product is also a project resource
This concept is particularly important.
A manufactured assembly can simultaneously be:
an output of one production process and an input resource of another project process.
Consider an engineered support module fabricated for a defence programme.
At the project level it may be a material/resource required for a defined BoQ work package.
Internally, however, ProjectVIEW can explode that product into a manufacturing BoM.
Its fabrication may require structural materials, bought-out components, specialist labour, welding or machining equipment, quality inspections and perhaps outsourced finishing or specialist testing.
Once completed and accepted, the finished assembly is returned to the parent project as a controlled, identifiable resource ready for installation.
The important point is that its cost has not disappeared into a generic factory overhead account.
Its labour hours, machine time, materials, subcontracted operations and production progress remain attributable to the project requirement that created it.
That is project cost control reaching inside manufacturing.
Defence example: one BoQ requirement, an entire production project underneath
Consider a defence contractor delivering an integrated mission-support facility.
One contractual scope item may require an engineered equipment enclosure or structural module.
From the parent project perspective, management wants to know:
- Is it ready?
- When will it be installed?
- What did it cost?
- Has it passed inspection?
- Is it using the approved configuration?
But underneath that apparently simple item sits a mini-project.
- Engineering releases drawings and specifications.
- The system generates or associates the relevant BoM and routing.
- Procurement secures required components.
- Production allocates shop capacity, labour and machinery.
- Selected specialist processes can be outsourced.
- Quality records inspections, non-conformances and approvals.
- Configuration changes are version-controlled.
The finished item is serialized or otherwise identified, transferred to the required yard or site, and ultimately consumed by its parent installation activity.
This is where the ProjectVIEW principle of connecting BoQ ↔ WBS ↔ Cost Codes becomes particularly powerful: the commercial requirement, schedule, production resources and actual costs are not different realities maintained by different departments.
They become different views of the same project reality.
DANAOS applies comparable fabrication logic today in complex project environments such as shipbuilding and shipyard operations, where fabrication, materials, labour, subcontractors, design information, production and cost are already intertwined. Danaos Projects
Space example: manufacturing cannot be separated from configuration and quality
Now consider a specialised ground-support structure or integration frame produced for a space programme.
Its BoM may contain standard items, specially manufactured components and precision parts obtained from specialist suppliers.
- Some production takes place in the manufacturer’s shop.
- Another operation may be outsourced.
- Final assembly may occur in a different facility.
- Acceptance may require inspection records, certificates, approved drawings and a precise as-built configuration.
This is why quality cannot simply be another ERP module sitting beside manufacturing.
Quality is part of the production state.
The European space standards make this relationship explicit: ECSS maintains dedicated requirements for space product assurance, quality assurance for space projects and configuration/information management. ECSS
A manufactured item cannot truthfully be reported as “complete” merely because fabrication operations reached 100%.
- It may be physically manufactured but not inspected.
- Inspected but subject to a non-conformance.
- Accepted but not released.
- Released but not transported.
- Delivered but not integrated.
- Integrated but waiting for final verification.
Each state means something different to Production, Quality, Planning, Commercial Management and the customer.
A serious ERP must understand those differences.
In Defence and Space, real-time information is not enough. It must be high-confidence information.
This is perhaps the most important distinction.
Executives often ask for “real-time dashboards.”
But speed without confidence is dangerous.
If a programme director is told that an assembly is 82% complete, what exactly does 82% mean?
- Hours consumed?
- Operations completed?
- Physical quantities produced?
- BoM items completed?
- Quality-approved output?
- Earned value?
- Shop-floor self-reporting?
The objective should therefore be high-confidence real-time progress.
A progress statement should be supported by evidence from the processes underneath it: manufacturing operations, consumed materials, labour transactions, machine activity, subcontractor milestones, inspection status, approved documentation and schedule position.
The U.S. Digital Engineering Strategy calls for authoritative sources of system data and models spanning disciplines and the lifecycle. It explicitly links such an authoritative source of truth to managing cost, schedule, performance and risk, while stressing that stakeholders require the right information at the right time. Assistant Secretary of War
That principle translates directly into project-based ERP.
Progress should not merely be reported. Progress should be proven.
Where AI changes Defence and Space project manufacturing
ProjectVIEW ERP provides the structured process and data layer. DANAOS describes ProjectVIEW OS and ProjectVIEW AI as an intelligence layer operating over structured BoQ, WBS, cost and operational information, with published areas including cost-deviation prediction, delay and productivity forecasting, risk scoring, procurement intelligence, anomaly detection and AI-assisted workflows. Danaos Projects
For Defence and Space manufacturing, this opens several particularly valuable use cases:
- AI-validated progress. An AI agent can compare declared production progress against BoM completion, consumed materials, labour transactions, machine activity, subcontractor status and passed quality gates. Instead of simply repeating “75% complete,” it can flag that only 61% of the evidence supports the reported state and identify what is missing.
- AI schedule and production-risk forecasting. If a specialist component is delayed, one machine is unavailable and a mandatory inspection has moved, AI can evaluate their combined effect on the production routing, WBS activity and ultimate project milestone—rather than analysing each problem in isolation.
- AI quality and configuration intelligence. Document intelligence can identify missing inspection records, inconsistent drawing revisions, incomplete certificates, recurring non-conformance patterns or transactions executed against superseded information. The objective is not to replace engineering judgement but to surface contradictions before they propagate downstream.
- AI procurement and make-or-buy intelligence. Because a fabricated product can be produced internally or outsourced, AI can compare internal capacity, machine availability, historical productivity, supplier lead times, procurement commitments and forecast cost before management decides whether to make, subcontract or purchase.
- AI executive and stakeholder briefings. An authorised stakeholder could ask: What is the current approved status of Package X, what is blocking completion, what is its latest forecast cost and which evidence supports that assessment? The AI response can be generated from structured ERP transactions and linked evidence rather than manually assembled emails and spreadsheets.
The critical word throughout is evidence.
AI becomes substantially more valuable when it reasons over controlled operational data rather than trying to reconstruct project truth from disconnected documents.
Confidentiality changes how collaboration must work
Defence and space programmes introduce another requirement: not every stakeholder should see everything.
- Real-time visibility does not mean unrestricted visibility.
- Programme leadership may need cost and schedule exposure.
- Production management needs detailed manufacturing status.
- Quality teams need inspection and non-conformance information.
- Specialist contractors may require only their assigned work package.
- Customers may require approved milestone status without access to internal commercial or supplier information.
The correct architecture is therefore:
one source of truth, multiple authorised views.
In U.S. environments handling Controlled Unclassified Information, NIST SP 800-171 Rev.3 provides an important benchmark: it addresses protection of CUI in non-federal systems and includes access control, least privilege, auditability, system integrity and protection of information in transit and at rest. It specifically requires limiting users and processes to the access necessary for their assigned functions and maintaining detailed audit records. NIST Publications
This does not mean that using an ERP automatically establishes compliance with NIST, ECSS, export-control rules or a particular defence contract. Compliance must always be validated against the specific programme, jurisdiction, data classification and contractual obligations.
But it defines the correct architectural direction.
Project information should be distributed according to identity, role, responsibility and need-to-know.
Notifications to sensitive stakeholders should ideally announce that a significant event exists and provide authenticated access to the authoritative record—not unnecessarily distribute confidential technical or commercial information through uncontrolled channels.
ProjectVIEW’s integrated CDE already supports document versioning, approvals, history and audit trails, while its manufacturing environment connects production activity to the originating project structure. ProjectVIEW document control and CDE capabilities Danaos Projects
From digital thread to economic thread
The Defence and Space sectors already understand the digital thread.
Industry technology providers describe it as the continuous connection between engineering, manufacturing, production and lifecycle information. Siemens, for example, positions the aerospace and defence digital thread around programme management, engineering, supply chain, production and product support. Siemens Resources
But there is another thread that is just as important:
the economic thread.
- A design decision has a cost.
- A BoM revision has a procurement consequence.
- A late component has a schedule consequence.
- Machine downtime changes production economics.
- A rejected part consumes labour and materials without producing accepted progress.
- An outsourced process creates commitment, schedule and quality dependencies.
- A configuration change can invalidate work already performed.
ProjectVIEW’s project-based logic connects that physical and engineering reality back to the BoQ, WBS and Cost Codes.
That means the digital thread does not end at engineering or the shop floor.
It continues into budget, commitments, actual cost, earned value, project progress and financial performance.
Why conventional manufacturing ERP is not enough
A conventional manufacturing ERP may be very good at answering:
What does it take to manufacture Product A?
Defence and Space project manufacturing requires a broader question:
Why are we manufacturing Product A, for which contractual requirement, against which schedule milestone, using which resources, under which configuration, at what cost, with what quality status, and how does its completion affect the parent programme?
That question crosses engineering, project controls, procurement, production, quality, subcontracting, logistics and finance.
It cannot be answered reliably when those functions live in disconnected systems.
And it cannot be answered by AI if AI itself has no structured operational truth underneath it.
This is the significance of ProjectVIEW’s BoQ-to-BoM project manufacturing model.
The BoM explains how the product is built. The WBS explains when it must be built. The BoQ explains why the project needs it and where its economic value sits. Cost Codes explain what its execution is costing the enterprise. Quality and configuration records establish whether the output is actually acceptable.
Project-based manufacturing connects all five.
AI can then interpret the resulting digital fabric.
The Defence & Space manufacturing ERP should become a command system, not a database
For complex Defence and Space programmes, the objective is not another system of records.
It is a controlled project-manufacturing command environment.
One capable of following a requirement from contractual scope to engineering definition; from BoQ to BoM; from procurement to fabrication; from internal shop to external specialist contractor; from production to inspection; from finished component to assembly and erection; and from physical execution back to time, cost, quality and programme performance.
In these environments, a manufactured item may be a product today, a project resource tomorrow and part of a much larger system after installation.
The information system must understand all three states.
That is project-based manufacturing.
And that is precisely the type of complexity for which an integrated, project-centric ERP such as DANAOS ProjectVIEW ERP is architected.
FAQ: Defence & Space Project-Based Manufacturing
What is the difference between a BoQ and a BoM?
A BoQ represents project or contractual scope and quantities, while a BoM describes the components required to manufacture a product. In project-based manufacturing, the important capability is maintaining the relationship between them so that manufactured products remain linked to the project requirement, WBS activity, budget and cost structure that created the demand.
What does BoQ-to-BoM mean?
BoQ-to-BoM means taking a project deliverable or fabricated item defined within the commercial/project structure and expanding it into the materials, components, operations and resources necessary to manufacture it. Once completed, the manufactured product returns to the parent project as a controlled resource for assembly, erection or installation.
Why is project-based manufacturing important for Defence and Space?
Because many Defence and Space deliverables are engineered for a specific programme, configuration or mission rather than produced solely as repetitive stock. They therefore require simultaneous control of engineering, manufacturing, project schedule, quality, procurement, subcontracting and cost.
How can AI improve Defence and Space manufacturing ERP?
AI can compare reported progress with operational evidence, predict production and procurement risks, detect anomalies, review documentation, identify configuration inconsistencies and provide authorised stakeholders with evidence-based project briefings. Its reliability depends heavily on the quality and structure of the ERP data underneath it.
Why is secure stakeholder visibility important?
Because sensitive programmes require both rapid information flow and strict information control. The objective is not to expose all project information to everyone, but to give each authorised stakeholder the right verified information, at the right time, for the right purpose.
