The Incremental Commitment Model organizes software and system engineering and acquisition processes in ways that better accommodate the different strengths and difficulties of hardware, software, and human factors engineering approaches. It also provides points at which they can synchronize and stabilize, and at which their risks of going forward can be better assessed and fitted into a risk-driven stakeholder resource commitment process.
Imagine you are going to Las Vegas. Most software and system projects are developed like playing roulette. You put all your money in at once and hope your number comes up. That is to say, a full set of requirements is specified up front, the full set of resources is committed to an essentially fixed-price contract, and you wait to see if the bet was a good one or not. ICM is more like poker or blackjack. With the ICM, you place a smaller bet to see whether the prospects of a win are good or not, and decide whether to increase the bet based on better information (by seeing more cards) about the prospects of success.
To continue with the poker metaphor, every round of ante or betting is like an Increment. An Archor Point or Milestone is when the dealer starts a round by, say, flipping a card. Feasibility Evidence, as to the success of the project, is the card(s) that are shown. Risk management is seeing how good your hand is compared to what the others might be holding. Stakeholder Satisficing is deciding whether it's worth it to continue betting, and how much. The only place where the poker metaphor doesn't apply is that sometimes there is concurrent development, the simultaneous dealing of cards and betting within a round.
In roulette, nothing can change as soon as the wheel starts to spin. Besides not being able to change your bet, numbers don't suddenly disappear off the wheel, or new numbers start to appear. The technological world is not so static. Software platforms change all the time. Systems depend more and more on being parts of network-centric, collaboration-intensive systems of systems. An incremental model can keep up with the changes that are bound to happen in every project enviornment, due to competitors, relied-upon outside components, or the emergent requirements from each prototype.
