Working With Deliverables

Following my previous blog on Working With Projects & Dependencies I wanted to say a little on working with deliverable’s and avoiding some pitfalls.

I wrote this blog to address some trends I am now seeing with new architects modelling implementation and migration architecture for the first time because its really important to get this right. This is aimed at beginners.

What is a deliverable?

The ArchiMate 3.1 Specification says.

A deliverable represents a precisely-defined result of a work package.

Figure 1: Projects & Deliverables

So simply put, when we do work in a work package, we expect a result. Work packages realize deliverables & in my last blog I showed how I manage link dependencies from one work package to another by accessing (reading) the deliverable that is realized by another project.

Its not the only way we can work with this, but its a way that works.

Common Issues In Naming Deliverables

Correctly Scoping The Name

Each element in an architecture model is reusable and may be used in many views. This means you need to be specific to the context you are modelling in. For example lets say we name our deliverable “High Level Design Documentation”. It is a fairly generic name that would be an object that many architects may want to use. When we are thinking of using specific elements in specific contexts we need to get this level of abstraction right. If we are documenting an element named “High Level Design Documentation” then we can only document things that are specific to all high level designs (HLDs). if we needed to say something specific about a project, we would need to name it in a way that’s identifiable as a project specific element; Its far better to name it “Project A – High Level Design Documentation” in such a case.

I spoke about this in my blog Documenting An Architecture Model.

How we scope the element is dependent on how we will use it. In the case of “High Level Design Documentation” – If every project has exactly the same requirement to deliver exactly the same type of document its tempting to just reuse the same element on each project. That’s a really bad thing if you are trying to dependency Map because then every work package would have a relationship to the same element and you would have no way of differentiating between the different deliverables. Figure 2 is an example:

Figure 2: Using same High Level Design Documentation element (A bad idea)
Figure 3: Navigating High Level Design Documentation

The view looks easily understandable but it is bad in the when we look at this in the model. In figure 3 we can see the relationships for the High Level Design Documentation Element. There’s no way of telling that project A can run completely independent of project C, because project C accesses high level design documentation, and there is no difference between the element realized by project A to the one realized by project B or C.

Correctly Scoping the Element With Specialization

So if we want to show we have a standard high level design and maybe have the documentation of that element reflect the standard, what do we do? The solution to this problem is simple. we use a specialization.

Figure 4 shows several deliverable’s being a specialization of a standard deliverable.

Figure 4 – Specializing a standard deliverable.

Confusing Deliverables With Requirements Or Goals

I have seen sometimes people define deliverable like requirements – where people are thinking about what a project needs to do, rather than what a project needs to deliver. You can think of a set of defined deliverable as a checklist of things that a project should produce. In general I don’t go crazy with this idea. If you saw my blog on High Level Design you could see a design can be composed from many documents, and If I did decide a HLD was a deliverable I wouldn’t model each document, unless I have a very special reason to do so.

In fact if a high level design is part of our standard project documentation – I may not model them specifically at all (See Just Enough Architecture). Some examples of deliverables:

  • Project Standard Documentation
  • Fully Configured Production environment for Project X
  • Updated InfoSec Policy
  • A Deployment Process
  • ISO27k Audit Policy Pass

Looking at the deliverable above you can see a deliverable can be almost anything. I nearly didn’t include ISO27k Audit Policy Pass. The reason being that although it may be a deliverable, its easy to confuse it with a requirement. Deliverable’s are effectively an outcome of the work done to realize a requirement, or goal.

In the documentation for the elements above I might specify further what we need to achieve that deliverable. For example I might elaborate on “Fully Configured Production Environment For Project X” by saying something like:

Production environment implemented and documentation of its acceptance provided by operations and the all the stakeholders shown in the view “Project X Stakeholders”

We don’t need to write a book, but we do need to be precise; specific and measurable.

Focusing On Delivering Documentation

Ok, there are times when documentation is key to the progression of other projects and dependencies, and documentation can definitely be a deliverable. Don’t get lost in doing architecture there – our goal at the end of the day is to have projects deliver value, not to only document. One of my own managers favorite sayings is “Build the hospital, don’t only design it”. The message being is we can spend a long time trying to design a perfect thing, but unless we have a practical implementation for it, its useless. For that reason when looking at any implementation and migration architecture in my own company, we always look to see if there is a deliverable that goes beyond documentation. I think this is good general advice, but I mention this especially for my own architects…

Modelling Too Many Things At The Top Level

In figure 4 we showed Standard high Level Design Documentation as a common deliverable. Standard high level designs may be composed of several documents, and unless there is a very specific need we do not want to model project specific instances of all of them. It would be better to create a view showing the composition of a high level design like in figure 5.

Figure 5: High Level Design Composition View

Summing this Up

This blog was really targeted to address some issues I am seeing right now from some people that are new to modelling completely, and I may have repeated things that I have said in other blogs, but I hope other people find this useful. Having a well defined set of deliverables really helps set expectations.

Working with Projects & Dependencies

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.

Figure 1 – Road map 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.

Figure 2 – Realizing 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:

Figure 3 – Dependencies & deliverable map

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.

Figure 4 – Additional Triggering Dependency

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.

Figure 5 – The navigator view of Project C

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.