last week, i taught a primavera p6 training course to some great folks in frosty fort mcmurray.
as often happens, an interesting question came up about critical path. and this is not the first time this question has been put to me. but this time, i thought i would write about it.
“how do i put an activity on my project’s critical path in primavera p6?”
so here’s the situation. a project schedule has been built and scheduled in primavera p6. but for some reason, the planner is unsatisfied that activity z is not on the critical path. so, dear expert, how can i put it on the critical path?
why should an activity be on the critical path?
to really answer the question of “how” to alter a project’s critical path, we need to first ask “why”? what is the end-goal?
here are a few common responses i hear from planners:
1) the activity is “critical” to success of the project – it should be on the project’s critical path.
as murray woolf points out in his though-provoking article “when is the critical path not the most critical path”, there are 22 distinct definitions for the term “critical path” according to google results.
which means that your definition of critical path may not be the same one used by your client or even your boss. trouble!
sometimes we want to highlight an activity for it’s importance to the successful completion of a milestone or the project itself. however, adjusting a project’s logic just to ensure that an activity shows as red on the gantt chart is not the right approach.
project logic is meant to plan the order of execution of activities. the order is declared in the planning process.
we should not alter a project’s critical path just to highlight activities as “important”. use activity codes or udfs to define and track the “important” activities.
if you want to go deeper on this matter, then read murray’s article. in it, he suggests a paradigm shift in how we define the criticality of an activity and what project activities are most “critical”.
2) i think/suspect activity z should be on the project’s critical path.
review your project’s existing logic, and assess whether that is true or not. does activity z fit into the proper sequence of activities on the project’s critical path?
if the activity was incorrectly linked, or circumstances have changed the order of execution, then adjust activity z’s logic accordingly to put it on the critical path.
always make a backup before you alter your project’s logic. but also think about the impacts of these kinds of changes.
what are the impacts of adding an activity to the critical path?
change logic can alter the critical path downstream, so compare your project’s old critical path to the new one.
document all changes in a notebook topic or somewhere similar.
ask any of the forensic scheduling experts on linkedin and they’ll tell you that adjusting the project’s logic during the execution of a project without justification and agreement from your client can lead to a lawsuit. so better play it safe and do the right thing.
what do you think?
what are your thoughts or questions about critical path changes? drop us a comment below.
