Noti Haim | System Engineering Consultant, Project Management & Test Engineering

Management of Contractual and Management Requirements Using DOORS

Management of managerial and contractual requirements of the project in parallel with management of the product technical requirements.

The methodology covers the full workflow from importing contractual data, requirement classification and traceability, through editing and organizing the Technical Specification and the Statement of Work (SOW) and managing them within the DOORS environment.

The approach enables full traceability between contract clauses, technical requirements, project tasks and subcontractor activities while maintaining structured documentation and responsibility definition across the project lifecycle.

System Engineer in a Profit Center within a Matrix Organization

System Engineering within a Profit Center operating in a matrix organization is a multidisciplinary role that combines technical, managerial and business aspects in order to maximize company profitability and customer satisfaction.

• Profit Center versus Cost Center: the System Engineer in the Profit Center focuses not only on the technical solution, but also on customer satisfaction, risk management and process efficiency to support business success.
• Role in the management team: the System Engineer is an integral member of the project management team alongside the Project Manager and Contract Manager, with technical, managerial and business responsibility.
• Economic challenge: most Life Cycle Cost decisions are determined in the early stages, so the System Engineer must balance customer needs, uncertainty and company profitability targets from the start.
• Success criteria: profitability, ROI, schedule adherence, customer satisfaction, follow-on orders and the quality of requirements management, risk management and design reviews.
• Interface with the Project Manager: success in a matrix organization requires clear responsibility boundaries, continuous dialogue and coordinated training between management and engineering functions.

High-Complexity Project Management

This presentation reviews project management methodology for high-complexity projects, with emphasis on work methods adapted to high technological complexity.

The presentation is intended to describe the activities, responsibilities and risks of the project management team throughout the lifecycle of high-complexity projects.

• Project definition and objectives.
• Project classification by type of activity, technological complexity (Bonen scale) and maturity levels (TRL/MRL).
• Project management team roles, including the Project Manager, System Engineer, Marketing Manager and additional stakeholders.
• Project lifecycle: an in-depth description of the seven stages, from initiation to disposal, including objectives, activities, deliverables and unique risks in each stage.
• Agile project management: comparison with the traditional Waterfall approach, with emphasis on the role of the System Engineer and the new roles of Scrum Master and Product Owner.

The project lifecycle includes seven main stages:

1. Initiation and need definition: formulation of business strategy and construction of a prototype.
2. Marketing and negotiation: Bid/No Bid decision and signing of a profitable contract.
3. Kickoff and organization: workforce allocation and building work plans (WBS, PMP).
4. Project execution: system engineering processes, integration and delivery to the customer.
5. Completion and closure: fulfillment of commitments, team dispersal and knowledge preservation.
6. Operational use and maintenance: technical support, training and troubleshooting.
7. Disposal. In a typical high-complexity project, the entire process may last between 16 and 31 years.

Unlike traditional Waterfall management, which focuses on meeting a fixed schedule and budget, the Agile approach strives to deliver maximum value to the customer under resource constraints. In this method, new roles such as Scrum Master and Product Owner are defined, and the System Engineer takes a central role in backlog management.

Development Management Models

This methodology reviews the different ways to manage the System Development Life Cycle (SDLC), defined as the set of activities required to specify, design, build, test and approve a system.

• Main lifecycle approaches: development of a single main product at the end of the process (Predictive), development through prototypes, and Iterative / Incremental development.
• Traditional models: the Waterfall model and the V-Model, which emphasize structured progression, planning, and the linkage between development and test stages.
• Iterative and incremental models: the Evolutionary model, Incremental development, the Spiral model, and the Sawtooth model for early risk reduction and gradual capability growth.
• Agile and Scrum: short development cycles, early and continuous delivery of customer value, openness to change, and close day-to-day coordination within the team.
• Management considerations: the knowledge paradox, early risk reduction through simulations and prototypes, and choosing the most suitable development model before starting development.

The methodology emphasizes that there is no single ideal model for every project; in practice, organizations usually use combinations and adaptations according to project conditions, and choosing the wrong model can be a costly mistake.

Test Engineering Methodology

Test Engineering is a discipline within System Engineering that begins at the project initiation stage. Its main objective is the technical and economic optimization of the test concept with a comprehensive lifecycle perspective, from development through maintenance and operational use.

