PM Milestone Project Management Templates

Chapter 1 asserts that any project worth doing is worth doing fast. The reason is that, for most projects, investment starts when the project starts, but return on investment does not start until the project is complete. Thus, the goal of a started project should be to finish ASAP. We will consider the constraint to this goal.

Most projects performed today use the CPM, which was developed in the early 1950s and is taught as the centerpiece of most project-management classes. (I know. I teach some at the University of Phoenix.) It is also described in all project-management texts. Figure 3.2 illustrates a typical critical-path schedule. The longest path through the network is the critical path.

Figure 3.2 also shows the resources assigned to perform each task. Assume the estimate of task duration requires the resource being fully dedicated to the task (an approach I recommend, for reasons that will become clear later on). Will this project complete on time? Not likely. The schedule plans for all of the resources to multitask (i.e., work on more than one task at a time). By so doing, they will extend the duration of each of the tasks they are working on and, thus, of the overall project. Since the project will be late if only one task on the critical path takes longer than planned, this project is planned to be late. This is true for almost all CPM-planned projects as nearly none of them have infinite resources.

Analyzing the project illustrated in Figure 3.2 allows us to estimate how long it might actually take. Consider the work performed by resource 1 (tasks 1, 3, and 5). Since all three tasks are planned to start at the same time, this means each task will take three times as long while the three are worked simultaneously. Thus, as the shortest task (task 1) is 5 days long, after 15 days, task 1 will be complete, and tasks 3 and 5 will have five days of work performed on them. Then, resource 1 must split time between the two remaining tasks, meaning each task progresses at the rate of one day process per two days of elasped time. Therefore, the remaining 20 days of work on task 2 will take 40 days, and the total actual duration for task 3 will be 55 days. After 55 days, task 5 still has 15 days of work on it, so its total duration will be 70 days.

Figuring out how long resource 2 will take on each task gets more complicated because of the task dependencies. Resource 2 can start on task 2 with 100% effort on day 15 and will not be able to start on task 4 until resource 1 completes task 3 (i.e., until day 55). Thus, resource 2 can work 40 days focused on task 2, but must split time for the final 5 days of work with task 4, causing the duration of task 2 to increase to 50 days. Task 4 is now overlapping with task 2 and task 6, extending its duration to 40 days. Figure 3.3 illustrates the expected actual performance of the project, extending the date by over a month. The project was planned to fail.

ID |
Task Name |
Duration |
Predecessors |
Resource Names | ||||||

Apr '04 |
May '04 |
Jun '04 |
Jul '04 |
Aug '04 | ||||||

4 11 18 25 |
2 9 16 23 |
30 6 13 20 27 4 11 18 25 |
1 8 15 | |||||||

1 |
Taskl |
5 days |
1 |
2 |
t 8/2 | |||||

2 |
Task 2 |
45 days |
1 |
2 |
r â– | |||||

3 |
Task 3 |
25 days |
1 | |||||||

4 |
Task 4 |
30 days |
3 |
2 |
1 | |||||

5 |
Task 5 |
60 days |
1 |
h1 | ||||||

t | ||||||||||

6 |
Task 6 |
5 days |
2 | |||||||

7 |
Project End |
0 days |
2, 4, 6 |

ID |
Task Name |
Duration |
Predecessors |
Resource Names | ||||||||||||||||||||||||||||||||||||||||

1 |
Taskl |
15 days |
1 | |||||||||||||||||||||||||||||||||||||||||

2 |
Task 2 |
50 days |
1 |
2 | ||||||||||||||||||||||||||||||||||||||||

3 |
Task 3 |
55 days |
1 | |||||||||||||||||||||||||||||||||||||||||

4 |
Task 4 |
40 days |
3 |
2 | ||||||||||||||||||||||||||||||||||||||||

5 |
Task 5 |
70 days |
1 | |||||||||||||||||||||||||||||||||||||||||

6 |
Task 6 |
10 days |
5 |
2 | ||||||||||||||||||||||||||||||||||||||||

