By Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong and Richard Turner


Abstract

In Greek mythology, Procrustes was a rogue smith and bandit who invited travellers to rest in his “perfectly sized bed.” When they accepted, he forcibly bound them to it, then stretched them or cut off various body parts until they “perfectly” fit the bed. Too many organizations have a single model of high maturity to which they try to fit all their projects. Development and acquisition organizations are finding that competitive success requires systems that are a mix of high security assurance components, opaque and dynamic COTS products and cloud services, and highly useful but kaleidoscopic apps and widgets. Approaching such systems with a one-size-fits-all corporate process and maturity model often results in a procrustean fit. As a process model generator, the Incremental Commitment Spiral Model has a set of criteria for determining which process or processes best fit a particular system of interest. This article summarizes the criteria and illustrates how they have been successfully applied in various situations [1].

Introduction

Too often, high maturity is seen as a proven, standard process that is tailored down or up or in other ways twisted and tortured to adapt to projects that simply don’t fit the process. This flies in the face of the definition of a high maturity organization as agile, flexible, and continuously improving. Rapid change, requirements uncertainty, and short capability delivery cycles are increasing the need for such agility, and the traditional process and lifecycle models are not meeting the challenge.

Table 1 describes some examples of Procrustean situations that result from inflexible or overly constrained “high maturity” or otherwise “disciplined” approaches. It elaborates the situation into the likely undesired project result, an example, and a remedy or means of avoiding the situation using the ICSM’s four primary principles: Stakeholder value-based guidance; Incremental commitment and accountability; Concurrent multi-discipline engineering; and Evidence and risk-based decisions.

A Different Approach

The Incremental Commitment Spiral Model (ICSM),1,2 shown in Figure 1, is the result of our efforts to better integrate the hardware, software, and human factors aspects of systems, to provide value to the users as quickly as possible, and to handle the increasingly rapid pace of change. While its pedigree lies in the spiral concept first broadly published in 1988,3 this new version draws on over 20 years of experience helping people deal with the fact that the original version was too easy to misinterpret.

Fundamental Principles

In hindsight, most of the problems in using the 1988 spiral model came from users constructing processes that had nothing to do with the underlying concepts. The ICSM’s four underlying principles, based on observed failure modes over years of experience, are:

Stakeholder value-based guidance. Failing to include and address the value propositions of its success-critical stakeholders can result in their minimal commitment to the project; they may underperform, decline to use, or block the use of the results.

Incremental commitment and accountability. If success-critical stakeholders are not accountable for their commitments (or lack thereof), and the associated consequences (good or bad), they may not provide necessary commitments or decisions in a timely manner and are likely to be drawn away to other pursuits when they are most needed.

Concurrent multi-discipline engineering. Sequential definition and development of a) requirements and solutions; b) hardware, software, and human factors; or c) product and processes likely slows the project and leads to early, hard-to-undo commitments that limit options for project success.

Evidence and risk-based decisions. If key decisions are made based on assertions, vendor literature, or meeting an arbitrary schedule without access to evidence of feasibility, the project is building up risks.

The annual series of “Top-5 Quality Software Projects” software-intensive systems projects published in CrossTalk4 are examples of successful projects that applied the ICSM principles. These were chosen annually between 2002 and 2005 by panels of leading experts as role models of best practices and successful outcomes. Of the 20 Top-5 projects, 16 explicitly used concurrent engineering; 14 explicitly used risk-driven development; and 15 explicitly used incrementally committed, iterative system evolution. Additional projects gave indications of their partial use. Unfortunately, the project summaries did not include discussion of stakeholder involvement.

The ICSM is not a single one-size-fits-all process. It is actually a process generator, which steers your process in different directions, depending on your particular circumstances. Unlike in the traditional sequential approaches, each spiral concurrently addresses all of the activities of product development to include:

• Requirements (objectives and constraints)

• Solutions (alternatives)

• Products and processes

• Hardware

• Software

• Human factors aspects

• Business case analysis of alternative product configurations

• Product line investments

