Skip to content

Dependencies limit the possible sequences of events

If you missed the previous articles from the CM Baseline series, please check them out first:

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.  
functional or technical dependency
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. 
overlapping change dependency 

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).
change dependencies
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.
planning bandwidth

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
Task Dependencies
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

6 thoughts on “Dependencies limit the possible sequences of events”


    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.

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

  3. Pingback: Timing is Everything - MDUX

  4. Pingback: 5 Ways a CM Baseline brings value - MDUX

Leave a Reply

Your email address will not be published.

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.