Change: Roadmap, Minimum Viable Product (MVP) and States

the pfd of capability based planning .. e.g. the sequence and order that the changes must be made (if there is an order).

identifying the viable architectural states along the way to the target.

Identify the sequence and dependencies across the prioritized list of changes.

This is basically a PFD for the set of changes. (note these are hard dependencies .. not resource dependencies).

Identify groupings of changes that form a Minimum Viable Product at a point in time.

The MVP may stage the implementation of a product over a number of increments. So a product may be broken down into a chunk of work typically delivered in 3 months.

(picture of an item in an mvp moving from 10% complete to 50% to 70% and then to 100% across 4 increments.

Size each of the items in the MVP for the state.

Consider the definition of the MVP and the contents.

This may cause a re-definition of the MVPs. (an iterative process).

Identify points where value is delivered that leads to the target set of changes.

This step associates an MVP to an architecture state. This provides a clear definition of the changes that must be allocated to programmes and projects.

These increments provide a time frame for the realization of the changes.

Focus of increments and iterative development is to fail fast and learn.

Increments may correspond to an architectural state.

typically 3 months between increments.

Architectural states provide a definition of the enterprise that has been realized and value is starting to be delivered.

All architectural states are 'intermediate' except for the last architectural state = Target Architectural state.

Also known as Transitions (MSP and ITIL) or deployments.

Provide a document containing the definitions of the MVP and increments.

Provide a visual representation of the roadmap (a model for the change view).