In this way, ICSM helps adapt your lifecycle strategies and processes to your sources of change. It also supports more rapid system development and evolution through concurrent engineering, enabling you to develop and evolve systems more rapidly and to avoid obsolescence. It is, in many ways, the antithesis of Procrustes bed – one that adjusts to the person, not the other way around.

ICSM Lifecycle

The Phased View (Figure 2) shows how the overall lifecycle process divides naturally into two major stages. Stage I, Incremental Definition, covers the up-front growth in system understanding, definition, feasibility assurance, and stakeholder commitment. If the Phase I activities do not result in deciding to radically change the effort by adjusting scope or priorities, or discontinuing the development completely, they lead to a larger Stage II commitment to implement a feasible set of specifications and plans for Incremental Development and Operations.

The duration of Stage I can be anywhere from one week to five years, depending on factors like the number, capability, and compatibility of the proposed system’s components and stakeholders. A small, experienced, developer-customer team, using agile software methods and operating on a mature infrastructure, can form and begin incremental development of a well-defined software project in less than a week. A more complex project requires significant effort and could take up to five years or more. An example might be an ultra-large, unprecedented, multi-mission, multi-owner, system-of-systems needing to integrate with numerous independently evolving legacy or external systems. We have provided ICSM elements to the definition and development of such systems.5

Stage II is planned around the length of the increments to be used in the system’s development and evolution. This is a key decision made during the Development Commitment Review. A small agile project can use two-to-four week increments. A much larger project could need increments of up to two years to develop and integrate an increment of operational capability. However, the ICSM capability delivery cadence is not necessarily linked to the internal development cadence, and there may be several internal integration cycles within a longer release increment. Some large, inseparable, hardware components would take even longer to develop their initial increments, and would be scheduled to synchronize their capability deliveries with concurrently evolving infrastructure or software increments.

Stage I activities have assured a common vision, committed stakeholders, and an architecture capable of accommodating foreseeable changes such as user interfaces, external system interoperability requirements, or transaction formats. These enable the features in each Stage II increment to be prioritized and the increment timeboxed.

Flexible, Multiple and Evolving Processes

The ICSM essentially uses evidence and risks to generate appropriate processes throughout the lifecycle. Figure 3 illustrates four example paths through the ICSM to visualize how different risks create different processes.

Example A is a simple business application based on an already-available Enterprise Resource Planning (ERP) package. There is no need for a Valuation or Architecting activity if the ERP package has already been purchased and its architecture has already proved cost-effective in supporting more complex applications. Thus, the project can go directly into Stage II, using an agile method such as a combination of Scrum and Extreme Programming. There is no need for “Big Design Up Front” activities or artifacts because an appropriate architecture is already present in the ERP package. Nor is there a need for heavyweight waterfall or V-model specifications and document reviews. The critical risk identified at the end of Exploration could be the user acceptance and business process reengineering required for deployment. In this case, that risk would be considered negligible if the system’s human interface risks have been sufficiently mitigated via ERP package-based prototyping.

Example B involves a risky but innovative system such as adding a retina scanner to the next model of a cellphone product. There are a number of uncertainties and risks/opportunities to resolve, such as scanner hardware integration and safety of the user. But the new capability is needed quickly and there is a fallback (deferring its introduction to the following model), so proceeding to address the risks and develop the system is acceptable.

Example C is a system that is defined as safety critical. The stakeholders responsible for the safety of the proposed system find at the Foundations Commitment Review that the proposers have provided inadequate safety evidence. It is better to have the proposers develop such evidence through architecture-based safety cases, fault tree analyses, and failure modes and effects analyses before proceeding into the Foundations phase. The arrow back into the Valuation phase indicates this.

In Example D, the developers are simply too late to play. It is discovered before entering the Development phase that a superior product has already entered the marketplace, leaving the current product with an infeasible business case. Here, unless adjusting the project’s scope can make a viable business case, it is best to discontinue it. It is worth pointing out that it is not necessary to proceed to the next major milestone before terminating a clearly non-viable project; however, stakeholder concurrence in termination is essential.

ICSM Risk-Driven Common Cases

Many projects can reuse experience from previous projects. However, every project has the possibility of unique aspects that could impact the selection of processes and the path through the ICSM. To enable early estimation, supply examples that help users with initial planning, and support categorization and capture of lessons learned, we have identified a set of seven risk patterns that represent the most often seen paths through the ICSM. We have named these patterns Common Cases:

