This paper was published in IJERA, August 2012. <h5>Introduction</h5>Resource conflicts are an extremely common occurrence within any multi-project environment. Even after completely eliminating all possible resource conflicts using 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 in such cases. CCPM 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 of 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 conflicting tasks are on feeding chains) and giving higher priority to the task with a higher ratio.  <h5>Prioritising tasks in a single project environment using CCPM </h5>In most of the literature on CCPM, e.g., Critical Chain (1997), Newbold (1998), Simpson and Lynch (1999), Homer (1998), and Leach (1999) have advocated dividing the various possible combinations of feeding buffer consumption percentage and chain completion percentage into three zones of Red, Yellow and Green. If the conflicting tasks occur on chains, which are in different colour zones, the task in the red chain gets higher priority over the task in the yellow chain, which in turn gets higher priority over the task in the green chain. If the two tasks occur on the chains, which are in the same colour zone, CCPM, at best, says that doing any 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, which are to be done by the same resource, CCPM recommends the following procedure.<ol style="list-style-type:decimal;"><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 of Red, Yellow and Green as shown in Figure 2.</li><li>All the tasks of the respective chains get the colour of the band where the point corresponding to the % Buffer Consumption and % Completion lies on the fever chart.</li><li>The task priority of the tasks to be followed is red, yellow and green in that order.</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) say 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. The estimation of how much work remains to be done is also subjected to inflation by safety margins – the very same problem CCPM attempted to solve by using buffers. Moreover, the estimate of ‘duration left’ is highly subjective and varies significantly for different people involved with the same project. This gives rise to a lot of scepticism and a lack of confidence in the task priorities derived by this algorithm among the members of the project team. <h5>Rule based on integration point position for single projects</h5>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, which integrate with the critical chain at two different points. In that case, the task on the feeding chain, which integrates earlier with the critical chain, gets higher priority over the task in the chain that integrates later with the critical chain. If the two conflicting tasks occur on two feeding chains, which integrate at the same point with the critical chain, then doing any task first is equally acceptable.<h5> </h5><h5>The simulation involving a single project</h5>In order to check the difference in the resulting project lead time by following the above two rules, the following assumptions are made.<ol style="list-style-type:decimal;"><li>There will be no other resource conflict in the project other than the one under consideration. This assumption is valid because the CCPM methodology demands the removal of almost all the resource conflicts during the project-planning phase.</li><li>The conflicting tasks occur on two different feeding chains integrating at two different points on the critical chain.</li></ol> With these two assumptions, a project network, whose results can be impacted by the two different decision-making rules, can be made 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 for simulating the lead times achieved by following the two different task priority rules. Task A and Task F are to be done by the same resource, and there is a conflict of priority. By checking the different possible durations of each of the tasks and chains in the project network, the impact of the two different decision-making rules, in all the possible situations, can be studied. In other words, this is the most generalised project network to study the impact of the decision-making rules under consideration. The following sets of conditions are studied.<ol style="list-style-type:decimal;"><li>When Task A and Task F are in the same colour band</li><li>When Task A is in Red and Task F is in Yellow or Green & when Task A is in Yellow and Task F is in Green</li></ol> For all the above cases, the buffer consumption-based priority rule can give opposite priority to the integration point position-based priority rule. Since the critical chain completion percentages for both the chains are 0%, it is assumed that 0%-10% buffer consumption is Green band, 10%-20% buffer consumption is Yellow band and 20% and higher is Red band (CCPM suggests to keep the colour bands biased towards red zone for smaller chain completion percentages). <h5>The range of task durations studied in the simulation</h5><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 647501 cases found where both Task A and Task F were in the same colour band, the following is the frequency distribution of the percentage difference in the lead time of the project based on the buffer priority rule and the integration point position-based priority rule was observed. In Figure 4, the upper limit of -10 and frequency four means that there were four cases found where the integration point position-based priority rule gave a longer lead time by 10%-12% of the buffer priority rule. Similarly, the upper limit of 26 and frequency 16 means that there were 16 cases found where the integration point position-based priority rule gave a shorter lead time by 24%-26%.<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 323486 cases found where Task A and Task F were in different colour bands and the two rules gave opposite results, the following is the frequency distribution of the percentage difference in the lead time of the project by following the buffer priority rule, and the integration point position-based priority rule was observed. It looks very clear from the above result that both the probability of achieving a lower lead time & magnitude of the reduction in lead time, are favourable in the case of following an integration point position-based priority rule rather 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><h5>Prioritising tasks in a multi-project environment using CCPM</h5>When the conflicting tasks occur on feeding chains of 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 shows that most of them do task prioritisation with the following methodology.<ol style="list-style-type:decimal;"><li>Colour the tasks on the critical chain of the project with dark red, dark yellow or dark green based on the zone in which the %Buffer Consumption and % 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 and light green based on the zone in which %Buffer Consumption and % Completion of individual feeding chains lie on the fever chart.</li><li>The tasks are then prioritised in the order of dark red, dark yellow, dark green, light red, light yellow, light green.</li></ol> Some software, while doing the above steps, keeps the position of the feeding buffers fixed throughout the project, irrespective of the status of the critical chain, while others keep the position of the feeding buffers floating along the timeline depending upon the updated status of the critical chain. Some software ignores the status of the feeding buffer entirely. If a feeding chain starts to intrude into the project buffer, it colours the feeding chains dark red, dark yellow or dark green depending on the incursion of the feeding chain into the project buffer, while others always look at the feeding buffer status to colour the feeding chains. All the above task prioritisation methods inevitably lead to situations when tasks of different projects get mixed up with each other. That means that one resource can have Project A as the highest priority task and Project B as a lower priority task, whereas another resource can have task of Project B as the highest priority task and task of Project A as a lower priority task. Also, a resource can have one task of Project A as highest priority task, then a task of Project B and then again another task of Project A. These situations are completely counterproductive to achieve synchronisation of different resources and inevitably lead to inflation of project lead times.<h5> </h5><h5>Rule based on project priority for multiple projects</h5>The task prioritisation rule that was found to give much better results than the above-mentioned CCPM rule is as follows - Priority of tasks of two or more projects should never be mixed up. That means that if one task of Project A has higher priority than another task of Project B, then all the tasks of Project A must have higher priority than all the tasks of Project B for all the resources.<h5> </h5><h5>The simulation with two projects</h5>In order to check the difference in the resulting project lead time by following the above two rules, the following assumptions are made. There will be no other resource conflict in the project other than the one under consideration. This assumption is valid because the CCPM methodology demands the removal of almost all the 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 for simulating the lead times achieved by following the two different task priority rules. Task A and Task J are to be done by the same resource, and there is a conflict of priority. Similarly, Task D and Task G are to be done by different resources, and there is a conflict of priority. By checking the other possible durations of each of the tasks and chains 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 will mix the tasks of the two projects (if other tasks are of light Yellow or light Green) or it will be neutral towards doing any task in preference to any other (if other tasks are also light Red). <h5>The range of task durations studied in the simulation</h5><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 1498 cases found where both Task A and Task J were in the red colour band, the following is the frequency distribution of the percentage difference in the lead time of the project based on the buffer priority rule and the integration point position-based priority rule was observed. In Figure 7, the upper limit of -4 and frequency nine means that there were nine cases found where the integration point position based priority rule gave a longer lead time by 4%-6% of the buffer priority rule. Similarly,  the upper limit of 22 and frequency three means that there were three cases found where the integration point position-based priority rule gave a shorter lead time by 20%-22%.<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><h5>Conclusion</h5>The integration point position-based priority rule and the rule of never mixing up tasks of different projects while prioritising give a better result than the buffer priority rule in a far greater number of cases. Also, the quantum of benefits is more for the rules compared to the buffer priority rule. Since project environments are known to be highly uncertain and variations in task lead times is quite common, a rule that are more likely (higher probability) to give a better result must be followed, even though in a certain particular case, some other rule seems to provide a better result. Since the new rules have a higher probability of giving a shorter lead time for a project, these rules should be preferred over the current buffer-based task prioritisation rule.<h5> </h5><h5>Managerial implications</h5>The new rules of task prioritisation, as proposed in this paper, especially the rule for task prioritisation within single projects based on the position of integration point, apart from the obvious effect of shortening the project lead time, will drastically improve the acceptability of the change within the project team and save invaluable time which would have otherwise been spent on resolving conflicts occurring due to a flawed rule and the subjectivities involved in its method of calculation. The second rule of task priorities in multiple projects, based on the project priority, simplifies the task priority calculations, makes them more intuitive and easy to follow for everyone involved.