• Strategic motivation: without structured Test Engineering, projects suffer from late discovery of testability issues, expensive design changes, duplicated test equipment development and reduced customer satisfaction.
• Optimization processes: balancing Built-In Test (BIT) coverage versus external test equipment, while evaluating impacts on hardware cost, product reliability and overall economic feasibility.
• System simulations: supporting algorithm development, system element verification, edge-of-envelope behavior analysis, reduction of expensive field experiments and user training.
• Management and organization: the Test Engineer is an experienced System Engineer who coordinates all testability requirements and manages the interfaces between development, production and maintenance.
• Innovation: increasing use of AI in self-test for predictive maintenance and improved decision support within the system.

The methodology emphasizes cost-benefit considerations, the conditions for the feasibility of integrating simulation into the project, and the importance of integrating Test Engineering early as part of Concurrent Engineering across the full product lifecycle.

Integration of the System Engineer in ILS Activities in the Project

This methodology presents the strategic and economic importance of maintainability and Integrated Logistic Support (ILS) as part of Concurrent Engineering, with direct impact on customer satisfaction and the likelihood of repeat business.

• Strategic and economic importance: about 66% of Life Cycle Cost (LCC) is determined already in the concept and early design stages, even though most of the actual costs are incurred much later, when the ability to influence them is significantly lower.
• Role of the System Engineer and Concurrent Engineering: the System Engineer leads the definition of the maintenance concept, reliability analyses, spare allocation and testability requirements such as BIT, in an iterative process that influences the final product design.
• ILS elements: the work scope includes maintenance policy, customer infrastructure and manpower definition, and planning of an optimal spare parts system to achieve the required availability at minimum cost.
• Implementation, training and operational use: the activity includes classroom training, On-the-Job Training (OJT), test support and technical point-of-contact (POC) responses to issues arising in the field.
• Upgrades and key challenges: advance planning for backward compatibility and upgrades supports long-term customer relations and obsolescence management, while major challenges include support without a defined contract, long-term commitment and balancing maintenance priorities against production priorities.

Design To Lifecycle Cost (DTLC)

Design To Lifecycle Cost (DTLC) is a systemic design and development process focused on achieving the minimum total cost of the product across its full lifecycle, not only during acquisition and development.

• Lifecycle cost perspective: acquisition and development costs are only the visible part of the cost structure, while operations, maintenance, technical support and disposal create the larger hidden cost over time.
• The DTLC dilemma: most design and pricing decisions are made during the concept and design stages, while most of the actual spending takes place later during operation and maintenance.
• Systemic optimization: an economic model is used to simulate and compare design alternatives in order to find the optimal working point between conflicting parameters such as higher development cost versus lower future maintenance cost.
• Business impact and systems engineering role: production quantity, target market and project duration influence the optimal solution, while the Systems Engineer leads the holistic view, builds the economic model with the relevant disciplines and derives system requirements from lifecycle cost analysis.

Stakeholders and Work Interfaces

This methodology defines the stakeholders of the Systems Engineer and the required work interfaces in order to support project success in a matrix organization.

• Stakeholder-oriented management: each stakeholder has different objectives, expectations and interfaces with the Systems Engineer, so the interaction must align customer needs, project goals and organizational interests.
• Matrix organization challenges: the Systems Engineer usually operates without direct authority over all project personnel, while work methods, resource availability and tools may differ across disciplines and organizations.
• Key interfaces: the methodology covers structured interaction with the customer, project manager, contract manager, line management, quality, reliability, safety, testability, ILS, production, subsystem leaders, marketing, end users, procurement and additional internal functions.
• Responsibility split and coordination: it clarifies the division of responsibilities between the Systems Engineer and subsystem or discipline leaders in areas such as requirements, design reviews, integrations, tests, technical correspondence, risk management and work plans.

The methodology emphasizes early integration, continuous coordination and clear definition of interfaces as practical tools for maintaining technical coherence, schedule alignment and business effectiveness throughout the project lifecycle.

Relation between the Systems Engineer and the Customer

This methodology addresses the professional relationship between the Systems Engineer and the customer throughout the full project lifecycle, with emphasis on trust, technical authority and adaptation to the customer's business culture.

• Business-culture adaptation: different customers work through different decision patterns and priorities, so the Systems Engineer must adapt communication and management style to the customer's specific culture and organizational structure.
• Technical authority: the Systems Engineer serves as the leading professional authority on technical matters vis-a-vis the customer, and must demonstrate mastery, solution quality and effective response under pressure.
• Requirements coordination and product approval: ambiguous requirements must be clarified early, an agreed technical specification must be built, and verification and validation processes must be defined in advance to avoid disputes at the final stages.
• Trust and conflict management: trust is built through reliable reporting, honesty and informal communication channels, while disagreements should be resolved through project-level WIN/WIN solutions that avoid unnecessary escalation and preserve the customer's position.

