Unit III

Critical Path Method

The critical path method (CPM) is a step-by-step project management technique for process planning that
defines critical and non-critical tasks with the goal of preventing time-frame problems and
process bottlenecks. The CPM is ideally suited to projects consisting of numerous activities that interact
in a complex manner.

CPM is commonly used with all forms of projects, including construction, aerospace and defense,
software development, research projects, product development, engineering, and plant maintenance,
among others. Any project with interdependent activities can apply this method of mathematical analysis.
The first time CPM was used for major skyscraper development was in 1966 while constructing the
former World Trade Center Twin Towers in NYC. Although the original CPM program and approach is
no longer used, the term is generally applied to any approach used to analyze a project network logic
diagram.

The essential technique for using CPM: is to construct a model of the project that includes the following:

A list of all activities required to complete the project (typically categorized within a work breakdown
structure),

The time (duration) that each activity will take to complete,

The dependencies between the activities and,

Logical end points such as milestones or deliverable items.

Using these values, CPM calculates the longest path of planned activities to logical end points or to the
end of the project, and the earliest and latest that each activity can start and finish without making the
project longer. This process determines which activities are "critical" (i.e., on the longest path) and which
have "total float" (i.e., can be delayed without making the project longer). In project management, a
critical path is the sequence of project network activities which add up to the longest overall duration,
regardless if that longest duration has float or not. This determines the shortest time possible to complete
the project. There can be 'total float' (unused time) within the critical path. For example, if a project is
testing a solar panel and task 'B' requires 'sunrise', there could be a scheduling constraint on the testing
activity so that it would not start until the scheduled time for sunrise. This might insert dead time (total
float) into the schedule on the activities on that path prior to the sunrise due to needing to wait for this
event. This path, with the constraint-generated total float would actually make the path longer, with total
float being part of the shortest possible duration for the overall project. In other words, individual tasks on
the critical path prior to the constraint might be able to be delayed without elongating the critical path;
this is the 'total float' of that task. However, the time added to the project duration by the constraint is
actually critical path drag, the amount by which the project's duration is extended by each critical path
activity and constraint.

A project can have several, parallel, near critical paths; and some or all of the tasks could have 'free float'
and/or 'total float'. An additional parallel path through the network with the total durations shorter than
the critical path is called a sub-critical or non-critical path. Activities on sub-critical paths have no drag,
as they are not extending the project's duration.
CPM analysis tools allow a user to select a logical end point in a project and quickly identify its longest
series of dependent activities (its longest path). These tools can display the critical path (and near critical
path activities if desired) as a cascading waterfall that flows from the project's start (or current status date)
to the selected logical end point.

In this diagram, Activities A, B, C, D, and E comprise the critical or longest path, while Activities F, G,
and H are off the critical path with floats of 15 days, 5 days, and 20 days respectively. Whereas activities
that are off the critical path have float and are therefore not delaying completion of the project, those on
the critical path will usually have critical path drag, i.e., they delay project completion. The drag of a
critical path activity can be computed using the following formula:

If a critical path activity has nothing in parallel, its drag is equal to its duration. Thus A and E have drags
of 10 days and 20 days respectively.

