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.

8 reasons not to leave architecture to the end of a project

Sometimes I see architecture left until the end of a project. These 8 reasons are the reasons I normally try to push for it earlier.

There have been times in the past where I have been pulled in at the end of a project and told that the project has implemented a technical solution and there’s a requirement by the customer for it to be documented and when that happens I get a little sad inside. In large projects one person never has all the information. This blog is from personal experience from working at different companies over the last 25+ years.

Its worth mentioning at this point that design doesn’t all have to be done at once in a waterfall fashion it can be agile. I will talk about this in later blogs.

Documenting architecture always has value, but much of the value you would get from an architecture practice has gone if you start doing architecture at the end of a project. The bigger the project the bigger the problem. Lets get started:

1 – It takes more effort doing it at the end.

When you do architecture at the end of the project you have to take time to understand everything that’s happened. This includes understanding how requirements have been realized and what decisions have been made

As you start to understand the scope and concepts behind a solution questions arise. I might go to one person and ask the answer – they typically wont know. or may have part of the story. They lead me to other resources and it could take me hours of time just to find out why a single decision has been made.

If a team had been working together on a single architecture throughout a project you don’t burn that investigative time trying to understand things. It’s not always obvious what necessitated a decision, so its important to track decisions in a single place.

2 – Its expensive

Time is money – exploring the rationale behind decisions and understanding whats happened at the end means having to engage lots of people. If an architect has a meeting with three technical specialists for an hour that’s 4 hours of work time. When they don’t have the answers to hand – they have to write emails, contact other people, and come back to the architect – that’s also burned time. If the decisions had been put into an architecture as they were made, in some projects its possible to save hundreds of hours.

The same idea applies with things like requirements realization. If you haven’t shown exactly how each requirement has been realized in architecture you will have to investigate each one. If you are in a project with a 1000 requirements and spend 15 minutes investigating each requirement then potentially you would have to spend 250 hrs just figuring this out (more, if you consider you need to engage other people).

Map the requirements at the beginning of the project and make sure you create some kind of requirements realization within a project. Keep a log of all the decisions made, together with the activities taken around each requirements together in one place. This extra effort will save time and money as a project moves on and resources come in and out of projects. It will kill the need for new architects (or other people) having to “investigate” to understand status at the end of a project and will reduce the number of meetings you need during the project.

3 – Its hard to build well under time constraints

At the end of a project there are normally time pressures because people want to shut things down.When I am having to investigate the architecture designs and their rationales, I need to take time. If organizing a meeting to understand how we realized one requirement takes an hour, and may not yield the result – other meetings will need to be scheduled in. In a situation when you are given a week to deliver a design near the end of a project – that time disappears very fast if you need to have multiple meetings and rely on peoples availability. This puts deadlines are at risk.

If we are building the architecture throughout a project there is no rush at the end of a project.

4 – Information gets lost

If decisions are made and not recorded in an architecture information very easily gets lost. In large projects many people are involved – sometimes resources get replaced over time and we lose information on why decisions were made. Sometimes that information is recorded but we don’t have access to it. If you have a large project spanning 6 months, that is running a project meeting every morning where they make decisions that’s potentially 120 sets of meeting minutes – assuming those minutes are kept properly and all the information on decisions is available you still need to sift through it. Of course some people make all their decisions in email, sometimes people leave the company, some also forget or don’t write things down.. In these situations you have real problems.

Keeping architecture concerns and decisions documented in a work log as part of your architecture design process throughout the project mitigates this risk. Having that log available on a collaborative platform is essential. if you have to take a conversation in email – paste that to the collaborative log too, so everyone knows everything that happens and there are no hidden caches of knowledge.

5 – You find things that are missed

When you take a structured approach to analyzing requirements and creating a requirements realization view for your solution, things don’t get missed, because an architect is guiding work. This is one reason why we do architecture design in the first place – to make sure a solution is fit for purpose. I’ve often seen functional requirements well considered by a technical team but non functional requirements missed. A technical team tends to focus on things like getting a server up and showing a tangible result.

