The Systems Engineering Approach to Handling Complex Engineering Projects
In the preceding chapter we identified the main sources of complexity in engineering projects, and in Sec. B2.3 we subdivided projects into a number of stages. We can now relate the two, in the sense of determining which sources determine the complexity in the various stages and thereby determine the complexity of the objects created within each stage. These objects are, as we know from Sec. B2.4, processes and the artefacts and descriptions resulting from them, and while our approach to handling them has a common basis, as was already foreshadowed in Ch. A5 and will be developed in more detail in the next section, there are also significant differences, as we shall discuss later in this chapter.
KeywordsSoftware Development System Engineering Engineering Project Complex Entity Contracting Strategy
Unable to display preview. Download preview PDF.
- 1.The complex contracting arrangements in a number of large infrastructure projects are discussed in section 6.7 of Managing Large Infrastructure Projects, ref. 3 below Google Scholar
- 2.A well-known assessment of the success of software project is the CHAOS Manifest of the Standish Group, http://standishgroup.com, but it has also been criticised by a number of sources, many of which can be found by simply Google on “standish report”. However, there seems to be no doubt about the fact that large software projects have had a relatively poor rate of completion on time, within budget, and to agreed performance criteria, whatever may be valid reasons for this
- 3.The book Managing Large Infrastructure Projects, published by A.T. Osborne BV, 2008, is a most interesting and valuable documentation of lessons learned on 15 major infrastructure products in Europe, with the findings clearly organised into eight groups. The study specifically addresses Project Management, but because these are large and very complex projects, many of the problems encountered are those that arise in complex systems in generalGoogle Scholar
- 4.Failure Modes, Effects, and Criticality Analysis (FMECA) is a well-established process, documented in numerous textbooks and articles, and supported by different many tools. The best introduction is to look it up in Wikipedia, http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis
- 5.This text appeared in the Newsletter of the Systems Engineering Society of Australia (SESA), No. 48 (July 2009); under the title Why Software is Different Google Scholar
- 6.Data Item Descriptions (DIDs) were originally defined as part of MIL-STD-498, which consisted of two parts, Overview and Tailoring Guidebook and Application and Reference Guidebook, and aimed at software development. However, the concept has proved to be of enduring value and applicability, and current defence contracts often require compliance with a large number of DIDs Google Scholar