1

I have to make an AOA diagram in which the following situation occurs:

+---+----------------+--------------+
| # |  Description   | Predecessors |
+---+----------------+--------------+
| C | Welding        | B            |
| D | Removing slack | C            |
| E | Filling tank   | C, D         |
+---+----------------+--------------+

Since C is a predecessor of both D and E, but E is also dependant on D, can I simplify the diagram to just a sequence of C->D->E ? If not, would the diagram be as following: No simplification

Or am I allowed to simplify in this case, so the result is as following: With simplification

To me it seems weird both to have a node with just two incoming dummies, but also to just to fully drop a predecessor relationship like nothing happened. Am I missing something?

| improve this question | |
2

I'm going to go the other route from the existing Answer and ask:

What useful information does the first diagram have that the second does not?

Going by the law of transitivity, if C implies D and D implies E, then C implies E. Thus, I would argue that your first diagram is stating that 'C implies E' twice.

The only scenario I can think of for this to be useful is if you really, REALLY need to check that C is done before starting E, regardless of whether or not D has been done yet. Which, in turn, implies both that:

  1. 'C->D' is a 'soft requirement', in that it is possible it might not be upheld. That is, we can't trust that C was done even if we know that D was.
  2. We care more about C->E than we do about any of the other predecessor dependencies.

I don't think either of those apply in your situation. Perhaps you can think of some other reason for which stating 'C->E' twice is useful. If you cannot, I would suggest for you to simplify the diagram.

| improve this answer | |
  • The fact that two people give different answers is very interesting. Is there, by any chance, a reference about transitivity in AOA's? If not I think that maybe there should be, since a model only retains its value if everyone uses it the same way. Food for discussion? – JohannesB May 5 '18 at 10:45
  • I guess "Perhaps you can think of some other reason for which stating 'C->E' twice is useful." says it all: readability. So there's two doors for you: one with logical correctness, the other with communicating information at a glance. My two cents: when looking at a diagram, I want to understand the whole project. So I definitely don't want to think about transitivity. But technically speaking, @Sarov has the better answer. – Stephan Weinhold May 5 '18 at 20:01
1

First I'd adjust the length of the arrows to the length of the task. At least that's the way I'm using it.

Ad your question: You are not required to use dummy activities. But I'd chose to do so. Simply, because they can help to reduce complexity. So in your case I'd vote for the first diagram. I can understand it at a glance without having to read and think.

| improve this answer | |
  • Ignoring the arrow lengths for a second, do you think this would hence be the correct solution for this process table ? To me that seems reasonable, because otherwise the diagram would just be one big sequential process, which loses a lot of information. – JohannesB May 4 '18 at 10:11
  • I would have drawn it the same. That long process would be hell to understand. And with your version you can see the dependencies at a glance. – Stephan Weinhold May 4 '18 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.