If a critical path activity has another activity in parallel, its drag is equal to whichever is less: its duration
or the total float of the parallel activity with the least total float. Thus since B and C are both parallel to F
(float of 15) and H (float of 20), B has a duration of 20 and drag of 15 (equal to F's float), while C has a
duration of only 5 days and thus drag of only 5. Activity D, with a duration of 10 days, is parallel to G
(float of 5) and H (float of 20) and therefore its drag is equal to 5, the float of G.

These results, including the drag computations, allow managers to prioritize activities for the effective
management of project completion, and to shorten the planned critical path of a project by pruning critical
path activities, by "fast tracking" (i.e., performing more activities in parallel), and/or by "crashing the
critical path" (i.e., shortening the durations of critical path activities by adding resources).

Program Evaluation and Review Technique

PERT is a method of analyzing the tasks involved in completing a given project, especially the time
needed to complete each task, and to identify the minimum time needed to complete the total project. It
incorporates uncertainty by making it possible to schedule a project while not knowing precisely the
details and durations of all the activities. It is more of an event-oriented technique rather than start- and
completion-oriented, and is used more in projects where time is the major factor rather than cost. It is
applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development
projects.

Program Evaluation Review Technique (PERT) offers a management tool, which relies "on arrow and
node diagrams of activities and events: arrows represent the activities or work necessary to reach
the events or nodes that indicate each completed phase of the total project." 

PERT and CPM are complementary tools, because "CPM employs one time estimate and one cost
estimate for each activity; PERT may utilize three time estimates (optimistic, expected, and pessimistic)
and no costs for each activity. Although these are distinct differences, the term PERT is applied
increasingly to all critical path scheduling.

Events and activities

In PERT diagram the event is the main building block, and it known predecessor events and successor
events:

PERT event: a point that marks the start or completion of one or more activities. It consumes no time and
uses no resources. When it marks the completion of one or more activities, it is not "reached" (does not
occur) until all of the activities leading to that event have been completed.

predecessor event: an event that immediately precedes some other event without any other events
intervening. An event can have multiple predecessor events and can be the predecessor of multiple events.

successor event: an event that immediately follows some other event without any other intervening
events. An event can have multiple successor events and can be the successor of multiple events.

Beside events PERT also knows activities and sub-activities:

PERT activity: the actual performance of a task which consumes time and requires resources (such as
labor, materials, space, machinery). It can be understood as representing the time, effort, and resources
required to move from one event to another. A PERT activity cannot be performed until the predecessor
event has occurred.

PERT sub-activity: a PERT activity can be further decomposed into a set of sub-activities. For example,
activity A1 can be decomposed into A1.1, A1.2 and A1.3. Sub-activities have all the properties of
activities; in particular, a sub-activity has predecessor or successor events just like an activity. A sub-
activity can be decomposed again into finer-grained sub-activities.

Time
PERT has defined four types of time required to accomplish an activity:

optimistic time: the minimum possible time required to accomplish an activity (o) or a path (O), assuming
everything proceeds better than is normally expected

pessimistic time: the maximum possible time required to accomplish an activity (p) or a path (P),
assuming everything goes wrong (but excluding major catastrophes).

most likely time: the best estimate of the time required to accomplish an activity (m) or a path (M),
assuming everything proceeds as normal.

expected time: the best estimate of the time required to accomplish an activity (te) or a path (TE),
accounting for the fact that things don't always proceed as normal (the implication being that the expected
time is the average time the task would require if the task were repeated on a number of occasions over an
extended period of time).

te = (o + 4m + p) ÷ 6

standard deviation of time : the variability of the time for accomplishing an activity (σ te) or a path (σTE)

σte = √ [(p - o) ÷ 6]

PERT supplies a number of tools for management with determination of concepts, such as:

float or slack is a measure of the excess time and resources available to complete a task. It is the amount
of time that a project task can be delayed without causing a delay in any subsequent tasks (free float) or
the whole project (total float). Positive slack would indicate ahead of schedule; negative slack would
indicate behind schedule; and zero slack would indicate on schedule.

critical path: the longest possible continuous pathway taken from the initial event to the terminal event. It
determines the total calendar time required for the project; and, therefore, any time delays along the
critical path will delay the reaching of the terminal event by at least the same amount.

critical activity: An activity that has total float equal to zero. An activity with zero float is not necessarily
on the critical path since its path may not be the longest.

Lead time: the time by which a predecessor event must be completed in order to allow sufficient time for
the activities that must elapse before a specific PERT event reaches completion.

lag time: the earliest time by which a successor event can follow a specific PERT event.

fast tracking: performing more critical activities in parallel

crashing critical path: Shortening duration of critical activities

Activity Predecessor a m b µ σ2
 te

A - 6 7 8 7 0.11

B - 1 2 9 3 1.78

C - 1 4 7 4 1.00

D A 1 2 3 2 0.11

E A,B 1 2 9 3 1.78

F C 1 5 9 5 1.78

G C 2 2 8 3 1.00

H E,F 4 4 4 4 0

I E,F 4 4 10 5 1.00

J D,H 2 5 14 6 4.00

