# How do I know (without error and trial) if an intersection of activities is inevitable in an AoA network structure?

I've been instructed that a good AoA network diagram should have minimal number of overlapping or "kinks" between activities.

But let's say I have a question like this. After numerous attempts, I have realized that there's no way to avoid an overlapping of activities in the network diagram for this question.

Activity Predecessor
A -
B -
C -
D A
E A
F B, D
G C
H B
I F, G

But how do I figure this out without wasting time on making numerous network diagrams before finally realizing a "kink" is inevitable?

## TL;DR

If you've got multiple dependencies on items on the left and duplicates of items on the right, chances are you're going to have some issue with your diagram. If you're asking for a canonical answer, there may be one in set theory or graph theory, but I don't think there's a canonical algorithmic answer that wouldn't be better asked on Mathematics Stack Exchange. The point of laying out graphs for your projects is so you can fix any conceptual, planning, or resource problems that turn up, not to avoid the effort of graphing them in the first place.

## A Quick Example

Aside from pointing out that there's no silver bullet, graphing can be quick. It took me less than a minute to convert the data given in your original question into an acyclic directed graph of dependencies.

How you choose to lay out your graph will determine whether you really have a problem or not. If you graph it as a dependency digraph rather than an activity-on-arrow diagram, absent real data about the activities there's no obvious problem since you don't have any circular dependencies. For example, consider your data rendered with Graphviz using the DOT language and stored in a foo.dot file:

``````digraph {
A
B
C
D -> A
E -> A
F -> B, D
G -> C
H -> B
I -> F, G
}
``````

If you render it with `dot -Tjpg -o foo.{jpg,dot}` then you end up with an acyclic dependency digraph like this one:

There are no confusing dependencies. Nodes A, B, C and E are independent of one another, but the terminal task I depends on A, B, and C (and their dependencies) having been completed. Your longest chain is `A -> D -> F -> I` (three activities for AoA, and four for AoN) which appears to be your critical path.

You might also consider viewing this as `((A -> D -> F) + (H -> B -> F)) -> I` (5 activities for AoA, 7 activities for AoN) depending on whether F is truly equally dependent both chains, or whether I can still be reached or produce value if the goal of the `H -> B -> F` chain isn't fully delivered. Lots of projects have objectives that are "important" but not necessarily do-or-die, and mapping out the critical path can help you make those sorts of decisions.

Meanwhile, E is a terminal activity all its own. It's sitting off by itself, and while it might represent a valuable activity of some sort it isn't really part of the critical path to I. The graph just tells you that the E-node is not central to your longest path, but it doesn't really tell you anything about the value of the activity, or whether it's optional or not.

You can lay out this graph in all sorts of other ways that could produce odd results, and of course it will take a lot longer if you want to fill up your graph with all kinds of additional data on your nodes or arrows. That's entirely beside the point, though.

The reason to graph a project isn't because the graph itself will magically produce an outcome. The goal is to visualize the plan and then make necessary adjustments to your scope, schedule, budget, or even stakeholder expectations so you can improve the project. That could be through simplification, reordering, reallocating resources, trimming non-essential activities (e.g. do you really need Activity E?), or otherwise determining what the critical path should be.

Mapping out a graph tells you what your activity chains currently look like, not what they should look like. The most important part isn't making the initial graph, though. The value of a graph in project management comes from post-graphing analysis. That's when you decide whether the visualized plan actually represents what you want to do, how you want to do it, and the optimal order in which things should be done.

If you don't like the resulting graph, you can re-evaluate the activity chains to identify what can or should change. So, even if you know ahead of time that a graph will have issues, visualizing the work is still an essential step in determining how to organize it better.