Sarah A. Sheard

Overcoming barriers to systems engineering process improvement

Neither systems engineering nor process improvement is new. Since 1992, INCOSE papers and others have been reporting success in documenting and improving processes. A considerable body of process improvement literature is available, particularly related to improvement of software development processes. Even systems engineering process improvement is gaining in popularity, judging from the increasing number of INCOSE papers detailing various efforts. Yet the nature of systems engineering poses challenges over and above those seen in other process improvement efforts. This paper focuses on identifying and resolving typical barriers to improving the systems engineering process.

Interpreting continuous-view capability models for higher levels of maturity

When assessing an organizationx92s process maturity using a continuous-view model like the three systems engineering capability models, the capability of each process area is rated separately. This view can be very helpful to lower-maturity organizations because it provides an improvement path that can address one area at a time according to business needs. However, rating process areas separately makes less sense for more mature organizations because their processes map less cleanly to process areas and because process improvement is best applied across an organizationx92s processes to address strategic business needs. This paper first makes the case that, for organizations at Level 3 or 4 maturity, the business processes themselves are what should be rated, rather than the process areas of the model. The rating process consists of two steps: verifying that the processes cover the base practices, and then rating the maturity of the processes. The paper then provides an interpretation of how the term x93Level 4x94 or x93Level 5x94 should be applied to an organization as a whole.

Complexity in large-scale technical project management

Complexity is a catch-all term that is used to express many different factors that cause problems in the management of projects. This paper presents a framework for systematising the description of different types and measures of complexity. First, the attributes that appear in different definitions and uses of the word complexity are compared. Some are shown to be causes of system and project complexity, and some are shown to be effects. Next, types of complexity from previous work are explained. Finally, those types of complexity are applied to different aspects of a large-scale technical development projects: the project building a technological system, that system itself, the environment into which the system will be inserted, and, to some extent, the interpretation of these factors as being complex or not by the humans involved in the system.