K G,I 2 2 8 3 1.00

Advantages

PERT chart explicitly defines and makes visible dependencies (precedence relationships) between the
work breakdown structure (commonly WBS) elements.

PERT facilitates identification of the critical path and makes this visible.

PERT facilitates identification of early start, late start, and slack for each activity.

PERT provides for potentially reduced project duration due to better understanding of dependencies
leading to improved overlapping of activities and tasks where feasible.

The large amount of project data can be organized and presented in diagram for use in decision making.

PERT can provide a probability of completing before a given time.

Disadvantages

There can be potentially hundreds or thousands of activities and individual dependency relationships.

PERT is not easily scalable for smaller projects.

The network charts tend to be large and unwieldy requiring several pages to print and requiring specially
sized paper.

The lack of a timeframe on most PERT/CPM charts makes it harder to show status although colours can
help (e.g., specific colour for completed nodes).

Crashing the Project

The project manager is frequently confronted with having to reduce the scheduled completion time of a
project to meet a deadline. In other words, the manager must finish the project sooner than indicated by
the CPM/PERT network analysis. Project duration can often be reduced by assigning more labor to
project activities, in the form of overtime, and by assigning more resources (material, equipment, and so
on). However, additional labor and resources increase the project cost. Thus, the decision to reduce the
project duration must be based on an analysis of the trade-off between time and cost. Project crashing is a
method for shortening the project duration by reducing the time of one (or more) of the critical project
activities to less than its normal activity time. This reduction in the normal activity time is referred to
as crashing. Crashing is achieved by devoting more resources, usually measured in terms of dollars, to the
activities to be crashed.

We will assume that the times (in weeks) shown on the network activities are the normal activity times.
For example, 12 weeks are normally required to complete activity 1-2. Further, we will assume that the
cost required to complete this activity in the time indicated is $3,000. This cost is referred to as
the normal activity cost. Next, we will assume that the building contractor has estimated that activity 1-2
can be completed in 7 weeks, but it will cost $5,000 instead of $3,000 to complete the activity. This new
estimated activity time is known as the crash time, and the cost to achieve the crash time is referred to as
the crash cost.

Activity 1-2 can be crashed a total of 5 weeks (normal time - crash time = 12-7 = 5 weeks) at a total crash
cost of $2,000 (crash cost - normal cost = $5,000-3,000 = $2,000). Dividing the total crash cost by the

total allowable crash time yields the crash cost per week:

If we assume that the relationship between crash cost and crash time is linear, then activity 1-2 can be
crashed by any amount of time (not exceeding the maximum allowable crash time) at a rate of $400 per
week. For example, if the contractor decided to crash activity 1-2 by only 2 weeks (reducing activity time
to 10 weeks), the crash cost would be $800 ($400 per week ¥ 2 weeks).

The objective of project crashing is to reduce project duration while minimizing the cost of crashing.
Since the project completion time can be shortened only by crashing activities on the critical path, it may
turn out that not all activities have to be crashed. However, as activities are crashed, the critical path may
change, requiring crashing of previously noncritical activities to reduce the project completion time even
further.

The normal times and costs, the crash times and costs, the total allowable crash times, and the crash cost
per week for each activity in the network in Figure 17.12 are summarized in the following table:
We start by looking at the critical path and seeing which activity has the minimum crash cost per week.
Observing the preceding table and the following figure, we see activity 1-2 has the minimum crash cost of
$400 (excluding the dummy activity 3-4, which cannot be reduced). Activity 1-2 will be reduced as much
as possible. The table shows that the maximum allowable reduction for activity 1-2 is 5 weeks, but we
can reduce activity 1-2 only to the point where another path becomes critical. When two paths
simultaneously become critical, activities on both must be reduced by the same amount. If we reduce the
activity time beyond the point where another path becomes critical, we may be incurring an unnecessary
cost. This last stipulation means that we must keep up with all the network paths as we reduce individual
activities, a condition that makes manual crashing very cumbersome. For that reason we will rely on the
computer for project crashing; however, for the moment we pursue this example in order to demonstrate
the logic of project crashing.

