It is not a single one-size-fits-all process model, but a process model generator that enables projects to use their risk patterns to determine their best-fit process.  It has a set of common risk patterns that indicate when it is best to use various forms of agile,  plan-driven, or other forms of development.  Its incremental commitment decision points enable projects to adapt their processes as new needs and opportunities arise.
2. What is the purpose of the ICSM, and how can projects apply it?
 Its main purpose is to provide organizations with increasingly diverse classes of projects with an alternative to trying to fit them all to a one-size-fits-all process model, but also to use its four guiding principles as a basis for achieving shared project values.
3. Can you name some of the benefits that organizations can get from using the ICSM.
 Ensuring project success by making winners of the project’s success-critical stakeholders.  Reducing rework, technical debt, and project overruns by using risk- and evidence-based decision milestones.  Better adapting to increasing rates of change via incremental system definition and development.  Summaries of benefits are provided at the end of Chapter 0 and in Chapter 12.
4. There are four key principles which are underlying the ICSM. Which are they, and what makes them so important?
1. Stakeholder value-based guidance.  Neglecting success-critical stakeholders generally leads to an unsuccessful project or enterprise.
2. Incremental commitment and accountability.  In an era of increasingly rapid change, single-step, fixed requirements projects generally lead to obsolete systems.
3. Concurrent multi-discipline engineering. Sequential requirements-first or hardware-first approaches take too long and often over-constrain attractive cyber-physical-human systems solutions.  Multiple stakeholder value propositions require concurrent attention to their reconciliation.
4. Evidence- and risk-based decisions. Shortfalls in evidence of a proposed system’s superiority or feasibility are uncertainties and risks of unsuccessful projects.  Chapters 13 and 14 elaborate on how to develop and evaluate evidence.

Chapters 1 through 4 elaborate on the principles via failure and success stories and implementation guidance.
5. The ICSM is not a monolithic one-size-fits-all process model.Organizations can use the model to define and enhance their processes. Can you elaborate on that?
This is covered by the answers to the first two questions above.  Some projects with lower criticality and rapid change are best done with agile methods; others with high criticality and relative stability are best done with plan-driven methods.  Large projects may find it best to do agile in some parts and plan-driven in others  The ICSM provides decision criteria for choosing the best-fit approach among these or other methods.  Chapter 11 elaborates on the common cases.
6. I like the case studies that are provided in the book, for me they visualize how the ICSM can be deployed. Could you highlight one of case study?
A good one to highlight is the successful Intravenous Medical Pump project in Chapter 1.  It had complex combinations of hardware, software, and human factors to address,stringent safety requirements, and a very competitive schedule, and used the ICSM approach to produce a technical award-winning and  highly successful marketplace product line.
7. Is it possible to combine the ICSM with agile frameworks like Scrum, DSDM, SAFe, or DAD? Can you give some examples showing how it can be done?
Table 11.3 in Chapter 11 provides criteria (size/complexity, rate of change, criticality, non-developmental item support, personnel capability) for determining agile and 9 other common process cases.  One of these,  Architected Agile, is very similar to DAD.  Table 12-1 in Chapter 12 identifies a couple of dozen good practices that are compatible with various of the common cases, including Scrum, DSDM, and SAFe.
8. The ICSM also covers dealing with risks and opportunities, suggesting an incremental approach. How can you do this, and what is the advantage of addressing risks and opportunities incrementally?
The longer a risk is not addressed, the more risky commitments the project will make, causing an increasing buildup of technical debt that is increasingly expensive to pay off.  Chapter 15 addresses the five major ways of dealing with risk: buying information, risk avoidance, risk transfer, risk reduction, and risk acceptance.  Buying information via prototyping, modeling, simulation, stakeholder interviews, reference checking, or other methods is the best way to determine which of the other four approaches to take.  The three ICSM system definition stages, Exploration, Valuation, and Foundations, are all about buying information to reduce risk and acting on it, as discussed in Chapters 6, 7, and 8.  Chapter 9 provides an approach in which a separate agile systems engineering team addresses emerging changes and risks, and rebaselines the plans for the next development increment while the developers are completing the current increment.  Each of these chapters include a list of most frequent risks to watch for at the end of the phase, and illustrates the practices via a single-thread Medical First Responder System example.
9. If an organization would like to deploy the ICSM, what would be a way for them to start?
It is best to start incrementally with the practices that would be most cost-effective to implement, such as adding feasibility evidence to the items to be evaluated at decision milestones, prioritizing increment features to support timeboxing,  and adding an agile change assessment and increment rebaselining team to the development phases, as discussed on Section 0.5 of Chapter 0.  As a bottom line, it is not a bad idea to incrementally commit to the ICSM.  Other ways to start would be to visit the ICSM web site at http://csse.usc.edu/ICSM, which will include times and locations for upcoming ICSM tutorials.

Leave a Reply