If you come to the end of a project and suddenly realize the technical solution doesn’t meet your requirements, you are in a bad position. It’s too late to rebuild or change technologies. You may end up having to compromise quality just to get the project ended, or investing a significant amount of time and money re engineering or rebuilding a solution.

The earlier you do a requirements analysis the earlier you find gaps. The hard and sometimes boring requirements analysis part at the beginning of a project is essential. You must make sure that every requirement is realized in a view. At this point you should be also ensuring every requirement has an owner that is managing it. The project managers can then more effectively chase up project status without having to call lots of expensive meetings.

6 – You’ve lost the benefit of concerns management.

There are two ways you can approach things. You can put out a fire in a burning house, or you can stop the fire from happening in the first place, by taking away the matches from the idiot that likes to start fires.

When you are doing architecture properly you are identifying and managing risks before they happen by applying thought and designing things to stop issues from arising. A design uses the shared experience of all those involved to avoid problems rather than the experience of individual resources. Of course you can also reuse designs, but that’s another story.

On the flip side, you can leave implementation of projects to technical resources. and manage concerns as they happen. When this happens you have an escalation culture. You normally end up with managers and a lot of emergency meetings to handle problems, often after the project is implemented, leaving a sour taste in the mouth of both operations and the customer. This is very expensive because its a lot of burned meeting time because you are handling the after effects of a fire happening; which also includes a level of damage control. If a house has caught fire several times during a project the damage has already been done. I’ve seen before entire platforms have to be rebuilt because technical teams have rushed to implement a solution without realizing the requirements or dependencies of other systems around them. I have also seen the same problems reoccur.

Concerns cannot be managed at the end of a project because you cannot go back in time to fix them. The only thing you can do that’s cost effective is manage them as they happen or suffer the cost of potentially needing to redo things.

7 – It ends up frustrating people

When you have the end of a project in sight you want to cross the finish line, the project don’t want to have to deal with an architect coming in at the last minute and finding holes in their work. It frustrates everyone, architect included. If you have left architecture to the end the chances are the budgets are depleted and people are exhausted through overwork because the plan that was executed wasn’t designed and work wasn’t properly estimated. The last thing anyone wants at that point is to realize a technical implementation is not fit for purpose when they cant do anything about it – thats demoralizing.

8 – It results in lower quality

When you consider everything above you will realize at the end of a project to get architecture documentation out, you are going to have to compromise. This for me personally is very hard, because I always want to deliver the best. It may be that the documentation will end up at a high level, or it may be that some concerns will just have to be accepted rather than mitigated. It might be that we need to make assumptions about why things were done, or that we don’t get to model our solution because there just wasn’t enough time. The team may have made costly mistakes during the project. At this point you have ran out of time to address all the concerns.

Its very likely that the quality of architecture will be lower if you used the time at the end of a project just to document architecture, rather than following an architecture practice during a project. Its also likely that because of this approach there will be issues arising once a project goes into service.

If you have viewed architecture as a documentation exercise at the end of a project the chances are that what is implemented doesn’t address all of your own internal non functional requirements, the customers requirements, or other stakeholder needs – because the time at the end of the project was focused on describing what has been put in place rather than what really needs to be put in place.

Architecture and security non functional requirements normally exist to ensure we meet the standards our companies promise, they are designed to protect the company, to mitigate risks risks. They also may address the needs of internal stakeholders and may have been put in place to ensure we learn from the mistakes that our predecessors have made. . If we haven’t designed a solution to meet the needs of all of our stakeholders, then we may well see the same issues reoccurring time and time again.

There’s no worse feeling in the world than having to present forward an architecture that you cant justify or isn’t as good as you would like it to be, because of things that were outside of your control. In such cases I think its always important to be honest, to present the architecture, and also the concerns that you have on it at the end of a project so they can be addressed by other architects or your quality team.

To raise quality we also need to raise awareness. architecture may be difficult and laborious at times, but as I have mentioned in this blog, people need to know the benefits of not leaving it to the end.