{"id":7931,"date":"2013-11-25t11:13:34","date_gmt":"2013-11-25t16:13:34","guid":{"rendered":"\/\/www.deco-dalles.com\/?p=2072"},"modified":"2019-04-08t16:23:31","modified_gmt":"2019-04-08t20:23:31","slug":"can-force-activity-onto-projects-critical-path","status":"publish","type":"post","link":"\/\/www.deco-dalles.com\/can-force-activity-onto-projects-critical-path\/","title":{"rendered":"how can i force an activity onto my project’s critical path?"},"content":{"rendered":"

last week, i taught a primavera p6 training<\/a> course to some great folks in frosty fort mcmurray<\/a>.<\/p>\n

as often happens, an interesting question came up about critical path<\/a>. and this is not the first time this question has been put to me. but this time, i thought i would write about it.<\/p>\n

“how do i put an activity on my project’s critical path in primavera p6?”<\/h2>\n

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?<\/p>\n

why should an activity be on the critical path?<\/strong><\/p>\n

to really answer the question of “how” to alter a project’s critical path, we need to first ask “why”?\u00a0what is the end-goal?<\/p>\n

here are a few common responses i hear from planners:<\/p>\n

1) the activity is “critical” to success of the project – it should be on the project’s critical path.<\/h2>\n

as murray woolf points out in his though-provoking article “when is the critical path not the most critical path”<\/a>, there are 22 distinct definitions for the term “critical path” according to google results.<\/p>\n

which means that your definition of critical path may not be the same one used by your client or even your boss. trouble!<\/p>\n

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.<\/p>\n

project logic is meant to plan the order of execution of activities. the order is declared in the planning process.<\/p>\n

we should not alter a project’s critical path just to highlight activities as “important”<\/strong>. use activity codes or udfs to define and track the “important” activities.<\/p>\n

if you want to go deeper on this matter, then read murray’s article<\/a>. in it, he suggests a paradigm shift in how we define the criticality of an activity and what project activities are most “critical”.<\/p>\n

2) i think\/suspect activity z should be on the project’s critical path.<\/h2>\n

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?<\/p>\n

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.<\/p>\n

always make a backup before you alter your project’s logic. but also think about the impacts of these kinds of changes.<\/p>\n

what are the impacts of adding an activity to the critical path?<\/h2>\n

change logic can alter the critical path downstream, so compare your project’s old critical path to the new one.<\/p>\n

document all changes in a notebook topic or somewhere similar.<\/p>\n

ask any of the forensic scheduling experts<\/a> on linkedin<\/a> 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.<\/p>\n

what do you think?<\/h2>\n

what are your thoughts or questions about critical path changes? drop us a comment below.<\/p>\n

\"new<\/a><\/span>