On the day of delivery, the people most likely to appear in photos are usually the product, the customer, and the technical leaders. Once testing is completed, the shipping container is sealed, and the handover documents are signed, a product finally moves from the development site to the customer.
But outside the camera frame, many other tasks are still being completed. Procurement teams may just have finished tracking the last batch of components and their quality certificates. Warehouse personnel verify part numbers, quantities, and shelf-life requirements. Finance confirms payment milestones. Legal teams review acceptance clauses once again. Technical support teams ensure that power supplies, cooling systems, and test equipment are ready. Quality and product assurance personnel confirm that approved drawings and software versions are being used. Project managers continue closing remaining issues one by one.
Looking further back, even before a product has a drawing, the project may already be underway. Marketing and business teams are determining what customers are actually willing to pay for. Strategy teams are evaluating whether the project is worth the company’s investment. Financing teams are securing funds to support a long development cycle. Government affairs teams are coordinating facilities, applications, and external resources. Human resources teams are searching for people whose capabilities cannot easily be described by a standard job title.
A drawing may appear to belong to a single designer, but a delivery never belongs to only one discipline. Engineers solve the question of “whether the product can work”; the entire organization solves the question of “whether it can be delivered on time, in the correct condition, with complete evidence and according to contract requirements.”
This article is not intended to rank which function is more important. The “behind the scenes” work mentioned here simply refers to the many activities that never appear in product photos. Like research and development, manufacturing, and engineering, they are all essential parts of a project system.
For engineers, understanding how an organization operates from these perspectives helps build a stronger overall view. For those considering entrepreneurship, it is also worth asking whether they can bring together experts in all these areas—or whether they themselves can take on multiple roles during the early stages of a company.
1. How Many People Support an Engineer in Completing a Project?
There is no universal answer. In a mature aerospace organization, the same project may involve dozens of different roles directly or indirectly. In a startup, the same functions may be handled by fewer people, combined into multiple responsibilities, or outsourced to external partners.
The organization can become smaller, but the functions themselves do not disappear.
If there is no dedicated supplier management team, engineers may have to chase material deliveries themselves. If there is no configuration management specialist, project managers or quality personnel must maintain version control. If there is no equipment support team, test engineers must also take responsibility for facilities and equipment beyond the product itself.
Therefore, a more accurate question than “how many people stand behind a product” is:
How many different functions must work together for a product to successfully complete delivery?
China’s national standard GB/T 32451-2015 places aerospace project management within the entire project life cycle. GB/T 32305-2015 focuses on product assurance and the reliability of products meeting mission requirements. GB/T 19001-2016, the current Chinese national standard equivalent to ISO 9001:2015, treats quality management as a set of interconnected processes rather than merely final inspection.[1][2][3]
NASA’s Systems Engineering Handbook describes engineering activities as interconnected processes including system design, product realization, and technical management across project phases. Product realization involves not only manufacturing, but also procurement or reuse, integration, verification, validation, and transition. In other words, transforming a requirement into a delivered product has always been a cross-disciplinary and cross-organizational systems engineering effort.[4][5]
Figure 1: Nine interconnected chains operating simultaneously during a delivery process
Source: Illustration created by the author
2. A Project Has Been Running Long Before the First Drawing Appears
Marketing and Business Development: Turning “Interest” into an Executable Requirement
The input received by engineers is often an already-processed set of requirements: how large the product should be, what performance it should achieve, when it should be delivered, and what environment it will operate in.
However, the original customer request may have been much simpler: “I need something lighter,” “I need something faster,” or “I need lower costs.”
The role of marketing and business teams is to identify the actual application scenario, purchasing capability, competitive landscape, and procurement process, then work with technical teams to transform vague expectations into clear boundaries.
This is not simply about “winning an order.” If a contract promises a certain result but the technical solution can only guarantee performance under specific conditions; if a customer treats a planning milestone as a guaranteed delivery date; or if acceptance criteria do not correspond to a valid test method, the conflict does not disappear. It is merely postponed until the most expensive stage of delivery.
The first alignment between business and engineering is essentially the earliest form of interface control in a project.
Strategy, Financing, and Government Affairs: Giving a Project Time, Resources, and Room to Survive
Aerospace projects often require long development cycles and significant upfront investment. Revenue and expenditure rarely occur at the same time.
Strategy teams determine whether a technology should become a customized project, a standardized product, or a long-term platform. Financing and investor relations teams explain the technical roadmap, milestones, funding requirements, and risks, ensuring that the company can continue development and delivery before products generate revenue.
Financing is not simply about putting money into an account. It is effectively purchasing time for the technical team to experiment, improve, and overcome uncertainty.
Government affairs work is also more than applying for subsidies. Factory site selection, industrial support, project registration, talent policies, testing conditions, and communication with local authorities can all affect whether a project can move forward smoothly.
Different companies may divide these responsibilities differently, but the common goal is the same: transforming external rules and resources into conditions that the company can execute.
Finance, Legal, and Intellectual Property: Placing Ambitions Within Boundaries
Finance teams answer more than the question of “how much money remains.” They also manage how project budgets are allocated, when cash flows out, when long-lead materials need to be paid for, how costs are recorded, and how invoicing matches revenue collection.
A technical solution that is feasible on paper does not necessarily mean the company’s cash flow can support it. A low purchase price does not necessarily mean the total cost remains low after considering inventory, rework, and delays.
Legal teams focus on contract responsibilities, acceptance conditions, change mechanisms, confidentiality obligations, and liability boundaries. Intellectual property teams distinguish between existing technologies, newly created project results, publicly releasable information, and information requiring protection.
If technological innovation is not properly documented and protected, it may lose commercial value or create ownership disputes during cooperation.
Figure 2: Relationship between project stages and roles from requirement to delivery
Source: Illustration created by the author
3. After a Project Starts, Who Brings Everyone onto the Same Page?
Project Management and Planning: Managing Commitments, Not Spreadsheets
Customers may want earlier delivery. Engineers may need more time for validation. Procurement teams face actual supplier lead times. Manufacturing teams need stable drawings. Finance teams have cash-flow constraints. Test facilities have other projects waiting in line.
The value of a project manager is not simply reminding everyone about deadlines every day. It is integrating scope, technical status, schedule, cost, resources, risks, and interfaces into a single decision-making framework.
For example, a temporary change to a connector model may appear to be only a material substitution. In reality, it may affect electrical interfaces, mechanical installation, thermal design, procurement lead times, inventory disposition, test coverage, drawing revisions, and customer delivery documents.
Project management ensures that every impact has an owner, a deadline, and evidence of closure. Without this central coordination, each department may complete its own tasks while the overall project still fails to achieve delivery.
Human Resources, Administration, IT, and Security: Creating the Conditions for Execution
Projects do not simply require “engineers.” They require people with specific experience in materials, manufacturing processes, software, testing, or systems engineering.
Human resources teams handle recruitment, staffing, training, performance management, and retention of key personnel. Administrative teams support facilities, meetings, travel, and daily operations.
These functions may appear distant from the product itself, but losing a critical position can leave an entire task on the project schedule without anyone capable of taking ownership.
IT and information security teams manage account permissions, engineering environments, data backup, collaboration systems, and network boundaries. Security management controls personnel access, facilities, information carriers, and data circulation according to project requirements.
If configuration files are scattered across personal computers, test data cannot be traced, or former employees retain access rights, even an excellent design can become unusable because information has lost control.
In a small company, these responsibilities may not have dedicated departments, but that does not mean the functions disappear. One person may take on several roles, but they must understand which responsibility they are performing and which approval rules apply at that moment. Organizations can be flat, but responsibilities cannot be ambiguous.
4. How Does a Model on a Drawing Become a Physical Product?
Manufacturing Engineering and Production: Turning “Can Be Designed” into “Can Be Reliably Produced”
Engineering drawings define what a product is intended to become. Manufacturing documents define how the factory will actually build it.
Production sequencing, welding or bonding parameters, tooling requirements, measurement methods for critical dimensions, operator qualifications, and repair limits are not automatically answered by a drawing.
Manufacturing teams deal not with ideal digital models, but with real materials, real equipment, and real process variation. They assemble parts, components, cables, software, and structures into a complete product while preserving records of processes, personnel, equipment, batches, and inspections.
The shared goal of manufacturing engineering and production is to ensure that success does not depend on individual experience or luck, but can be repeated consistently.
Production planning and material control convert bills of materials, manufacturing routes, workforce and equipment capacity, inventory status, and project milestones into executable work orders and schedules.
They determine which processes can run in parallel, which missing components may block final assembly, and which equipment conflicts need to be resolved.
Production planning is not simply filling dates into a spreadsheet. It is maintaining manufacturing rhythm under constantly changing real-world conditions.
Supply Chain and Procurement: A Single Line in a Drawing May Represent Six Months in the Outside World
An engineer may add a valve, connector, chip, or composite material specification to a bill of materials in seconds.
For supply chain teams, that single line may trigger months of work: sourcing, quotations, capacity assessment, technical clarification, supplier qualification, contract negotiation, delivery tracking, quality documentation collection, and issue resolution.
Procurement is not complete when an item is “available.” It must simultaneously consider quality, cost, delivery, and long-term supply continuity.
Supplier quality management is especially important. Passing prototype evaluation does not mean a production batch will remain stable. A supplier having equipment and certifications does not automatically mean that every future product is qualified.
Changes in raw material sources, special processes, key personnel, tooling, equipment, or even factory locations can alter product risk.
The real challenge of aerospace supply chains is integrating external manufacturers into a controllable, verifiable, and traceable quality system.
Warehousing and Logistics: Products Remain in a Technical State Even While Stored or Transported
A warehouse is not simply a place where items are kept.
Different materials may require temperature and humidity control, electrostatic protection, cleanliness requirements, shelf-life monitoring, batch separation, first-in-first-out management, or special packaging.
Materials awaiting inspection, approved materials, rejected materials, expired materials, and quarantined materials must all maintain clear status identification. Receiving, issuing, returning, and substituting materials must leave complete records.
Otherwise, two components with the same appearance may come from different batches, and although they look identical, their quality evidence may be completely different.
Logistics is also part of engineering control.
How precision products are secured, how shock and vibration are limited, whether temperature and humidity are monitored, what happens after unexpected impact, and whether transport routes and handling conditions meet requirements all need to be designed in advance.
A product does not automatically leave controlled status simply because it leaves the factory gate.
5. A Product May Work, but Who Proves It Is in the Correct State?
Testing and Metrology: Turning “Looks Normal” into Comparable Data
Testing teams transform design requirements into test items, conditions, sequences, acceptance criteria, and records.
A successful test must answer at least four questions:
- Is the tested item the correct product?
- Is the correct software and parameter configuration being used?
- Are the measurement instruments reliable?
- Are environmental and boundary conditions acceptable?
Simply seeing a green “PASS” indicator on a screen does not constitute complete evidence.
The purpose of metrology is to ensure that measurements obtained at different times, with different equipment, and in different locations can be traced and compared.
If sensors, instruments, or test fixtures exceed calibration limits, test conclusions may lose their foundation.
Metrology personnel do more than calibrate equipment. They also consider measurement range, accuracy, validity periods, operating environments, and the impact of out-of-tolerance conditions on previous test results.
Technical Support: Ensuring Facilities and Equipment Are Available When Needed
Technical support here mainly refers to the operation and maintenance of facilities, utilities, and production and testing equipment.
Power systems, compressed air, cooling water, vacuum systems, clean environments, temperature and humidity control, lifting equipment, and test systems all require maintenance, inspection, repair, and emergency response.
Imagine a product undergoing a long-duration environmental test.
Engineers monitor product parameters. Test personnel execute procedures. Technical support personnel focus on whether the refrigeration system, vacuum pumps, power supply, and circulation systems can continue operating reliably.
A single equipment failure may invalidate days of testing. A utility fluctuation may even be mistaken for a product failure.
The value of technical support is creating stable and repeatable physical conditions for engineering work.
Quality and Product Assurance: Protecting Processes, Configuration, and Evidence Chains
Quality and product assurance are not the same as technical support, nor are they simply about signing the final approval document.
Quality personnel verify whether processes are executed according to approved procedures, whether nonconformities are controlled, and whether inspection records are complete.
Product assurance usually takes a broader view, ensuring that quality, reliability, safety, and other assurance activities support mission objectives. ECSS product assurance management standards also emphasize that product assurance must run throughout the project and interact with project management and engineering activities.[6]
They ask questions such as:
Which revision of the drawing was used on the production floor?
Is the software checksum consistent?
Who approved this deviation?
Are personnel qualifications and equipment certifications for critical processes still valid?
Could unresolved issues affect the mission?
Can the product data package connect the physical product with its manufacturing, inspection, testing, and problem-resolution history?
Quality and product assurance do not replace engineering judgment. Their role is to ensure that decisions are based on controlled processes and auditable evidence, while protecting critical boundaries under schedule pressure.
Configuration management, documentation control, and data management also play key roles here: the physical product must remain consistent with its corresponding drawings, software, materials, and records.
Safety and Environmental Management: Ensuring People and Facilities Do Not Become Project Risks
Hazardous chemicals, high-pressure gases, lifting operations, cryogenic fluids, high temperatures, high voltages, vacuum vessels, and large moving equipment may all appear in aerospace development environments.
Safety, occupational health, and environmental management teams control risks that may not appear in product performance indicators but can still bring a project to a halt.
Through risk identification, work permits, training, protective measures, emergency plans, and site inspections, they ensure that personnel and facilities remain safe throughout development activities.
Figure 3: Four components of a deliverable product
Source: Illustration created by the author
6. Packing Is Not the End: The Final Mile of a Delivery
After a product completes testing, the project enters a phase that is often underestimated: factory acceptance review, packaging, transportation, on-site recovery, customer acceptance, and document transfer.
At this stage, engineers may still need to address technical issues. Manufacturing and testing teams confirm the final configuration. Quality and product assurance teams review open items and data packages. Warehousing and logistics teams execute packaging and transportation plans. Business teams and customer managers coordinate the on-site schedule.
After arriving at the customer’s site, additional challenges may appear. Power supply, grounding, network connections, cleanliness levels, temperature and humidity conditions, lifting interfaces, or joint-test requirements may differ from expectations.
Field service personnel must understand the product while also communicating accurately among the customer organization, internal teams, and multiple technical disciplines.
They are not simply “installing equipment.” They are completing the transition of the product from the development organization to the user organization.
NASA identifies transition as a separate activity within the product realization process. The reason is clear: technical completion does not automatically mean that the user has safely and correctly received and can operate the product.[5]
At this stage, finance teams focus on invoicing, revenue recognition, payments, and warranty retention. Legal and business teams ensure that acceptance complies with contracts and that changes are properly documented. Archive and configuration management teams ensure that delivery documents match the actual product configuration.
A delivery is not truly complete if only the physical package has arrived while acceptance criteria, operational boundaries, training, and responsibility interfaces have not been transferred.
7. After Delivery, Companies Must Turn Results into the Next Opportunity
Customer Service, Marketing, and Business Teams: Sending Field Feedback Back into the Product
Failures after delivery, usage patterns, maintenance costs, and new customer requirements all return to product improvement and future business decisions.
After-sales and field service teams are usually the first to encounter real-world usage problems. Marketing teams determine whether an issue is unique to one customer or represents a broader product opportunity. Business teams convert additional requirements into clearly defined scopes and contracts.
Communications and Brand Management: Accurately Explaining What Has Been Achieved
External communication is not about making technical capabilities sound as impressive as possible.
It requires balancing public understanding, commercial communication, and technical accuracy:
Which capabilities have already been delivered?
Which have only been experimentally validated?
Which remain future plans?
Which figures have defined test conditions?
Which information cannot yet be disclosed?
An exaggerated statement can damage customer confidence, employee judgment, and investor expectations at the same time.
Good communication explains complex achievements clearly while also defining the boundaries of actual capability.
Financing, Government Affairs, and Investor Relations: Turning One Achievement into Future Growth
A completed project creates more than revenue. It creates evidence of product maturity, customer trust, and organizational capability.
Financing and investor relations teams transform these achievements into information that external stakeholders can understand. Government affairs teams use these results to support industrial programs, resource coordination, and policy communication.
Together, these functions influence whether a company can build the next production line, recruit more talent, and undertake larger projects.
Knowledge Management, Documentation, and Human Resources: Ensuring Experience Does Not Remain Only in Individuals’ Minds
After a project ends, drawings, manufacturing processes, software, test data, failure records, supplier performance, and field experience should become organizational assets.
Knowledge management and documentation prevent teams from repeating the same mistakes. Human resources teams and managers identify critical capabilities, develop successors, and adjust organizational structures.
A truly mature company does not rely on a few individuals repeatedly solving emergencies. Instead, it gradually transforms personal experience into organizational capability.
8. The Real Meaning of Systems Thinking: Project Success Depends on Closed-Loop Interfaces
In aerospace engineering, systems engineering does not optimize the engine, structure, control system, and thermal environment separately and then expect them to automatically become a successful rocket.
Business operations work the same way.
R&D, manufacturing, supply chain, finance, quality, technical support, and business teams may each achieve local optimization, but the overall project may still fail.
A supply chain team seeking the lowest unit price may increase delivery risk.
An engineering team pursuing maximum performance may ignore manufacturability.
A business team seeking a contract may leave acceptance boundaries unclear.
A manufacturing team trying to meet deadlines may bypass configuration changes.
A finance team protecting short-term cash flow may delay critical long-lead materials.
Every local decision can transfer costs and risks to another part of the organization.
Many failures do not occur because a function completely failed to work. They occur because interfaces were never properly connected.
Customer language was not translated into engineering requirements.
Design changes were not communicated to procurement and production.
Equipment maintenance schedules conflicted with test windows.
Public statements failed to distinguish planned capabilities from delivered capabilities.
Products were shipped before acceptance documents were complete.
Figure 4: Common organizational interface failures
Source: Illustration created by the author
Therefore, “systems thinking” is not only about understanding how a product is composed of subsystems. It also means understanding how a delivery is created through interconnected organizational processes.
Every role needs to know:
Who provides its inputs?
Who receives its outputs?
Who will be affected by changes?
What evidence proves that the interface has been closed?
What This Means for Technical Personnel
Understanding these functions does not mean engineers should take every responsibility onto themselves. It means they should recognize project boundaries earlier.
Do not rush into design before requirements are clarified.
Expose long-lead components as early as possible.
Confirm facility conditions in advance.
Notify affected parties whenever changes occur.
Begin collecting delivery data from the first day of the project.
What This Means for Functional Teams
Getting closer to the product does not mean replacing engineers in design work. It means understanding how each action changes technical outcomes.
Finance teams should understand how payment timing affects material delivery.
Procurement teams should understand critical characteristics.
Warehouse teams should understand batch control and lifetime limits.
Communication teams should understand verification boundaries.
Project managers should understand that technical problems cannot always be solved simply by compressing schedules.
Conclusion: The Final Photo Cannot Contain the Entire Project
A product moving from a drawing to a delivery site certainly depends on engineers who develop concepts, create designs, perform calculations, write software, and conduct testing.
But it also depends on the people who identify customer needs, protect cash flow, define contract boundaries, track materials, manage batches, maintain equipment, control technical status, manage site risks, deliver products to customers, and secure resources and trust for future growth.
They may not all appear in the same project chat group, and they may not appear in the final celebration photo.
Some people are only a wrench away from the product. Others are separated from it by a contract, a payment milestone, an information system, or a policy discussion.
Yet if any one of these chains breaks, a technical achievement may remain stuck as a drawing, prototype, or test article.
Engineers transform physical laws into products; organizations transform products into trusted deliveries. What deserves recognition is not one department completing a project alone, but a group of professionals with different expertise connecting their individual responsibilities into a complete system.
As the space industry moves toward larger-scale commercialization, successful missions increasingly require not only engineering expertise but also reliable access to spacecraft manufacturing capabilities, Assembly, Integration & Test (AIT) equipment, and high-quality satellite data. STARPATH GLOBAL connects global customers with China’s expanding aerospace supply chain, providing AIT equipment solutions, satellite imagery products, and customized space solutions for different mission requirements. Whether you are developing a satellite program, improving spacecraft production capabilities, or exploring Earth observation applications, STARPATH GLOBAL can help connect your needs with suitable aerospace resources through its global space services. For customized requirements and cooperation opportunities, contact STARPATH GLOBAL.
References
[1] State Administration for Market Regulation and Standardization Administration of China: GB/T 32451-2015 Aerospace Project Management, current national standard; reviewed in 2025 and confirmed to remain valid.
[2] State Administration for Market Regulation and Standardization Administration of China: GB/T 32305-2015 Space Product Assurance, current national standard.
[3] State Administration for Market Regulation and Standardization Administration of China: GB/T 19001-2016 Quality Management Systems — Requirements, equivalent to ISO 9001:2015, current national standard.
[4] NASA: NASA Systems Engineering Handbook, Rev. 2, NASA/SP-2016-6105 Rev2; related materials include the Systems Engineering Handbook and Fundamentals of Systems Engineering.
[5] NASA: Systems Engineering Handbook, Section 5.0 Product Realization, covering product implementation, integration, verification, validation, and transition processes.
[6] European Cooperation for Space Standardization: ECSS-Q-ST-10C Rev.1, Space Product Assurance — Product Assurance Management, 2016.