It turns out that activity 1-2 can be crashed by the total amount of 5 weeks without another path becoming
critical, since activity 1-2 is included in all four paths in the network. Crashing this activity results in a
revised project duration of 31 weeks at a crashing cost of $2,000. The revised network is shown in the
following figure
Since we have not reached our crashing goal of 30 weeks, we must continue and the process is repeated.
The critical path in the preceding figure remains the same, and the minimum activity crash cost on the
critical path is $500 for activity 2-3. Activity 2-3 can be crashed a total of 3 weeks, but since the
contractor desires to crash the network only to 30 weeks, we need to crash activity 2-3 by only 1 week.
Crashing activity 2-3 by 1 week does not result in any other path becoming critical, so we can safely
make this reduction. Crashing activity 2-3 to 7 weeks (i.e., a 1-week reduction) costs $500 and reduces
the project duration to 30 weeks.

The total cost of crashing the project to 30 weeks is $2,500. The contractor could inform the customer
that an additional cost of only $2,500 would be incurred to finish the house in 30 weeks.

Suppose we wanted to continue to crash this network, reducing the project duration down to the minimum
time possible; that is, crashing the network the maximum amount possible. We can determine how much
the network can be crashed by crashing each activity the maximum amount possible and then determining
the critical path of this completely crashed network. For example, activity 1-2 is 7 weeks, activity 2-3 is 5
weeks, 2-4 is 3 weeks, and so on. The critical path of this totally crashed network is 1-2-3-4-6-7 with a
project duration of 24 weeks. This is the least amount of time the project can be completed in. If we
crashed all the activities by their maximum amount, the total crashing cost is $35,700, computed by
subtracting the total normal cost of $75,000 from the total crash cost of $110,700 in the preceding table.
However, if we followed the crashing procedure outlined in this example, the network can be crashed to
24 weeks at a cost of $31,500, a savings of $4,000.

Gantt Chart
A chart in which a series of horizontal lines shows the amount of work done or production completed in
certain periods of time in relation to the amount planned for those periods.

 Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a  project.
Terminal elements and summary elements comprise the work breakdown structure of the project. Modern
Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts
can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line as
shown here.
 Time estimates
Activit Expected
Predecessor Opt. Normal Pess.
y time
(O) (M) (P)
a — 2 4 6 4.00
b — 3 5 9 5.33
c A 4 5 7 5.17
d A 4 6 10 6.33
e b, c 4 5 7 5.17
f D 3 4 8 4.50
g E 3 5 8 5.17

Applications: Baseline in Gantt chart is used for clear comparison picture of what and how was planned and
the current state of a project. Thus a manager or anyone who manages a project is able to see whether a
schedule deviates from the initial plan. A project will be successfully accomplished when everything goes
according to a baseline.
A baseline gives a manager possibility to understand and track project progress and forecast project results.
Generally baselines are a combination of project scope, cost and schedule (time) that are called triple
constraints of a project.
Thanks to baselines a project manager knows what exactly goes wrong and how much it takes. They help to
realize problematic points and minimize them.
Gantt charts can be used for scheduling generic resources as well as project management. They can also be
used for scheduling production processes and employee rostering. In the latter context, they may also be
known as timebar schedules. Gantt charts can be used to track shifts or tasks and also vacations or other types
of out-of-office time. Specialized employee scheduling software may output schedules as a Gantt chart, or they
may be created through popular desktop publishing software.

Managing Risk
In business, risk management is defined as theprocess of identifying, monitoring and managing
potential risks in order to minimize the negative impact they may have on an organization.

Risk Management Process

Risk response matrix

Risk response is the process of developing strategic options, and determining actions, to
enhance opportunities and reduce threats to the project’s objectives. A project team member is
assigned to take responsibility for each risk response. This process ensures that each risk
requiring a response has an owner monitoring the responses, although the owner may delegate
implementation of a response to someone else.

Risk severity matrix

Risk response matrix

