This paper was published in IJERA, August 2012. <h2>Introduction</h2>Resource conflicts are an extremely common occurrence in any multi-project environment. Even after completely eliminating all possible resource conflicts through resource levelling during the project-planning phase, reasonable common-cause variation (uncertainty, or statistical fluctuations) can result in resource conflicts from time to time during the execution phase. Project managers normally lack any objective decision-making criteria in such situations and generally rely on their experience or other subjective criteria to make decisions. CCPM (Critical Chain Project Management) provides an objective decision-making rule in such situations. Fundamentally, it advocates that a task on the critical chain always takes priority over all other tasks in the project. For two or more tasks occurring on feeding chains, it advocates looking at the ratio of feeding-buffer consumption percentage to chain-completion percentage of the contesting feeding chains (assuming the conflicting tasks are on feeding chains) and giving higher priority to the task with the higher ratio.  <h2>Prioritising tasks in a single project environment using CCPM</h2>Most of the literature on CCPM - for example, Critical Chain (1997), Newbold (1998), Simpson and Lynch (1999), Homer (1998), and Leach (1999) - advocates dividing the various possible combinations of feeding-buffer consumption percentage and chain-completion percentage into three zones: Red, Yellow and Green. If the conflicting tasks occur on chains that are in different colour zones, the tasks on the Red chain gets higher priority than the task on the Yellow chain, which, in turn, gets higher priority than the task on the Green chain. If the two tasks occur on chains that are in the same colour zone, CCPM, at best, says that performing either task first is equally acceptable.<figure class="image"><img style="aspect-ratio:8334/5548;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritization-figure-01_1754370236.png" width="8334" height="5548"></figure>For example, if a project network, as shown in Figure 1, has Task A and Task F that are to be performed by the same resource, CCPM recommends the following procedure.<ol><li>Calculate the expected remaining duration of each of the chains on which the two tasks lie.</li><li>Calculate the buffer duration available for each chain based on the remaining duration calculated in Step 1.  </li><li>Compute the ratio: % Buffer Consumption = (Planned buffer duration – Buffer duration available)/Planned buffer duration.  </li><li>Also, compute the ratio: % Completion = (Planned chain duration – Remaining chain duration)/Planned chain duration.  </li><li>Plot the value of the two ratios on the fever chart shown below.  </li><li>Divide the fever chart into three zones - Red, Yellow, and Green - as shown in Figure 2.</li><li>All the tasks of the respective chains are assigned the colour of the band in which the point corresponding to the % Buffer Consumption and % Completion lies on the fever chart.</li><li>The task-priority order is Red, Yellow, and Green.</li></ol><figure class="image"><img style="aspect-ratio:8334/6623;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritization-figure-02_1754370334.png" width="8334" height="6623"></figure>There are several critiques of the above methodology. Tzvi Raz, Dov Dvir and Robert Barnes (2003) state that buffer penetration is defined as the amount of time running from the original start date of the buffer on the critical chain or one of the feeding chains, as appropriate, to the projected end date of the last task on the corresponding chain. The projected dates are based on estimates of the ‘duration left’ for the tasks. Estimating how much work remains to be done is also subject to inflation by safety margins – the very same problem CCPM attempted to solve by using buffers. Moreover, the estimate of the ‘duration left’ is highly subjective and varies significantly among different people involved in the same project. This gives rise to considerable scepticism and a lack of confidence in the task priorities derived by this algorithm among members of the project team. <h2>Rule based on integration point position for single projects</h2>The rule that was found to give much better results than the above-mentioned CCPM task-prioritisation rule is as follows. Suppose the two conflicting tasks occur on two feeding chains that integrate with the critical chain at two different points. In that case, the task on the feeding chain that integrates earlier with the critical chain gets higher priority than the task on the chain that integrates later with the critical chain. If the two conflicting tasks occur on two feeding chains that integrate with the critical chain at the same point, then performing either task first is equally acceptable.<h5> </h5><h2>The simulation involving a single project</h2>To compare the resulting project lead times achieved by following the above two rules, the following assumptions are made.  <ol><li>There will be no other resource conflict in the project apart from the one under consideration. This assumption is valid because the CCPM methodology requires the removal of almost all resource conflicts during the project-planning phase.</li><li>The conflicting tasks occur on two different feeding chains that integrate with the critical chain at two different points.</li></ol> With these two assumptions, a project network whose results can be impacted by the two different decision-making rules can be constructed as follows:<figure class="image"><img style="aspect-ratio:8334/5546;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritization-figure-03_1754370453.png" width="8334" height="5546"></figure>Figure 3 illustrates the project network used to simulate the lead times achieved by following the two different task-priority rules. Task A and Task F are to be performed by the same resource, resulting in a priority conflict. By examining the different possible durations of each task and chain in the project network, the impact of the two decision-making rules under all possible situations can be studied. In other words, this is the most generalised project network for studying the impact of the decision-making rules under consideration. The following sets of conditions are studied.  <ol><li>When Task A and Task F are in the same colour band.</li><li>When Task A is in the Red band and Task F is in the Yellow or Green band, and when Task A is in the Yellow band and Task F is in the Green band.</li></ol>For all the above cases, the buffer-consumption-based priority rule can assign the opposite priority to the integration-point-position-based priority rule. Since the critical-chain completion percentage for both chains is 0%, it is assumed that 0%-10% buffer consumption corresponds to the Green band, 10%-20% to the Yellow band, and 20% or higher to the Red band (CCPM suggests keeping the colour bands biased towards the Red zone for lower chain-completion percentages). <h2>The range of task durations studied in the simulation</h2><figure class="image"><img style="aspect-ratio:8334/3712;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritizationbox-02_1754629163.png" width="8334" height="3712"></figure>For the 6,47,501 cases in which both Task A and Task F were in the same colour band, the following frequency distribution of the percentage difference in project lead time between the buffer-priority rule and the integration-point-position-based priority rule was observed. In Figure 4, the upper limit of -10 with a frequency of 4 means that four cases were found in which the integration-point-position-based priority rule resulted in a project lead time that was 10%-12% longer than that obtained using the buffer-priority rule. Similarly, the upper limit of 26 with a frequency of 16 means that 16 cases were found in which the integration-point-position-based priority rule resulted in a project lead time that was 24%-26% shorter than that obtained using the buffer-priority rule.<figure class="image"><img style="aspect-ratio:8334/9833;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritisation-figure-04_1754629218.png" width="8334" height="9833"></figure>For the 3,23,486 cases in which Task A and Task F were in different colour bands and the two rules gave opposite results, the following frequency distribution of the percentage difference in project lead time between the buffer-priority rule and the integration-point-position-based priority rule was observed. It is evident from the above results that both the probability of achieving a lower lead time and the magnitude of the reduction in lead time are more favourable when following the integration-point-position-based priority rule than the rule currently advocated by CCPM.<figure class="image"><img style="aspect-ratio:8334/9848;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritisation-figure-05_1754629229.png" width="8334" height="9848"></figure><h2>Prioritising tasks in a multi-project environment using CCPM</h2>When conflicting tasks occur on feeding chains belonging to two different projects, the available literature on Critical Chain Project Management is not very explicit about the rule to be followed. The author’s experience with many CCPM software packages shows that most of them prioritise tasks using the following methodology.<ol><li>Colour the tasks on the critical chain of the project dark Red, dark Yellow, or dark Green, based on the zone in which the percentage Buffer Consumption and percentage Completion of the critical chain lie on the fever chart.  </li><li>Colour the tasks on the feeding chains of the project with light Red, light Yellow, or light Green, based on the zone in which the percentage Buffer Consumption and % Completion of the individual feeding chains lie on the fever chart.  </li><li>Prioritise the task in the following order: dark Red, dark Yellow, dark Green, light Red, light Yellow, and light Green.</li></ol>Some software packages, while doing the above steps, keep the position of the feeding buffers fixed throughout the project, irrespective of the status of the critical chain, whereas others allow the feeding buffers to float along the timeline based on the updated status of the critical chain. Some software packages ignore the status of the feeding buffer entirely. If a feeding chain starts to intrude into the project buffer, they colour the feeding chains dark Red, dark Yellow, or dark Green, depending on the extent intrusion into the project buffer, while others always use the feeding-buffer status to colour the feeding chains. All the above task-prioritisation methods inevitably lead to situations in which tasks from different projects get mixed up with each other. That means that one resource can have a task from Project A as its highest-priority task and a task from Project B as a lower-priority task, whereas another resource may have a task from Project B as its highest-priority task and a task from Project A as a lower-priority task. Similarly, a resource may have one task from Project A as its highest-priority task, followed by a task from Project B and then another task from Project A. These situations are completely counterproductive to achieving synchronisation across different resources and inevitably lead to inflation of project lead times.<h5> </h5><h2>Rule based on project priority for multiple projects</h2>The task-prioritisation rule that was found to give much better results than the above-mentioned CCPM rule is as follows: the priorities of tasks belonging to two or more projects should never be mixed up. This means that if one task from Project A has a higher priority than another task from Project B, then all the tasks in Project A must have higher priority than all the tasks in Project B across all resources.<h5> </h5><h2>The simulation with two projects</h2>In order to check the difference in the resulting project lead time by following the two rules above, the following assumption is made. There will be no other resource conflict in the projects apart from the one under consideration. This assumption is valid because the CCPM methodology requires the removal of almost all resource conflicts during the project-planning phase.<figure class="image"><img style="aspect-ratio:8334/9841;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritization-figure-06_1754371564.png" width="8334" height="9841"></figure>Figure 6 illustrates the two project networks used to simulate the lead times achieved by following the two different task-priority rules. Task A and Task J are to be performed by the same resource, resulting in a priority conflict. Similarly, Task D and Task G are to be performed by another resource, resulting in a second priority conflict. By examining the other possible durations of each task and chain in the project network, the impact of the two different decision-making rules can be studied. The conditions when Task A and Task J are both in the light Red colour band are studied. In this situation, either the buffer-colour-priority system mixes the tasks of the two projects (if the other tasks are in the light Yellow or light Green bands) or it remains neutral regarding which task should be performed first(if the other tasks are also in the light Red band). <h2>The range of task durations studied in the simulation</h2><figure class="image"><img style="aspect-ratio:8334/5122;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritizationbox-03_1754629546.png" width="8334" height="5122"></figure>For the 1,498 cases found in which both Task A and Task J were in the Red colour band, the following frequency distribution of the percentage difference in project lead time between the buffer-priority rule and the integration-point-position-based priority rule was observed. In Figure 7, the upper limit of -4 with a  frequency of 9 means that nine cases were found in which the integration-point-position-based priority rule resulted in a project lead time that was 4%-6% longer than that obtained using the buffer priority rule. Similarly, the upper limit of 22 with a frequency of 3 means that three cases were found in which the integration-point-position-based priority rule resulted in a project lead time that was 20%-22% shorter than that obtained using the buffer priority rule.<figure class="image"><img style="aspect-ratio:8334/8006;" src="https://web-assets.vectorconsulting.in/storage/editor_uploads//task-prioritisation-figure-07_1754629606.png" width="8334" height="8006"></figure><h2>Conclusion</h2>The integration-point-position-based priority rule and the rule of never mixing tasks from different projects during prioritisation produce better results than the buffer-priority rule in a far greater number of cases. Also, the quantum of benefits achieved using these rules is greater than that achieved using the buffer priority rule. Since project environments are known to be highly uncertain and variations in task lead times are common, a rule that is more likely (i.e., has a higher probability) to produce better results should be followed, even if, in a particular case, another rule seems to offer a better result. Since the new rules have a higher probability of delivering shorter lead times, they should be preferred over the current buffer-based task-prioritisation rule.<h5> </h5><h2>Managerial implications</h2>The new task-prioritisation rules proposed in this paper, especially the rule for prioritising tasks within a single project based on the position of the integration point will, apart from the obvious benefit of shortening project lead times, significantly improve the acceptance of the approach within the project team. They will also save invaluable time that would otherwise be spent resolving conflicts arising from a flawed prioritisation rule and the subjectivity involved in its calculation. The second rule, which prioritises task across multiple projects based on project priority, simplifies task-priority calculations and makes them more intuitive and easier for everyone involved to understand and follow.

Key Takeaways

Discover a groundbreaking task prioritisation method that challenges traditional CCPM. What if a simple rule could significantly shorten project timelines while eliminating confusion in multi-project environments?

Task prioritisation rules for project execution

<h5> Task prioritisation rules for project execution</h5>

Download PDF

<h5> Task prioritisation rules for project execution</h5>

Discover an objective task prioritisation rule for Critical Chain Project Management (CCPM) that outperforms traditional buffer rules, reducing project lead times.