Key Takeaways

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

Task prioritisation rules for project execution

This paper was published in IJERA, August 2012. <h5>Introduction</h5>Resource conflicts are an extremely common occurrence within any multi-project environment. Even after completely eliminating all possible resource conflicts using 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 in such cases. CCPM 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 of 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 conflicting tasks are on feeding chains) and giving higher priority to the task with a higher ratio.  <h5>Prioritising tasks in a single project environment using CCPM </h5>In most of the literature on CCPM, e.g., Critical Chain (1997), Newbold (1998), Simpson and Lynch (1999), Homer (1998), and Leach (1999) have advocated dividing the various possible combinations of feeding buffer consumption percentage and chain completion percentage into three zones of Red, Yellow and Green. If the conflicting tasks occur on chains, which are in different colour zones, the task in the red chain gets higher priority over the task in the yellow chain, which in turn gets higher priority over the task in the green chain. If the two tasks occur on the chains, which are in the same colour zone, CCPM, at best, says that doing any 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, which are to be done by the same resource, CCPM recommends the following procedure.<ol style="list-style-type:decimal;"><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 of Red, Yellow and Green as shown in Figure 2.</li><li>All the tasks of the respective chains get the colour of the band where the point corresponding to the % Buffer Consumption and % Completion lies on the fever chart.</li><li>The task priority of the tasks to be followed is red, yellow and green in that order.</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) say 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. The estimation of how much work remains to be done is also subjected to inflation by safety margins – the very same problem CCPM attempted to solve by using buffers. Moreover, the estimate of ‘duration left’ is highly subjective and varies significantly for different people involved with the same project. This gives rise to a lot of scepticism and a lack of confidence in the task priorities derived by this algorithm among the members of the project team. <h5>Rule based on integration point position for single projects</h5>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, which integrate with the critical chain at two different points. In that case, the task on the feeding chain, which integrates earlier with the critical chain, gets higher priority over the task in the chain that integrates later with the critical chain. If the two conflicting tasks occur on two feeding chains, which integrate at the same point with the critical chain, then doing any task first is equally acceptable.<h5> </h5><h5>The simulation involving a single project</h5>In order to check the difference in the resulting project lead time by following the above two rules, the following assumptions are made.<ol style="list-style-type:decimal;"><li>There will be no other resource conflict in the project other than the one under consideration. This assumption is valid because the CCPM methodology demands the removal of almost all the resource conflicts during the project-planning phase.</li><li>The conflicting tasks occur on two different feeding chains integrating at two different points on the critical chain.</li></ol> With these two assumptions, a project network, whose results can be impacted by the two different decision-making rules, can be made 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 for simulating the lead times achieved by following the two different task priority rules. Task A and Task F are to be done by the same resource, and there is a conflict of priority. By checking the different possible durations of each of the tasks and chains in the project network, the impact of the two different decision-making rules, in all the possible situations, can be studied. In other words, this is the most generalised project network to study the impact of the decision-making rules under consideration. The following sets of conditions are studied.<ol style="list-style-type:decimal;"><li>When Task A and Task F are in the same colour band</li><li>When Task A is in Red and Task F is in Yellow or Green & when Task A is in Yellow and Task F is in Green</li></ol> For all the above cases, the buffer consumption-based priority rule can give opposite priority to the integration point position-based priority rule. Since the critical chain completion percentages for both the chains are 0%, it is assumed that 0%-10% buffer consumption is Green band, 10%-20% buffer consumption is Yellow band and 20% and higher is Red band (CCPM suggests to keep the colour bands biased towards red zone for smaller chain completion percentages). <h5>The range of task durations studied in the simulation</h5><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 647501 cases found where both Task A and Task F were in the same colour band, the following is the frequency distribution of the percentage difference in the lead time of the project based on the buffer priority rule and the integration point position-based priority rule was observed. In Figure 4, the upper limit of -10 and frequency four means that there were four cases found where the integration point position-based priority rule gave a longer lead time by 10%-12% of the buffer priority rule. Similarly, the upper limit of 26 and frequency 16 means that there were 16 cases found where the integration point position-based priority rule gave a shorter lead time by 24%-26%.<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 323486 cases found where Task A and Task F were in different colour bands and the two rules gave opposite results, the following is the frequency distribution of the percentage difference in the lead time of the project by following the buffer priority rule, and the integration point position-based priority rule was observed. It looks very clear from the above result that both the probability of achieving a lower lead time & magnitude of the reduction in lead time, are favourable in the case of following an integration point position-based priority rule rather 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><h5>Prioritising tasks in a multi-project environment using CCPM</h5>When the conflicting tasks occur on feeding chains of 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 shows that most of them do task prioritisation with the following methodology.<ol style="list-style-type:decimal;"><li>Colour the tasks on the critical chain of the project with dark red, dark yellow or dark green based on the zone in which the %Buffer Consumption and % 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 and light green based on the zone in which %Buffer Consumption and % Completion of individual feeding chains lie on the fever chart.</li><li>The tasks are then prioritised in the order of dark red, dark yellow, dark green, light red, light yellow, light green.</li></ol> Some software, while doing the above steps, keeps the position of the feeding buffers fixed throughout the project, irrespective of the status of the critical chain, while others keep the position of the feeding buffers floating along the timeline depending upon the updated status of the critical chain. Some software ignores the status of the feeding buffer entirely. If a feeding chain starts to intrude into the project buffer, it colours the feeding chains dark red, dark yellow or dark green depending on the incursion of the feeding chain into the project buffer, while others always look at the feeding buffer status to colour the feeding chains. All the above task prioritisation methods inevitably lead to situations when tasks of different projects get mixed up with each other. That means that one resource can have Project A as the highest priority task and Project B as a lower priority task, whereas another resource can have task of Project B as the highest priority task and task of Project A as a lower priority task. Also, a resource can have one task of Project A as highest priority task, then a task of Project B and then again another task of Project A. These situations are completely counterproductive to achieve synchronisation of different resources and inevitably lead to inflation of project lead times.<h5> </h5><h5>Rule based on project priority for multiple projects</h5>The task prioritisation rule that was found to give much better results than the above-mentioned CCPM rule is as follows - Priority of tasks of two or more projects should never be mixed up. That means that if one task of Project A has higher priority than another task of Project B, then all the tasks of Project A must have higher priority than all the tasks of Project B for all the resources.<h5> </h5><h5>The simulation with two projects</h5>In order to check the difference in the resulting project lead time by following the above two rules, the following assumptions are made. There will be no other resource conflict in the project other than the one under consideration. This assumption is valid because the CCPM methodology demands the removal of almost all the 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 for simulating the lead times achieved by following the two different task priority rules. Task A and Task J are to be done by the same resource, and there is a conflict of priority. Similarly, Task D and Task G are to be done by different resources, and there is a conflict of priority. By checking the other possible durations of each of the tasks and chains 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 will mix the tasks of the two projects (if other tasks are of light Yellow or light Green) or it will be neutral towards doing any task in preference to any other (if other tasks are also light Red). <h5>The range of task durations studied in the simulation</h5><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 1498 cases found where both Task A and Task J were in the red colour band, the following is the frequency distribution of the percentage difference in the lead time of the project based on the buffer priority rule and the integration point position-based priority rule was observed. In Figure 7, the upper limit of -4 and frequency nine means that there were nine cases found where the integration point position based priority rule gave a longer lead time by 4%-6% of the buffer priority rule. Similarly,  the upper limit of 22 and frequency three means that there were three cases found where the integration point position-based priority rule gave a shorter lead time by 20%-22%.<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><h5>Conclusion</h5>The integration point position-based priority rule and the rule of never mixing up tasks of different projects while prioritising give a better result than the buffer priority rule in a far greater number of cases. Also, the quantum of benefits is more for the rules compared to the buffer priority rule. Since project environments are known to be highly uncertain and variations in task lead times is quite common, a rule that are more likely (higher probability) to give a better result must be followed, even though in a certain particular case, some other rule seems to provide a better result. Since the new rules have a higher probability of giving a shorter lead time for a project, these rules should be preferred over the current buffer-based task prioritisation rule.<h5> </h5><h5>Managerial implications</h5>The new rules of task prioritisation, as proposed in this paper, especially the rule for task prioritisation within single projects based on the position of integration point, apart from the obvious effect of shortening the project lead time, will drastically improve the acceptability of the change within the project team and save invaluable time which would have otherwise been spent on resolving conflicts occurring due to a flawed rule and the subjectivities involved in its method of calculation. The second rule of task priorities in multiple projects, based on the project priority, simplifies the task priority calculations, makes them more intuitive and easy to follow for everyone involved.

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

Download PDF

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

Let's Empower Growth