Risk response strategies
ForThreats
Avoid.Riskcanbeavoidedbyremovingthecause
oftheriskor executingtheprojectina different
waywhilestillaimingto achieveproject objectives.
Notallriskscanbeavoidedor
eliminated,andforothers,thisapproachmaybe
tooexpensiveortime‐consuming.However,this
shouldbethefirststrategyconsidered.
Transfer.Transferringriskinvolvesfinding
anotherpartywhoiswillingtotakeresponsibility
foritsmanagement,andwhowillbeartheliability
oftheriskshoulditoccur.Theaimistoensure
thattheriskisownedandmanagedbytheparty
bestabletodealwithit effectively.Risktransfer
usuallyinvolvespaymentofapremium,andthe
cost‐effectivenessofthismustbeconsideredwhen
decidingwhethertoadoptatransferstrategy.
Mitigate.Riskmitigationreducestheprobability
and/orimpactofanadverseriskeventtoan
acceptablethreshold.Takingearlyactionto
reducetheprobabilityand/orimpactofariskis
oftenmoreeffectivethantryingtorepairthe
damageaftertheriskhasoccurred.Riskmitigation
mayrequireresourcesor timeandthuspresentsa
tradeoffbetweendoingnothingversusthecostof
mitigatingtherisk.
ForOpportunities
Exploit.Theaimistoensurethattheopportunity
isrealized.Thisstrategyseekstoeliminatethe
uncertaintyassociatedwithaparticularupside
riskbymakingtheopportunitydefinitelyhappen.
Exploitisanaggressiveresponsestrategy,best
reservedforthose“goldenopportunities”having
highprobabilityandimpacts.
Share.Allocateriskownershipofanopportunity
toanotherpartywhoisbestabletomaximizeits
probabilityofoccurrenceandincreasethe
potentialbenefitsifitdoesoccur.Transferring
threatsandsharingopportunitiesaresimilarin
thatathirdpartyisused.Thosetowhomthreats
aretransferredtakeontheliabilityandthoseto
whomopportunitiesareallocatedshouldbe
allowedtoshareinthepotentialbenefits.
Enhance.Thisresponseaimstomodifythe“size”
ofthepositiverisk.Theopportunityis enhanced
byincreasingitsprobabilityand/orimpact,
therebymaximizingbenefitsrealizedforthe
project.If theprobabilitycanbeincreasedto100
percent,thisiseffectivelyanexploitresponse.
 Acceptance.Thisstrategyisadoptedwhenitisnotpossibleor practicaltorespondtotheriskbythe
otherstrategies,oraresponseisnotwarrantedbytheimportanceoftherisk.Whentheproject
managerandtheprojectteamdecidetoacceptarisk,theyareagreeingtoaddresstheriskifandwhenit
occurs.Acontingencyplan,workaroundplanand/orcontingencyreservemaybedevelopedforthat eventuality.

What is Critical Chain?

Critical Chain Project Management (CCPM) is a methodology for planning, executing and managing
projects in single and multi-project environments.

Critical Chain Project Management was developed by Dr Eli Goldratt and was first introduced to the
market in his Theory of Constraints book “Critical Chain” in 1997. It was developed in response to many
projects being dogged by poor performance manifested in longer than expected durations, frequently
missed deadlines, increased costs in excess of budget, and substantially less deliverables than originally
promised.

The Critical Chain Method has its roots in another one of Dr. Goldratt’s inventions, namely, The Theory
of Constraints (TOC). This Project Management Method comes into force after the initial Project
Schedule is prepared, which includes establishment of the task dependencies. The evolved Critical path is
reworked based on the Critical Chain Method. To do so, the methodology assumes constraints related to
each task.

In CCPM the critical chain is the set of activities that defines the overall duration of the project,
taking into account precedence and also resource dependencies. Critical chain requires the
construction of a feasible schedule with only the time to do the work in each activity. This
estimate is usually described as corresponding to a 50% confidence level or an average
duration. Resource conflicts are resolved by moving tasks earlier in time.

The Critical Path Project Management Methodology is very effective in organizations which do not have
evolved Project Management Practices.

However, the methodology does not advocate multi-tasking, and in Projects with complex Schedule
Networks, the results of implementing the Critical path Methodology have proven to be deterrent to the
overall Project Schedule. In addition, there is no standard method for calculating and optimizing the
Project Buffers. The Critical Path Project Management Methodology has had a fair amount of success in
manufacturing domains though it has not achieved any noteworthy success in the IT Sector.