• Software application or system

• Software-intensive device

• Hardware platform

• Family of systems or product line

• System of systems (SoS) or enterprise-wide system

• Brownfield modernization

Table 2 briefly describes when to use each common case and some examples of each.

ICSM and Large, Complex Systems

Obviously, larger, more complex systems will require a great deal more activity in Stage I. In Stage II, however, the ICSM allows a great deal of flexibility in providing a way of integrating and accommodating the wide variety of development activities that can appear across the various hardware, software, and human development activities. For that reason, the Implementation Phase is based on a three-tiered, timeboxed process that allows for reflection, anticipation, and adjustment to the changing environment, shown in Figure 4. This concept works best in software, but can apply to hardware in many cases. Figure 5 shows how this three-tiered model scales to multiple component or subsystem development.

ICSM and Process Improvement

ICSM is designed to provide flexibility. It also expects you to evaluate and apply the process assets you already have in new ways, and provides essential guidance on hw that can happen. ICSM also seeks to actively create and use lessons learned both within and between projects to decrease the learning cycle and accelerate improvement. The key intrinsic process improvement aspects in ICSM are evidence, risk-based process, the incremental approach, and anticipation/reflection.

In the ICSM, evidence is continuously created as a first class deliverable and used for process generation, decision-making, and stakeholder commitment. This evidence captures a wide variety of knowledge in a way that can be empirically analyzed to support retrospection at almost every point in the lifecycle. It can also be used to improve estimation, evaluate experimental processes and methods, and transfer knowledge across projects and systems.

As with many process models, risks are captured and tracked. However, in the ICSM they also directly impact the process generation activities and are integrated into all decision-making. Many risks are common across a domain, and so mitigation efforts based on ICSM process decisions are documented and can be easily captured to support decision-making and process generation across projects.

The incremental nature of the ICSM shortens the learning cycle. Agile and lean development methods with short cycle times, value-based scheduling, and continuous integration can be employed wherever appropriate. Coupled with the ICSM emphasis on evidence and risk, these can accelerate learning, reduce rework, and manage technical debt in such a way as to provide continuous process improvement throughout the Stage II activities.

Finally, process improvement requires balanced reflection and anticipation. Wayne Gretzky, who is generally acknowledged as the greatest hockey player of all time, ascribes a good deal of his success to the ability to anticipate where the hockey puck was going, and to skate to where he could capitalize on that knowledge. Anticipating where technologies, competitors, organizations, and the marketplace are going is increasingly critical to successful systems and software engineering. In contrast, organizations that spend their time asking, “How could we have done our last project better?” are actually skating to where the puck has been. Clearly, such “reflection in action” is good,6 but in a world of rapid change, reflection in action needs to be balanced with anticipation. The Incremental Commitment Spiral Model integrates reflection, anticipation, and agility to take advantage of evolving knowledge through a risk-based, principle-driven approach to system development. We are still firm believers that there are no panaceas, silver bullets, or one-size-fits-all solutions. We are confident, though, that the ICSM offers a coherent and useful way to approach systems development in a world that has not only changed, but will also continue to change throughout every system’s life cycle.

Conclusions

Procrustes caused a lot of damage before Theseus turned the tables (or the bed) on him. We believe that there are a lot of ways to fight procrustean tendencies through rethinking the processes we advocate, and pushing back on those who are applying inappropriate or damaging processes to our projects. One of these ways is using the process generation framework provided by the ICSM. Table 3 shows how the ICSM can mitigate our earlier list of procrustean issues.

ISCM supports adapting and applying multiple processes (or process assets) as needed throughout a project, regardless of size, duration, or complexity. It provides a flexible, extensible lifecycle that can be adopted across a wide variety of project environments. Most importantly, it establishes all of the underlying principles of high maturity organizations— stakeholder value, incrementality, concurrency, agility, flexibility, empiricism, improvement and predictability—without restricting the specific processes deployed. ICSM enables the opposite of a procrustean process: one that adapts to your needs rather than forcing you to meet its own.


