Timing is Everything

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

The accuracy of an Implementation Plan is essential for achieving the desired effectivity of a change. However, when it comes to the CM Baseline, Timing is not as important as the accuracy of the change dependencies defined between changes and between deliverables. The change dependencies create the sequence of events, giving us the planning bandwidth and transparency into all potential interferences of the planning with the change dependencies. And that is precisely why the combination is so powerful. Timing is needed to let people know when things need to be done to achieve the effectivity of a change, where the timing can push other changes out due to the change dependencies. Change dependencies can show the impact that timing changes or changes to dependencies can have on the configuration.

No planning in the CM Baseline

The planning activity itself does not take place in the CM Baseline, nor do resource dependencies need to be part of the Baseline. Applying resource dependencies and planning should be done in your planning tool of choice. However, the resulting implementation plan needs to be available in the CM Baseline as it will feed the planning details into the Implementation Map. The CM Baseline must deal with the fact that the Implementation Plan will change over time because of delays or more detailed planning.

The Implementation Map as input for Planning

The Implementation (change dependencies) Map is input for the planning activity. Any violations to the dependencies can be easily reported and acted upon whenever dates are assigned to deliverables.

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

Having a CM Baseline will make it easier to collect timing per type of dataset per type node/object to determine standard timings to support the generation of plans based on the Implementation Map created using the change dependencies. This way, we can speed up the planning process and improve the quality of the estimates.

Combining change during Implementation

Having the Implementation Planning information in the CM Baseline will allow us to see if there are still opportunities to combine work from multiple changes into one revision during the implementation of the changes. While dependencies are essential, the timing is also relevant as it indicates when a deliverable must be completed and if there is overlap on the level of deliverables. If the same deliverables are impacted, and the need dates for these changes are close, combining the work into one might be possible. More on this in future posts when we continue to unravel the possible usages of the CM Baseline.

Header Photo by Matthew Smith on Unsplash