A few of these constraints are listed out below:

There is a certain amount of uncertainty in each task.

Task durations are often overestimated by the Team Members or Task Owners. This is typically done to
add a safety margin to the task so as to be certain of its completion in the decided duration.
In most cases, the tasks should not take the time estimated, which includes the safety margin, and should
be completed earlier.

If the Safety Margin assumed is not needed, it is actually wasted. If the task is finished sooner,it may not
necessarily mean that the successor task can start earlier as the resources required for the successor task
may not be available until their scheduled time. Hence, the saved time cannot be passed on to finish the
Project early. On the other hand, if there are delays over and above the estimated schedules, these delays
will most definitely get passed on, and, in most cases, will exponentially increase the Project Schedule.

Problems with traditional project management

When planning for an upcoming project, estimates for task durations are required. In order for the plan to
be treated as realistic, much time is spent ensuring estimates are accurate. Accurate estimates give us
increased probability and high-confidence in the task completing on time. This allows additional safety
time beyond the work content time required to be embedded within the task duration. The more safety in
a task the more there is a tendency to behave in the following ways:

Not starting the task until the last moment  (Student Syndrome)

Delaying (or pacing) completion of the task  (Parkinson’s Law)

Cherry picking tasks

As a result, the safety which was included at the planning stage is wasted and, if “Murphy” strikes and
problems do occur, tasks over-run.

In addition Management force (for intuitive but invalid reasons) people to work on more than one task at
once – creating multitasking. This drives people to switch between tasks leading them to elongate time
estimates in planning and further waste the embedded task safety in execution.

Resources working on tasks also naturally resist reporting any early finishes. If an early finish is reported,
the estimate for the task is recognised as too long. When a similar task on a different project is estimated,
the initial response will be to again use a worst case duration. This will inevitably be challenged as the
similar task was finished early last time. Increased pressure will be placed on the resource to accept a
shorter estimate this time. The risk is that this, shorter estimate will not offer sufficient safety to the
project should a problem occur. Hence resources ensure that sufficient safety is always embedded in each
task estimate and the entire safety is used in execution of the task. This game is played by management
and resources!

In summary, delays to tasks are passed on to the entire project however; benefits from tasks finishing
early are rarely passed on to the same project.

The traditional tools used to manage projects; Critical Path Method (CPM), Program Evaluation and
Review Technique (PERT), Gantt, Prince Etc. do not address the misuse of embedded safety and
consequently the behaviours they drive.

Critical Chain Project Management

Critical Chain Project Management addresses these issues in the following ways.
Planning

Critical Chain - the Critical Chain is defined as the longest chain [not path] of dependent tasks. In this
case, ‘dependent’ refers to resources and resource contention across tasks/projects as well as the sequence
and logical dependencies of the tasks themselves. This differs from the Critical Path Method.

Estimations – To reduce the behaviours and time wasting associated with having too much embedded
safety, Critical Chain Project Management recommends that task estimates are cut to half the length of a
“normal” duration.

Safety – Critical Chain Project Management uses safety ‘Buffers’ to manage the impact of variation and
uncertainty around projects. The safety at a task level is aggregated and moved to strategic points in the
project flow.  There are three types of buffer/strategic points necessary to ensure the project has sufficient
safety:

Project Buffer – A project buffer is inserted at the end of the project network between the last task and
the completion date. Any delays on the longest chain of dependant tasks will consume some of the buffer
but will leave the completion date unchanged and so protect the project. The project buffer is typically
recommended to be half the size of the safety time taken out, resulting in a project that is planned to be
75% of a “traditional” project network.

Feeding Buffers – delays on paths of tasks feeding into the longest chain can impact the project by
delaying a subsequent task on the Critical Chain. To protect against this, feeding buffers are inserted
between the last task on a feeding path and the Critical Chain. The feeding buffer is typically
recommended to be half the size of the safety time taken out of the feeding path.

Resource Buffers – Resource buffers can be set alongside of the Critical Chain to ensure that the
appropriate people and skills are available to work on the Critical Chain tasks as soon as needed.