References and Notes

Notes:

1. Boehm, B. and J. Lane, “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, October, 2007

2. Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner, The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Addison Wesley Pearson, New York, 2014.

3. Boehm, B. “A Spiral Model for Software Development and Enhancement.” Computer. May 1988;61–72.

4. CrossTalk. “Top Five Quality Software Projects.” January 2002, July 2003, July 2004, September 2005. www.stsc.hill.af.mil/crosstalk.

5. Stephen Blanchette Jr., Steven Crosson, Barry Boehm, “Evaluating the Software Design of a Complex System of Systems,” CMU/SEI Tech Report CMU/SEI-2009-TR-023, January 2010

6. D. Schon, The Reflective Practitioner. Basic Books, 1983.

References:

1. Much of the material in this article is drawn from a new book: Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner, The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Addison Wesley Pearson, New York, 2014. The initial work that provided the basis for the book was funded in part by the US Department of Defense, through the Systems Engineering Research Center, a University Affiliated Research Center at Stevens Institute of Technology.


Richard Turner

Click to view image

Dr. Richard Turner has more than thirty years of experience in systems, software and acquisition engineering. Currently a Distinguished Service Professor at the Stevens Institute of Technology in Hoboken, New Jersey, he is co-author of three books: Balancing Agility and Discipline: A Guide for the Perplexed, co-written with Barry Boehm, CMMI Distilled, and CMMI Survival Guide: Just Enough Process Improvement. Dr. Turner is a Fellow of the Lean Systems Society.

E-mail: rturner@stevens.edu

Barry Boehm

Click to view image

Dr. Barry Boehm is a USC Distinguished Professor and Chief Scientist of the DoD-Stevens-USC Systems Engineering Research Center,. He was director of DARPA-ISTO 1989-92, at TRW 1973-89, at Rand Corporation 1959-73, and at General Dynamics 1955-59. He is a Fellow of the primary professional societies in computing (ACM), aerospace (AIAA), electronics (IEEE), and systems engineering (INCOSE), and a member of the U.S. National Academy of Engineering.

E-mail: barryboehm@gmail.com

Richard Turner

Click to view image

Dr. Richard Turner has more than thirty years of experience in systems, software and acquisition engineering. Currently a Distinguished Service Professor at the Stevens Institute of Technology in Hoboken, New Jersey, he is co-author of three books: Balancing Agility and Discipline: A Guide for the Perplexed, co-written with Barry Boehm, CMMI Distilled, and CMMI Survival Guide: Just Enough Process Improvement. Dr. Turner is a Fellow of the Lean Systems Society.

E-mail: rturner@stevens.edu

Jo Ann Lane

Click to view image

Jo Ann Lane is currently the systems engineering Co-Director of the University of Southern California Center for Systems and Software Engineering, a member of the Systems Engineering Research Center Research Council representing the system of systems research area, and emeritus professor of computer science at San Diego State University. Her current areas of research include system of systems engineering, system affordability, expediting systems engineering, and balancing agile techniques with technical debt.

Phone: 858-945-0099
E-mail: jolane@usc.edu

Supannika Koolmanojwong

Click to view image

Dr. Supannika Koolmanojwong is a lecturer and a researcher at the University of Southern California Center for Systems and Software Engineering. Her primary research areas are Software Process Improvement, Software Process Quality Assurance, Software Metrics and Measurement, Agile and Lean Software Development and Expediting Systems Engineering. She is a certified scrum master and a certified Product Owner. Prior to this, she was a software engineer and a RUP/OpenUp Content Developer at IBM Software Group.

E-mail: koolmano@usc.edu

Richard Turner

Click to view image

Dr. Richard Turner has more than thirty years of experience in systems, software and acquisition engineering. Currently a Distinguished Service Professor at the Stevens Institute of Technology in Hoboken, New Jersey, he is co-author of three books: Balancing Agility and Discipline: A Guide for the Perplexed, co-written with Barry Boehm, CMMI Distilled, and CMMI Survival Guide: Just Enough Process Improvement. Dr. Turner is a Fellow of the Lean Systems Society.

E-mail: rturner@stevens.edu


« Previous Next »