0

I'm working on documenting a situation where an activity (call it 'a') which is not itself on the project critical path has a direct impact on an activity (call it 'b') which is on the project critical path. That is, any delay in 'a' results in a delay in 'b' or failure to complete 'a' results in the failure to complete 'b'. What is the most correct way to describe activity 'a'? Is it a secondary critical path or something along those lines?

Thanks for any thoughts!

  • 1
    By definition, the way you're describing this, activity 'a' is ON the critical path. – David Espina Oct 20 '15 at 18:19
  • Thanks. That's been my assertion, but I'm getting pushback on it. As painful as it is to say I might just have to parse the definition from the PMBOK... now to find what I did with my copy. – atomicpedals Oct 20 '15 at 21:53
  • This CP is often misunderstood. I would bet those who are giving you push back is confusing task a is not being "important", thus not on being "critical." That's the most common misunderstanding. But it is the definition. If there is no slack between 'a' and 'b' such that, if 'a' is late, then everything else with zero slack is late, then 'a' is on the CP. Is is part of the shortest path to the finish line. – David Espina Oct 21 '15 at 12:34
  • I'm interested in the reasons for the pushback: who wants to keep it off the critical path & why? Knowing that would help move past terminology & on to substantive pm issues. – Vicki Laidler Nov 23 '15 at 4:57
1

Few thoughts:

If Activity A is part of the project plan, it can be also on the critical path. Please refer your network diagram and also check what is the dependency between Activity A & B. Is it SF, FF..? Based on that you can decide.

If Activity A' work is carried by a third party, then it can be added to your dependency log as well as risk log. Then action plan/mitigation plan should be planned.

0

As it sounds, activity A is not on the critical path (there is free slack in between) and it may be the "Near critical path", so, basically you're talking about the RISK related to task A. There are risks that can make task A slip to the point that it becomes critical and impact the whole project duration.

You cannot do much more than:

  1. Incorporating some contingency/buffer in task A to accomodate the risk

  2. Manage your risks properly, by defining a mitigation plan to avoid the eventuate on of risks that may delay the task and subsequently the tasks on critical path (incorporate mitigation tasks in your schedule)

  3. If there are no other dependencies on task A, consolidate it with task B and manage it as a single effort

There is no recipe in Project Management, different PMs would apply different techniques to make it work.

Good luck

Cheers

  • The OP wrote, "any delay in 'a' results in a delay in 'b'." The words "any" and "results" suggest something absolute, i.e., zero free slack. – David Espina Oct 22 '15 at 12:19
  • The OP also explicitly wrote "which is not itself on the project critical path" which suggests something absolute, i.e., presence of free slack. – TTKDroid Oct 22 '15 at 12:32
  • Those two statements are inconsistent. You cannot have a situation where any delay in "a" results in a delay in 'b' but conclude "a" is not on the critical path. One of these two OP original statements is wrong. – David Espina Oct 22 '15 at 12:36
  • Since this first statement is an observation and the second is a conclusion, I opted to assume the conclusion is wrong. – David Espina Oct 22 '15 at 12:37
  • I'm going All-in OP is talking about "sub-critical" or "near-critical" path activities. Either way, the key is proper risk management on the critical and near-critical tasks so that near-critical doesn't become critical and critical doesn't slip. – TTKDroid Oct 22 '15 at 14:05

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.