Execution
Priorities - All resources on a project are given clear and aligned priorities relating to the ‘health’ of the
Critical Chain relative to its associated buffer and hence the project as a whole. A resource with more
than one task open should normally be assigned to complete any task jeopardising any projects Critical
Chain before completing any feeding path task.

Completion – resources on a task are encouraged to follow the ‘roadrunner’ approach. When there is
work available it should be progressed at the fastest possible speed (without compromising quality) until
completed. Tasks are not left partially complete to remove the temptation to multitask.  As task duration
estimates have reduced safety they drive resources to meet the more “aggressive” durations and limit the
behaviours of Student Syndrome and Parkinson’s Law.

As the Progress of the Project is reported, the Critical Chain is recalculated. In fact, monitoring and
controlling of the Project primarily focuses on utilization of the Buffers. Hence the Critical Chain
Method considers the basic Critical Path based Project Network and Schedule to derive a completely new
Schedule.

Resource loading and resource leveling:

A project manager has several choices on how to meet demands of his/her many projects. Two simple
choices are resource loading and resource leveling. But, what do these two terms mean? Learn what
resource loading and resource leveling are and the differences between the two.

Resource loading mainly involves your manpower or employees. In resource loading, each employee is
assigned a task or a percentage of a project (X percent of the whole). Usually, it's 25 percent of the whole.
Then the employee is assigned other tasks until he or she reaches 100 percent booked. This would then
mean that the employees cannot take on any additional work.

With resource loading, a project manager can predict an employee's hours for the year and see how tasks
can be assigned. This also allows the project manager to decide whether or not additional employees or
contractors are needed to complete the scheduled projects.

The downside to resource loading is that employees cannot be 100 percent booked. Other things may
arise to take away their time, such as unexpected problems that need to be fixed. An employee should
always be under 100 percent booked. Resource loading increases the chance that a project will not be
completed on time because employees are overloaded with projects.

While resource loading mainly deals with manpower, resource leveling deals with both time (project
starting and ending date) and resources, including manpower and budget. Resource leveling tries to
balance the conflicting interests of projects with the available resources.

Resource leveling generally breaks things down into two categories: time and available resources. Some
projects need to be finished within a certain time frame. These projects will use all the available resources
(money and manpower) to complete the project by a certain date.

Resource Levelling:
 Projects that aren't as pressing can be spread out for an indefinite period of time until resources do
become available. These projects are usually ones that are not on the critical path and will not affect the
project completion date.

Like resource loading, resource leveling also has its problems. It is hard to determine in the beginning
which tasks will be on the critical path. Also, delaying a task could cause the entire project to fall behind
schedule.

When performing project planning activities, the manager will attempt to schedule certain

tasks simultaneously. When more resources such as machines or people are needed than are available, or
perhaps a specific person is needed in both tasks, the tasks will have to be rescheduled concurrently or
even sequentially to manage the constraint. Project planning resource leveling is the process of resolving
these conflicts. It can also be used to balance the workload of primary resources over the course of the
project[s], usually at the expense of one of the traditional triple constraints (time, cost, scope).

When using specially designed project software, leveling typically means resolving conflicts or over
allocations in the project plan by allowing the software to calculate delays and update tasks automatically.
Project management software leveling requires delaying tasks until resources are available. In more
complex environments, resources could be allocated across multiple, concurrent projects thus requiring
the process of resource leveling to be performed at company level.

In either definition, leveling could result in a later project finish date if the tasks affected are in the critical
path.

Resource leveling is also useful in the world of maintenance management. Many organizations have
maintenance backlogs. These backlogs consist of work orders. In a "planned state" these work orders
have estimates such as 2 electricians for 8 hours. These work orders have other attributes such as report
date, priority, asset operational requirements, and safety concerns. These same organizations have a need
to create weekly schedules. Resource-leveling can take the "work demand" and balance it against the
resource pool availability for the given week. The goal is to create this weekly schedule in advance of
performing the work. Without resource-leveling the organization (planner, scheduler, supervisor) is most
likely performing subjective selection. For the most part, when it comes to maintenance scheduling, there
is less, if any, task interdependence, and therefore less need to calculate critical path and total float.