Engineering interaction with the customer begins as early as the RFI stage and continues through design reviews, production, implementation and operational support. Long-term success depends on trust, understanding the relevant professional actors on the customer side and tailoring the working method accordingly.

The System Engineer as a Technical Manager

This methodology presents the role of the System Engineer as a technical manager responsible for ensuring that the technical solution satisfies project and customer expectations within cost and schedule constraints.

• Development management and control: the System Engineer identifies gaps and risks early through status reporting and periodic follow-up reviews, and provides direction to the technical leads.
• Requirements, integration and testing: the role includes defining and approving subsystem requirements with full traceability, managing the VMP, defining test activities and approving the design to ensure compliance.
• Technical risk and planning: the System Engineer leads technical risk management, writes the SEMP, defines the technical WBS and identifies laboratory and development infrastructure needs.
• Interfaces and external management: the methodology covers technical coordination with the customer, management of official project correspondence and document approval, as well as the System Engineer’s role in outsourcing models such as BTS and BTP.

The methodology also emphasizes the overlap between systems engineering and project planning and control in areas such as configuration management, schedules and stakeholder management, while relying on tools such as DOORS, risk systems and MS-Project as part of the broader project management team.

System Documents

System documents are not only contractual obligations but essential tools for organizing engineering thinking, surfacing systemic issues and coordinating expectations with the customer.

• Core document set: the framework includes managerial and technical plans such as SEMP, VMP, RMP and TCD, alongside additional plans for risk management, quality assurance and configuration management.
• Project leverage: these documents help lock technical commitments early in the lifecycle, especially around milestones such as SRR and PDR, and reduce risks created by contractual ambiguity.
• Requirement clarification and alignment: documenting and closing requirements as early as possible supports the project’s interests and creates clearer expectations between the project and the customer.
• Controlled delivery process: each document has a defined author and goes through configuration control, professional editing and quality assurance before delivery to the customer.

The methodology treats system documentation as an active management instrument throughout the project lifecycle, rather than as a passive reporting requirement.

Project Information Management

This methodology addresses information and knowledge management in the project, with emphasis on the central role of the Systems Engineer in preserving and sharing knowledge within the project and across the wider organization.

• Need and motivation: information management is especially critical in defense organizations because of long product lifecycles, rapid personnel turnover, and the high cost and complexity of experiments and integration processes.
• Core process: the methodology is based on a four-stage cycle of creating and collecting information, storing and organizing it, sharing and transferring it, and reusing and embedding it in future work.
• Managed content: the information base includes technical documents, formal correspondence, requirements management in tools such as DOORS, discussion summaries and tasks, as well as information from tests, integrations and investigations.
• Systems and continuity: information should be managed in systems that support search, configuration linkage, scenario-based retrieval and controlled sharing in order to improve continuity within the project and reuse across similar projects and technological building blocks.

The Systems Engineer is responsible for coordinating development processes, managing technical discussions with stakeholders, and ensuring that technological building blocks remain accessible for future projects and product updates. Effective information management turns scattered data into useful organizational knowledge and reduces the loss of critical engineering insight over long product lifecycles.

System Engineer Support in Production

This methodology provides a view into systems engineering processes across different companies and compares defense and civilian environments in order to derive lessons for implementation, transfer to production and organizational improvement.

• Sector differences: civilian projects are typically driven by shorter time-to-market and freer management culture, while defense projects are more conservative, standards-driven and oriented toward long lifecycle support.
• Requirements, risk and production transfer: defense organizations tend to be stronger in structured requirements engineering and risk management, while civilian organizations often show stronger practices in design verification and transition to production.
• Role of the System Engineer: in defense programs the System Engineer often acts as the technical representative of the program manager, with responsibility for integrated engineering aspects such as production, maintenance and testability, while overall program accountability remains broader.
• Implementation lessons: successful adoption of methodologies and tools depends on management commitment, correct resource allocation, suitable timing in the lifecycle, and the ability to align engineering methods with organizational culture and decision-makers.

The methodology also draws on NASA-style lifecycle thinking, emphasizing early operational concept definition, rigorous technical management, configuration control and clear interfaces as keys to improving systems engineering and supporting better organizational execution.

