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.
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 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.
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