Critical Path Analysis

Question

I'm currently looking at a past paper question regarding CPA. The question concerns the following subtasks.

The subtasks are denoted A, B, C, D, E, F, G, and H.

Subtask B cannot start until subtasks A and C have been completed.

Subtask C cannot start until subtask A has been completed.

Subtask D cannot start until subtask B has been completed.

Subtask E cannot start until subtask B has been completed.

Subtask F cannot start until subtasks D & E have been completed.

Subtask G cannot start until subtasks F & H have been completed.

Subtask H cannot start until subtasks A & C have been completed.

My question concerns A, B, C and H.

C cannot start until A is completed. B cannot start until A and C are completed. Why does it say it has to wait for A and C to be completed? Likewise with subtask H?

C can only be started when A has been completed - why doesn't it just say it has to wait for C? Is there another layer of complication here? Surely the completion of C implies the completion of A?

The first part of the question is to draw the diagram of the above sub tasks.

Answer 1

If it is an exam question, then it stands to reason that it is intentionally confusing. Simplifications such as applying the Law of Transitivity are intentionally avoided.

That being said, it is not inconceivable to have (the first draft of) dependencies looking like this in the real world.

Betty says she cannot start her work until Alice and Charlie are done theirs.

Charlie says he cannot start his work until Alice is done hers.

Daniel says he cannot start his work until Betty is done hers.

etc.

Though the dependencies can (and should) be simplified, the people who perform the tasks may not themselves have all the necessary information to do so, and thus, if you were to get information directly from them without analyzing and transforming it, you would end up with something akin to the above.

Answer 2

While recognising that this is an exam question, this type of situation is common in many projects, especially where dependencies are identified and entered into the plan at different stages in the planning process. By allowing these "non-optimised" relationships to exist in the plan, you can avoid a lot of manual rework and potentially breaking links that should not be broken.

It can also happen where the list of tasks is much longer and more complex than the list that you have been asked to consider, and where the subtlety of the inter-dependencies is less obvious. By keeping the "non-optimised" dependencies in your plan, you can more easily communicate to others, especially if they are in different parts of the organisation. For instance, if you have a hardware team, a software team, and a test team, the testing tasks may need to follow both the hardware deployment and the software installation. It may be obvious that the software installation can't take place until after the hardware is in place, but the hardware guys will only want to know that their work has to be completed before the testing has started. They may be completely uninterested in the software tasks, and never look at that part of the plan!

On the other hand, if you don't need the complexity and can see that it is easy to remove redundant relationships, then do so. It will keep your plan as simple as possible. However, my advice is to make the plan work for you. You are the master of the plan - and an imperfect but workable plan may be better than a perfect plan that takes hours or days of rework to analyse and apply even a simple change.