Transition

So Inception handled the risk of creating a project with insufficient value.
Elaboration handled the risk of selecting an architecture that couldn’t handle the high risk requirements.
Construction handled the risk of providing the most amount of the value we identified in Inception.

Transition handles the risk of a valuable project not being adopted into use.

Once we arrive at Transition, we have a complete valuable project with a good architecture. But we have to ensure that the target audience actually uses the product we’ve created successfully or that value is not realized.

Transition ends in one of two different ways, depending on the business you are in. Either it ends with “End Of Life (EOL)” or with “Release.”

If you are responsible for maintaining the product until the product is retired, then Transition ends with EOL. This means that you will continue to add maintenance iterations onto the plan for a long time to come. You will have iterations that basically implement groups of change requests, then release a product upgrade.

If you ever receive a change request that is architecturally significant or that radically changes the vision, what do you do? You probably guessed it. You start a new generation with its own IECT phases. Inception: Does this change have value? What is its scope? Elaboration: Let’s change a small part of the system to prove the architecture will work. Construction: Let’s change the rest providing as much value as we can based on time constraints. Transition: Let’s support the new version.

If you do not have the responsibility for maintenance, then Transition ends with “Release.” This can be because another group will be doing the support, or because you will be turning the source over to a client, etc. In this case Transition is finite and ends when the client or maintenance team accepts that they can successfully own the product now.