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 does it take 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.
Instead, 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 users can transform a project BoQ into production-ready BoMs and routings that remain 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.
In practice, this commonly overlaps with engineer-to-order and low-volume/high-complexity manufacturing.
However, the important distinction is economic as much as technical.
In other words, the manufactured item does not exist as an isolated product.
Instead, 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. In addition, 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.
Similarly, production cannot manufacture without understanding project milestones.
Procurement cannot buy solely against inventory demand.
Likewise, quality cannot operate separately from configuration.
And Finance cannot understand true project performance if fabrication costs sit apart from the project deliverable that caused them.
The missing translation: BoQ → BoM
This is the architectural problem that deserves more attention.
For example, 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.
Instead, it may itself be a project-based manufactured product.
In turn, that product expands into its own BoM consisting of multiple raw materials, bought-out components, consumables and semi-finished items.
- It also requires labour.
- In addition, it consumes machinery, tools and production capacity.
- It follows manufacturing operations.
- Finally, it passes through inspection and quality gates.
Certain processes may take place internally.
Others may go to specialised suppliers or subcontractors.
Finally, once complete, the manufactured output collapses back into a single identifiable product that the parent project scope consumes during assembly, erection, integration or installation.
We call this 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 and can distinguish inputs, semi-finished products and outputs. They can also 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
Instead, 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.
For example, 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.
In turn, 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 the assembly passes acceptance, the team returns it 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.
Instead, 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
For example, 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 the team install it?
- What did it cost?
- Has it passed inspection?
- Is it using the approved configuration?
But underneath that apparently simple item sits a mini-project.
- First, engineering releases drawings and specifications.
- Then the system generates or associates the relevant BoM and routing.
- Procurement secures required components.
- Production allocates shop capacity, labour and machinery.
- Specialist suppliers can take on selected processes.
- Quality records inspections, non-conformances and approvals.
- The system version-controls configuration changes.
Finally, the team serializes or otherwise identifies the finished item and transfers it to the required yard or site. Its parent installation activity then consumes it.
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 is inseparable 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.
- A specialist supplier may perform another operation.
- 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.
Instead, 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
Therefore, no one can truthfully report a manufactured item as “complete” merely because fabrication operations reached 100%.
- For example, it may be physically complete 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.
Therefore, 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 report tells a programme director 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.
Instead, evidence from the underlying processes should support every progress statement: manufacturing operations, consumed materials, labour transactions, machine activity, subcontractor milestones, inspection status, approved documentation and schedule position.
For example, 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.
Teams should not merely report progress. They should prove it.
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. Published areas include 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 arrives late, 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.
How can AI support procurement and stakeholder decisions?
- AI procurement and make-or-buy intelligence. Because the company can produce a fabricated product internally or outsource it, 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 can then generate its response 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
However, this does not mean that using an ERP automatically establishes compliance with NIST, ECSS, export-control rules or a particular defence contract. Organisations must always validate compliance against the specific programme, jurisdiction, data classification and contractual obligations.
But it defines the correct architectural direction.
Therefore, the system should distribute project information according to identity, role, responsibility and need-to-know.
For example, notifications to sensitive stakeholders should ideally announce that a significant event exists and provide authenticated access to the authoritative record. They should 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.
- Similarly, 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.
As a result, the digital thread does not end at engineering or the shop floor.
Instead, 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?
By contrast, 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.
However, no one can answer it reliably when those functions live in disconnected systems.
Nor can AI answer it 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 to build the product. Then the WBS explains when the team must build it. 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.
Instead, 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. It should also follow work from internal shop to external specialist contractor and from production to inspection. Finally, it should trace work 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.
Therefore, the information system must understand all three states.
That is project-based manufacturing.
And that is precisely the type of complexity that an integrated, project-centric ERP such as DANAOS ProjectVIEW ERP exists to handle.
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 engineers design many Defence and Space deliverables for a specific programme, configuration or mission rather than for 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. However, 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.
