This research examines the project management/systems engineering interface with a specific focus on costs and planning. This research also showed that the Systems Engineering process must function harmoniously within the larger Project Management environment for a development project to run optimally.
INTRODUCTION
- Development Projects Problem areas
- Concepts and Definitions
- Systems Engineering and Project Management Articles
- Problem Statement
- Research Objectives
- Research Contributions
- Research Questions
- Research Roadmap
- Chapter Summary
They do not, however, discuss the impact of design changes on the rest of the development project. What is the impact of a design change, in terms of functionally related elements, on the development project.
RESEARCH METHODOLOGY
- Discussion of Research and Analysis Method
- Exploratory Research
- Empirical Research
- Constructive Research
- Selection of Research Methods
- Root Cause Analysis (RCA)
- Chapter Summary
This will be a precursor in preparation for a subsequent root cause analysis of the experienced project problems. Once the mechanism is fully understood, a solution to the problem can be developed to prevent recurrence of the problem.
SYSTEM DEVELOPMENT BACKGROUND
- System
- Characteristics and Properties of a System
- System dynamics
- Systems Engineering
- Systems Engineering Process
- Systems Engineering Outputs and Summary
- Project Management
- Matrix Organisational Structure
- Design Influencing
- Success Domain Team (SD)
- Failure Domain Team (FD)
- Project Management Team (PM)
- Chapter Summary
The National Council on Systems Engineering (INCOSE) web page states: “The term systems engineering dates back to the early 1940s at Bell Telephone Laboratories [Schlager, 1956; Hall, 1962; Fagen, 1978]. In other words, the mindset of the FD team is: “what is the maximum allowable failure and what are the weaknesses in the design?” The mindset of the FD team is design failure mitigation.
BACKGROUND TO THE CASE-STUDY
- Purpose and Outline of the Chapter
- Background of Armour and Anti-Tank Weapons Systems
- Scope of the Case-study
- Introduction to Anti-Tank Missile Systems
- Evolution of Anti-Tank Weapons Systems
- First Generation Anti-Tank Missile Systems
- Second Generation Anti-Tank Missile Systems
- Third Generation Anti-Tank Missile Systems
- User Requirements Background
- Existing Anti-Tank Armoured Vehicle
- Ingwe Missile Description
- User Requirements
- Primary Constraints Invoked by the Client
- Contract Overview
- Project Management model
- Contractor’s Management Model
- Introduction to the Case-study Summary
The guidance unit processes this data and generates control signals for steering the missile. Anti-tank weapons are part of the Army Armored Formation of the South African National Defense Force (SANDF), (Source: SA Army Armor Formation website, March 2009).
CASE-STUDY
- Purpose and Outline of the Chapter
- Development Model and Development Process
- Development Project Objectives
- Development Strategy
- Systems Engineering Process Selection
- Applied Systems Engineering Process
- Design Reviews and Baseline Management
- Engineering Change Management
- PRACAS Management
- Overview of the Final Evolved System
- Development Project Logistics Engineering Process
- System Hand-Over
- Chapter Summary
This phase of development is shown in Figure 16 as the demonstration and evaluation phase (DVAL). Budget and time scale constraints for the development of the anti-tank weapon system necessitated a development strategy with minimal risk and first time right results. The IPS development model (Roos, 2001) discussed above was used to guide the systems development process for the development of the 3. generation anti-tank weapon system and associated logistics infrastructure.
The first 4 phases of the IPS development model discussed above, used for the case study, are shown in Figure 18. This is followed by the development of the production data package as part of the system engineering output discussed in Chapter 3. Technical logistics support writers were responsible for developing the supporting documentation package.
PROBLEMS EXPERIENCED AND LESSONS LEARNED
- Review of the Case-study
- Grouping and Quantification of the Problems Experienced
- Evaluation of the Analysis Results
- Management Related Project Problems
- Systems Engineering Related Problems
- QA and CM Related Problems
- Development Process
- The Causes of the Problems Encountered
- Chapter Summary
Chapter 5 discussed the background of the case study for the development of the ZT3 anti-tank weapon system and the systems engineering process using the IPS development model. Appendix B contains a breakdown and summary of the problems experienced and assigned Likert scale values. The ripple effects of this were sometimes underestimated, leading to cost and schedule overruns on the affected parts of the project.
Basically this worked very well right up to the CDRs for the individual configuration items for the weapon system. No formal system documentation as part of the development model describes "HOW" a particular design works. The summary of the research findings is that management accounted for 57% of all the problems experienced in the project, while systems engineering accounted for 20%.
ROOT CAUSE ANALYSIS
Purpose and Outline of the Chapter
- Evaluation of the IPS Development Model
- Finding the Root Cause
- Determining the theoretical ground
- Project management and systems engineering processes
- Systems Engineering Shortcomings
- Detailed Analysis of design iterations
- Established design process
- Application of the SD-FD design influencing model
- Real world design influencing model
- The Generalised Design Change Impact Equation
- Impact of functional couplings
- Development of the mathematical model
The hierarchical system in Figure 6 (Hitchins 1992) can be redrawn to also show the functional relationships between system elements that give rise to the emergent properties of the system. Functional links between parents and children are the result of emergent properties discussed in Chapter 3. Thus, it can be concluded that the main cause of the ripple effect is due to the change of Class I CI due to functional couplings between functional elements in the system hierarchy.
Functional coupling rules must be defined as a prerequisite for developing an influence equation. Because of the properties that occur in the system, there will always be functional relationships in the system hierarchy between the affected AI, its parent, and its children. Equation (2) shows that the impact or ripple effect of a single CI design change in a concurrent engineering environment is amplified as a result of the functional links between CIs and the size of the system hierarchy.
Summary of the impact of change
- What other factors are at play?
From Equation 2, the actual impact of a design change in a real system under development can be calculated to assess the feasibility of allowing a design change or rather to find alternative less disruptive solutions to the problem at hand for a development project. With the increased demand for "systems of systems", systems integration practices have gradually become more formalized and more specialized to identify the improved technical, cost and time results that can be achieved by controlling and progressively validating system interfaces throughout the development program. . Such a model will assist design review committees and project management by accurately and quickly determining the impact of a proposed change on the project before the change is approved.
The real-life reality is that cost and schedule are the primary constraints of any development project. The ZT3 anti-tank weapon system upgrade case-study is one such case. It can be qualitatively concluded that the success of the anti-tank weapon system project was mainly due to the good leadership and interpersonal relations of the management team, as well as the full support of the company's senior management.
How can the IPS model be improved?
What other models would be appropriate?
Design iteration is an established tool for design optimization and is primarily an effect-to-cause result. By forcing a premature design release, the likelihood of a Class I change to a system CI at the integration level and the associated ripple effect on all other functionally coupled CIs in the system hierarchy increases. A more structured systems engineering process could reduce the number of design iterations, thereby mitigating the risk of premature design release.
Chapter Summary
Digging deeper, it was discovered that the root cause of this incompatibility is actually unexpected and unplanned design iterations from the systems engineering process. Undefined design iterations cannot be accommodated under the discipline of project management as confirmed in PMBOK, (2008). Planned design iterations within a project schedule activity are generally not a problem for PM provided the activity is within cost and schedule constraints.
The discussion above identified design iterations as a result of the "effect-to-cause" design influence process. The fundamental systems engineering process and the project management process are in conflict because of the unpredictability of the number of design iterations required. In the next chapter, "cause-to-effect" design influence will be investigated, with the aim of reducing design iterations that are the natural outcome of "effect-to-cause" design influence.
EVALUATION OF STRUCTURED DESIGN
- Introduction to Structured Design
- Investigation into Structured Design methodologies
- Theory of Inventive Problem Solving (TRIZ)
- Axiomatic Design
- Case-Study - Problems Experienced and Lessons Learnt
- Structured Design Example: a subsystem of the case-study
- Revisit of the Narrative Inquiry Analysis findings
- Summary and Conclusions
In the previous chapter, the effectiveness of the IPS development model recommended by Roos (2001) for the case study project was discussed. Project management is required to manage the consumption of resources and schedules of the systems engineering project. In this section the different domains of the Axiomatic Design (AD) process are discussed.
In particular, the close connection between functional requirements and design parameters will be discussed. Melvin et al (2002) studied system hierarchy rearrangements as a tool to eliminate design iterations. The above literature confirms that the overall goal of AD is to reduce planning iterations and thereby improve the management of development projects.
CONCLUSIONS
Research Questions Answered
RCA of the problems encountered with the case study development project of a complex multi-disciplinary system in a concurrent engineering environment shows that the fundamental mechanism of the "effect-to-cause" design influence process gives rise to iterations. Analysis of the case study problems experienced, as well as subsequent system field tests, confirm that the IPS competitive engineering system development model is, at a technical level, an efficient and effective model for the development of integrated complex multicomponent systems. The case study RCA showed that the majority of the project problems encountered were at the management level and were not due to the IPS development model.
In effect, this could ripple further down the system hierarchy for each of the linked CIs and their sub-CIs. Detailed RCA of case-study problems shows that there is an incompatibility between PM and SE processes. What is the cause of each of the problems experienced and how can these be remedied.
Academic Contributions
This latent design defect can result in unplanned design changes that can adversely affect the performance of the development project. This ensures independence from the functional requirements and design parameters while minimizing system information content or functional links. The impact equation developed allows quantification of the impact of design changes for a specific system hierarchy that can be used for trade-off studies between different possible system hierarchies for a specific system function.
Justification of the requirement for system and design data "How" during the development of a formal system data package. Identification of further research areas in the field of systems engineering and structured design for more optimal development of new systems with the aim of reducing development project costs and time risks.
Recommendations
Further Research
Further research in this field will provide a firmer basis of when a design is ready to be released for further integration into the system. Support personnel must know how the system functions in order to diagnose and repair a failed function (Wooley, 2003). This requires that the original system data package developed under the system development project includes not only the.
Further research is required to find effective systems engineering methods and processes to achieve this goal. Improved Quantification of Early Systems Engineering Efforts There are several systems engineering studies (NASA 1992, Honor 2004) that show that system development program risk can be significantly reduced through Early Systems Engineering (ESEE) efforts. Despite agreement with these findings, from the systems engineering fraternity, early systems engineering efforts are often not sufficient in practice to ensure optimal system design.
Further Systems Engineering Development
The personnel involved in the development of the logistics products did not always understand how the user works during a typical deployment exercise. The scope of work for the consultant in charge of developing the technical manuals and training definition work was inadequate, resulting in the wrong subcontractor. Availability of data The system development data package only addresses "WHAT" the system should do, not "HOW" the system works.
The scope of work for the consultant tasked with the development of the technical manuals and training definition work was insufficient, leading to the selection of the wrong subcontractor. Continuous evaluation QA is not contracted for continuous evaluation of the logistics products throughout the development phase. Continuous Evaluation QA is not competent to evaluate the technical integrity of the Technical Manuals and Training Materials.
