In air travel, timing is everything because we do not want to miss our flight or miss a connecting flight. Also, in stories, timing is everything, as it can make or break a story. The same holds for changes; timing can make or break a change. This article will explore the fourth and last component of the CM Baseline: Planning to be more precise Implementation Plans.
If you missed any of the previous articles from the CM Baseline series, please check them out first:
- Understanding the Impact of Changes introduced the need for the CM Baseline.
- Connections tell the Story introduced the first component of the CM Baseline, the Business Object Graph.
- Intentions are the desire for new Stories, introduced the second component of the CM Baseline, the Impact Matrix.
- Dependencies limit the possible sequences of events, introduced the third component of the CM Baseline, Dependencies or a.ka. Change Dependencies.

Pyramid graphic by Martijn Dullaart. Picture of the Impact Matrix: Copyrights by IpX – Institute for Process Excellence from the CM2 courses. Pictures of the Business Object Graph, Dependencies, and Planning by Martin Haket.
Planning: the Implementation Plan
The input for making an Implementation Plan is the Impact Matrix which translates to a work breakdown and the change dependencies that create an Implementation Map (all the possible routes). The next step will be to estimate the effort for each deliverable if that is not done when making the business case for the change request. Typically a change request would get an implementation strategy or guidance on what effectivity is desired. This effectivity would be the basis for planning top-down and defining the need dates for the deliverables to achieve the desired effectivity while considering the possible routes (the Implementation Map). The need dates are the latest due date for a deliverable. It may be delivered sooner, but not later.
Now it is time to apply the resource dependencies. Applying resource dependencies will be done bottom-up. Here, we only look at the effort and need dates to see if our resources can deliver it on time. Or if we go one step further and give a planned release date. In both cases, we will have an Implementation Plan with committed resources.
There are different ways to achieve such an Implementation Plan. The above description matches the more traditional project management methodologies, while an Agile approach might differ.
Implementation Plan per Agile approach
If we used a Scaled Agile approach, we would have defined a Program Increment based on priorities (change dependencies) of changes, which will result in a list of deliverables with associated priorities (change dependencies). The project team(s) will commit to delivering a specific set of deliverables per sprint of the Agile Release Train. So, in this case, planning has several levels. A high-level plan and commitment to deliver a set of changes within a Program Increment (a certain period). While the detailed plan, indicating when specific deliverables will be delivered, is dealt with on a sprint by sprint approach. The scope of a sprint is a commitment to provide the agreed set of deliverables within the sprint time frame. While this might not be the complete change, the change is still committed for the increment. Even if a change is larger than one increment, it just means that the scope of the next increment is already (partially) defined.
Of course, it is possible to mix Agile and classical project management methodologies and tailor them to our own needs. For the CM Baseline, this does not matter.
Planning Accuracy
No planning in the CM Baseline
The Implementation Map as input for Planning

The below example shows the dependency between Change 3 and Change 2. Namely, the logical dependency between Part 3 and Part 5 will be inherited by Part 8 and 9.
In this hypothetical example, the dependency means that Change 3 and at least Part 8 must be released before you can work on Part 9. But in the below planning on the left, we can see that we did not account for this dependency. After replanning and fixing the violation, the plan shifts by one day. Note that all tasks/deliverables were planned with 1 day effort, and we work weekends as well.
In the worst case, if we realize that based on all the dependencies, the change can only achieve its effectivity when it is already too late. We can look for mitigations by adding more resources and changing priorities, but if still the change cannot be implemented in time. It needs to be sent back to the Change Review Board for guidance on continuing.
Standard Timings
Combining change during Implementation
Header Photo by Matthew Smith on Unsplash
Pingback: 5 Ways a CM Baseline brings value - MDUX