If you missed the previous articles from the CM Baseline series, please check them out first:
- Understanding the Impact of Changes introduces the need for the CM Baseline.
- Connections tell the Story introduces 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.
This article will explore the third component of the CM Baseline. Namely, the ‘Dependencies’ or also referred to as 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.
Change Dependencies
Change dependencies are dependencies between changes that directly impact the possible sequence of implementing these changes. You can have dependencies between CRs, CNs, or even between releases of specific datasets. Change dependencies are also inherited when moving through the change process. If you have 2 CRs with a change dependency, then the CNs that implement those CRs also have this dependency.
In various project management methodologies (e.g., Prince2 or PMI), several types of dependencies are recognized:
- Logical dependencies
- Preferential or Discretionary dependencies
- Resource dependencies
Logical Dependencies
Logical dependencies are dependencies where one thing requires another thing. Think about functional or technical interfaces and how you are processing changes that impact both ends of the dependency. In the picture below Change 3 will replace Part3 with Part8, and Change 2 will Replace Part5 with Part9. Because there is a functional (e.g., Part3 supplies power to Part5) or technical (e.g., mating conditions when their parents are assembled into Part7) dependency between these parts. This means that there is a change dependency between Change 3 and Change 2.
Or when multiple changes impact the same Part and/or Datasets. These dependencies are hard and cannot be ignored when sequencing the changes. In the below picture, both Change 1 and 3 impact the same EBOM; however, they intend to replace different parts in the EBOM. That creates a Change dependency. Same for Change 4 and 5, which both impact Dataset2.
Preferential or Discretionary Dependencies
Think about the implementation priority for a change, set by the change board or change authority. The implementation team cannot ignore these priorities without going back to the change board/authority. However, if you have a backlog of changes, the team still has a level of discretion to pick between the changes. Naturally highest priority goes first, but if you have multiple on the list, the team has a say in which one it will pick up first, assuming there are no Logical Dependencies that dictate the sequence of implementing these changes. Also, if the team works with a sprint cycle, and there is room to pick up small change, but that change has a lower priority, the team can still decide to do so.
Also, some preferential/discretionary dependencies will surface when planning the change as the team decides on the tasks and their sequence. Because these dependencies are not fixed and can be modified when needed, I will discuss these dependencies as part of the following article in the CM Baseline Series.
Resource Dependencies
While also being considered dependencies in project management methodologies, Resource Dependencies will be discussed when exploring the last component of the CM Baseline: Planning.
Change dependencies: a map to help navigate the implementation phase
When you combine priorities for changes and the different dependencies you have identified, you get a map showing possible routes to implement these changes. It helps in navigating the implementation phase of changes. When any deviations occur along the way, you can immediately see how this will impact your change dependencies and the possible routes to mitigate the problem(s).
You can translate this map into a sequence that will, in the end, also depend on resource dependencies. But it shows you the longest path, the shortest path, and therefore the planning bandwidth you have to implement all the changes in the backlog.
Define Change dependencies as Task dependency
When possible, it is advised to express change dependencies as a task dependency, because that makes the change dependency usable/actionable. Four types of task dependency exist:
- FS – Finish to Start | Task B can start when Task A finishes
- SS – Start to Start | Task B can start when Task A starts
- FF – Finish to Finish | Task B can finish when Task A finishes
- SF – Start to Finish | Task B can finish when Task A starts
When you add this information to the CM Baseline, you can take into account the planned changes and how they depend on one and another. Also when plans start to shift these dependencies will directly be impacted and you can see the solution space you have to mitigate any issues that might surface.
Header Photo by Clint Adair on Unsplash
Hey Martin. Thanks for the valuable remarks and method again. As far as I understood, Change Implementation Leader should combine all changes to prepare mentioned map. At that point, how does the Change Implementation Leader ensure, all dependent changes are included in specific CIB agenda? Cause, it is really painful action to get related changes at the same time since change owners & change scope might be different.
Hi Hatice. Thanks for your comment. The implementation map is more a result of all the change dependencies combined. This includes the priorities set by the Change Review Board (CRB). So in a sense, I envision that the Implementation Map can be generated and can be used as input by the Change Implementation Leader (CIL). The CIL can identify what the best implementation path will be (and in that way ensure all dependent changes are included in the specific CIB agenda) and start planning the change. This is more from an end state perspective, it can be that in intermediate states the CIL needs to do some work to get the implementation roadmap, but because the dependencies are clearly recorded in the Baseline it should be possible to identify the dependent changes for a CIB agenda.
I hope my answer helps. If not let me know.
Exactly, I got it right now. It seems that baselines produce butterfly effect as properly defined structure triggers more healthy results in implementation period as you emphasized in most articles.
Spot om! It is indeed a positive cascading effect that will improve the overall quality of doing change.
Pingback: Timing is Everything - MDUX
Pingback: 5 Ways a CM Baseline brings value - MDUX