This blog runs through some basic dependency mapping that we are doing within my team, and the approach I sometimes take to manage project deliverable’s in a large scale project environment.
There are many different approaches that can be taken to do this, but i will show how i am doing things now.
Road Map Level Dependencies.
You can see basic dependency mapping that we did in BiZZdesign Enterprise Studio (BES). We have three projects; they are work packages in ArchiMate that are pinned to a timeline.The arrows between them are triggering relationships; Project A triggers project B, which then triggers project C. These relationships are causal. In BES creating a “Roadmap view” enables us to easily shift these things around.
The warning triangle is shown because project C is starting before project B is over. When we are doing agile project development each work package should have well defined deliverable’s and is well scoped with goals which are sufficiently defined so we can measure the success of a project.
Dependencies in the I&M Views
In Planning Work In Archimate I introduced an Implementation & Migration view – which shows a work package with a dependency, Within this view you can see the work package and deliverable’s.
In a larger scale, different architects may be modelling these packages with managers, and we will typically have those views for each project. This is good for individual projects but doesn’t work if we want to understand dependencies across the top level for all projects. The view above may also include dependencies on other deliverable’s. Its important that we get project managers to sign off on these views and document that somewhere, because as projects get more complex, its easier to have discussions on roadmaps with leadership teams where the different project owners have committed.
Real World Deliverables.
So in the real world the triggering relationships between work packages like shown in figure 1 are often not enough. Projects sometimes have several deliverable’s delivered within a project timeline, or other projects outside our project scope need them. Sometimes projects start early or are run at the same time because management will apply pressure to “start now” (also known as “jumping the gun”). Take a look at Figure 3:
When talking to different project teams about deliverable’s they will state dependencies on other deliverable’s in other projects. when drawing those together I use accessing relationships – for example project C within the view above reads Deliverable B. In taking the deliverable centric discussion if we are looking we have discovered a new dependency shown here in bold. Project E should not start until after Project B.
To my mind, the best scenario is when work packages have dependencies between each other. Project C or Project E should not start until project B is completed. Work packages should have resources allocated so they can start, and continue to the end focusing on a clearly defined goal, and once that is achieved, move on to the next thing. Its well known in scientific circles that people cannot multi task. The triggering relation is a causal one, perfect for expressing one thing starting after another. Realistically though, I don’t always get my own way, so triggering one project after another doesn’t always work for me in the real world!!
The reason my deliverable dependencies are denoted by accessing relationship is that work packages can exhibit behavior, but deliverable’s are passive structural elements; so we cannot use triggering relationships.
When running through this exercise of mapping with different project teams we can build much more realistic road maps, avoiding chaos when knowing the exact impact when a project is either delayed or stopped. We often draw the final road maps without the dependencies – and its quite often when projects are running their own individual lives that nobody keeps track of a dependency & deliverable map. In having this we can help inform our stakeholders and help them make better decisions when prioritizing projects. If we just look at the navigator in figure 5 you can see for project C that the dependencies for the project are easily visible; they are accessed. The deliverable’s are very visible, they are realized. Project to project dependencies are shown and easily understandable Note, there are some extra objects on that package where I have used project C in other blogs.
Focusing on the deliverable
In figure 1, I showed a dependency relationship with warnings. Sometimes that cannot be avoided for reasons outside of our control. I recently removed all the dependency relationships from a road map just because they made it too messy and complicated.
In cases where the project structures look messy I will sometimes create a road map with deliverable’s only on it, so i can see delivery dates rather than the projects themselves.. Most management do not need exposure to a view like in figure 4 – but its essential for project managers to understand these dependencies between projects, because without understanding dependencies project plans are likely to be unrealistic. there’s nothing worse than a project getting half way through and then discovering they will be delayed because another team hasn’t delivered something important. In an ideal world strict project discipline and work packages are defined to deliver single agile work packages. As things get larger scale things often get more complex, and this blog demonstrates a technique I have actually used in order to dig into some of those complexities..
Using Associations To Denote Dependency
I would like to say thanks to Eero Hosiaisluoma for pointing out two things. First I had inadvertently reversed the directions of my access relationships in the original article. Second was pointing out that in Archimate 3.1 we can also denote direction on an association relation, which we could use instead of the accesses relations. Where I work our standard is ArchiMate 3.0; so I didn’t even think to mention this.