Systems Engineering in Defense and Civil Markets in Israel and Worldwide

This methodology provides an overview of systems engineering processes in different companies in Israel and worldwide, while comparing defense and civil markets and extracting lessons from the implementation of methodologies and tools.

• Market differences: civil markets are characterized by freer management culture and much shorter time-to-market, while defense markets are more conservative, standards-driven and oriented toward longer product lifecycles.
• Requirements, risk and lifecycle focus: defense organizations are generally stronger in requirements engineering and structured risk management, while civil organizations often excel more in design verification, transfer to production, innovation, design and user experience.
• Role of the System Engineer: in defense environments the Systems Engineer may act as the technological envoy of the program manager, with responsibility for technological risks and for integrated engineering aspects such as production, maintenance and testability.
• Implementation lessons and methodology adoption: successful deployment of requirements tools and engineering methods depends on senior-management commitment, correct allocation of resources, proper timing in the project lifecycle and effective organizational adoption by engineers and decision-makers.

The methodology also draws on NASA lifecycle thinking, emphasizing the importance of ConOps, clear lifecycle phases, rigorous technical management, configuration control and interface management. The main recommendation is to institutionalize systems engineering through dedicated training, shared governance and mandatory use in new projects.

Verification Master Plan (VMP)

The Verification Master Plan (VMP) is intended to regulate the design approval process in the project and to ensure that verification is planned, coordinated and agreed in advance across all stakeholders.

• Early gap identification: the VMP supports an early review of system requirements in order to detect ambiguous definitions and prevent approval difficulties later in the lifecycle.
• Resource and expectation management: it enables early identification of tools, test equipment and additional resources, while fully synchronizing the design approval process with the customer and the project team.
• Responsibility and timing: the document is led by the Systems Engineer in coordination with the Test Engineer and development leads, while quality assurance oversees compliance as part of the quality plan. A draft should exist as early as SDR and a final version by PDR.
• Document content: the VMP links system requirements to practical execution, including test stages, linkage to requirements, test setups, success criteria, safety and fault documentation, timeline-based verification activities and regression processes for software and hardware updates.

The VMP is a critical management tool for ensuring quality, reliability and safety, while verifying that all system requirements are addressed in a structured and preplanned way.

The Engineering Excellence Paradox - Why the Airbus A380 Failed

The Airbus A380 was designed to be the largest and most complex passenger aircraft ever built, representing an extraordinary engineering achievement and a major strategic effort to challenge Boeing in the very-large-aircraft market.

• Faulty market assumption: Airbus based the program on a hub-to-hub growth model, while the market shifted toward point-to-point travel using smaller, more efficient twin-engine aircraft such as the Boeing 787 and Airbus A350.
• Operational and infrastructure burden: the aircraft suffered from very high fuel consumption, expensive four-engine maintenance and airport-infrastructure constraints that limited the number of destinations it could serve effectively.
• Management and production failures: the program encountered major delays and cost overruns, driven in part by incompatibility between design tools across countries, wiring problems and a politically fragmented management structure that slowed decisions and suppressed escalation of bad news.
• Engineering paradox: the case demonstrates that exceptional engineering excellence without economic viability, market fit and robust program integration can still lead to product failure.

Although the A380 remained a remarkable technical achievement, weak demand and the market preference for efficiency over size led Airbus to terminate production in 2021. The lesson is that engineering success must be balanced with system-level business realism.

System Engineer as a Business Partner

The Systems Engineer is not only a technical authority but also an integral member of the project management team alongside the Project Manager and Contract Manager, responsible for driving the project toward an optimal working point that balances technical excellence with business and budget constraints.

• Working Point and DTLC: the Systems Engineer must define the project's working point between customer value and product price, and understand that most lifecycle cost is determined already in concept and early design stages.
• Business contribution across the lifecycle: the role includes engineering support for cost assessment, ROI analysis, demo-scope decisions, cost targets, subcontractor SOW definition, customer-claim handling and preparation for production, maintenance and follow-on business.
• Interfaces and built-in conflicts: the Systems Engineer works in close overlap with the Project Manager in areas such as risk, stakeholders, schedules and configuration control, while also bridging the natural tension between engineering conservatism and marketing's need to maximize customer value.
• Requirements as a profitability tool: effective requirements management helps prevent gold plating, reduce NRE, avoid schedule delays and improve overall project profitability.