7 |
Project End |
0 days |
2, 4, 6 |
May'04 Jun '04 Jul'04 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 5 12 19 26 9/13 18 25 Figure 3.3 Actual task performance. A method exists to solve this problem: resource leveling. Most CPM software includes the ability to resource level. Figure 3.4 illustrates the resource-leveled version of Figure 3.1. Note that the date of the resource-leveled schedule conforms to the date of the actual schedule. It also resolves the first UDE: projects frequently overrun schedule. Of course they do: they are planned to! Examination of Figure 3.2 and 3.4 leads to an interesting observation. The software identified the critical path as only comprising tasks 5 and 6. This is curious as there is no critical path for the upper path of the project. Just why it chose this is a mystery to me, and I know that the identified critical path after resource leveling will be different with different software, even if it does the leveling the same way. The reason is that the critical path is not defined after resource leveling. Before resource leveling, the critical path has no extra time in it (float or slack). Notice on Figure 3.2 that the two noncritical paths, the path through tasks 1 and 2, and the path through tasks 3 and 4, each have extra time, shown by the line with no task bar. After resource leveling (Figure 3.4), all of the paths have float (or slack). Thus, none is the critical path. I do an informal survey in the classes I teach for the PMI. I ask how many students resource-load (i.e., identify the resources needed, as in Figure 3.2) their project
Apr'04 May'04 Jun'04 Jul'04 Aug'04 Sep'04 Oct 4 11 18 25 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 5 12 19 26 Figure 3.4 Resource-leveled critical-path schedule. plans. Usually one half to two thirds do so. I then ask how many resource-level their plans. Usually, it is about 5%. Thus, about 95% of projects are planned to fail in the first place. Keep in mind this is a group made up of the elite in project management: most are certified PMPs. I ask those that resource-load but do not resource-level why they work this way. Most do not have an answer, but those who do say one of two things: 2. The leveling leads to sequences that do not make sense. The first point indicates a reluctance to deal with reality. I will deal with the second point later. For now, we are going to follow Dr. Eliyahu Goldratt and suggest a simple definition change: the constraint to a single project is the critical chain, defined as the longest path through the network after resource leveling. Figure 3.5 illustrates the critical chain for our simple example project. Note that it has no float or slack when defined. Note also that it jumps the project logic paths (although it retains the technical logic paths in the project plan.) In the past, I never questioned the proposition that an acceptable way to remove resource contention is first to identify the critical path and then level resources. My literature search did not reveal the basis for this proposition. I suspect, but have no proof, that this may be a result of technological evolution. It is possible to calculate a project manually to find the critical path. There is no simple algorithm to create an optimum, resource-leveled critical path. Thus, it is very difficult to resource-level even a modestly complex project plan manually. The relatively expensive and slow computers that existed at the time of the growth of CPM and PERT did not lend themselves to doing a lot of calculation. The idea that you could use the computer to calculate the critical path, lay out the network, and then deal with the potential resource constraint seems logical enough. It may even have been that for the projects using CPM and PERT, resources were less often a constraint. They could find the critical path and then determine and satisfy the resource demand. Current project-management software operates by starting with the activity structure (critical path) and only then considers the limited resources available for the project. Project-management software identifies the critical path by linking the project activities in a logical way, then measuring the longest time through the network of activities, assuming no resource constraints. The project manager inputs resource availability. The software then allocates the resources through various schemes, but usually first to the critical path (i.e., by least float or slack) and then to the paths that are nearest to the critical path in time duration (minimum-slack activities first). People who have studied resource allocation know that this does not always give the optimum schedule. People have proposed various heuristics, and some programs provide a large number of selections. The only way to find the optimum among these options is trial and error. Most software gives you some degree of control over the process. Thus, Goldratt's first key insight is to identify the constraint of a single project as the critical chain, instead of the critical path. The critical chain includes both task and resource constraint. |

Was this article helpful?

What you need to know aboutâ€¦ Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

## Post a comment