The methodology frames the Systems Engineer as a business partner who must ensure that the product is not only technically sound, but also commercially correct, contractually aligned and economically viable.

Simulation - Is It Worth It?

Simulation is the representation of a system or process through mathematical models, scenarios or tools that reproduce the expected behavior of the real system. Its main goals are to support system testing and approval processes and to train end users.

• When it is worthwhile: simulation is especially valuable for complex and expensive systems, when field experiments are costly, when early risk reduction is needed, when extreme or safety-related conditions must be examined, and when operational faults need to be recreated under laboratory conditions.
• Engineering benefit: simulation enables early integrations, shortens software and algorithm development time, improves fault analysis and supports better preparation for formal verification activities.
• Risks and limitations: incorrect assumptions or model errors may lead to wrong conclusions, simulator development may consume significant time and budget, and the model must be updated continuously whenever the real design changes.
• Decision basis: feasibility should be determined through cost-benefit analysis, while choosing the right level of complexity and fidelity according to the engineering questions the project actually needs to solve.
• Sully example: the film dramatizes how a simulation may produce the wrong engineering conclusion when it ignores human-in-the-loop delay. Only after adding realistic pilot reaction time did the simulation support the real decision to land on the Hudson, highlighting the importance of human factors, decision latency and operational context.

The methodology concludes that simulation is not automatically justified in every project. It becomes worthwhile only when the expected gain in development speed, quality improvement and risk reduction clearly exceeds the cost of development and ongoing maintenance.

מהנדס המערכת בתהליך השיווקי ומשא ומתן

המתודולוגיה מקנה למהנדס המערכת כלים מעשיים להשתלבות אפקטיבית בפעילויות השיווקיות ולמתן תמיכה טכנית לאורך תהליך המענה להצעה והמשא ומתן.

• שלב המענה להצעה: העבודה מתחילה בדיון התנעה בין שיווק, הנדסה, תפעול, כספים ובעלי עניין נוספים כדי להגדיר תכולות, אחריות ולוחות זמנים למענה.
• נקודת עבודה, תימחור וטבלת ציות: מהנדס המערכת מסייע להגדיר את הבסיס הטכני לתימחור, מתעד הנחות עבודה תחת אילוצי זמן ותקציב, בונה את הפתרון הטכני ומציג אותו באמצעות טבלת ציות מול דרישות הלקוח.
• תימחור, סיכונים ותמיכה במשא ומתן: התפקיד כולל בניית דגם עלות מבוסס WBS, זיהוי סיכונים טכניים ותקצוב בצ"ם, עדכון המענה הטכני במהלך המשא ומתן ותמיכה בנושאי קניין רוחני, היתרי שיווק, NDA, אופסט ואחריות תכן לאחר האספקה.
• הדגמות וניהול מידע: יש לנהל הדגמות כמיני-פרויקט ממוקד להמחשת הערך והציפיות של הלקוח, ובמקביל לשמר את כלל מסמכי ההצעה, חומרי הלקוח והתכתובות הפורמליות במערכות המידע הארגוניות כדי למנוע מחלוקות עתידיות.

המתודולוגיה מציבה את מהנדס המערכת כסמכות מקצועית מרכזית בתהליך השיווקי, שמבטיחה מענה אמין טכנית, מבוקר חוזית ומודע להיבטים העסקיים מול הלקוח.

Requirements Management in Economic Aspects

This methodology presents requirements management as a powerful financial tool and explains how adding functions that were not actually required by the customer can damage project profitability through over-engineering.

• Project success impact: weak requirements management is presented as one of the most common causes of project failure, with about 47% of unmet project goals linked directly to poor requirements management.
• Hidden costs: about 51% of wasted project budgets are attributed to poor requirements management, starting from vague requirements and ending with expensive retrofits, delays and contractual penalties.
• Scope creep and over-engineering: around 65% of delivered functionality is barely used by the customer, yet it still consumes development, production and testing resources that directly erode profitability.
• Profitability mechanism: rigorous requirements management helps reduce NRE, prevent future failures, reduce penalties with subcontractors and optimize lifecycle cost (LCC).
• Requirements paradox and economic meaning: although only about 33% of managers view requirements management as a critical core capability, it is exactly this discipline that connects the engineering side to the business side by increasing profitability and reducing misunderstandings.

The methodology highlights the financial meaning of requirements discipline: better requirements management is not only good engineering practice, but a direct tool for closing what the presentation describes as one of the deepest financial holes in complex projects.