Best Project Scheduling Techniques.

management
MEDIA
HEALTH
law
DESIGN
EDUCATION
MUSIC
agriculture
LANGUAGE
M E C H A N I C S
psychology
BIOTECHNOLOGY
GEOGRAPHY
ART
PHYSICS
history
E
C
O
L
O
G
Y
CHEMISTRY
mathematics
ENGINEERING
Project Scheduling Techniques

Subject: PROJECT SCHEDULING TECHNIQUES Credits: 4
SYLLABUS
Resource Scheduling
Introduction, Project Stages, Project Constraints, Resource Constraints, Resource Aggregation, Resource
Leveling, Time-Constrained Network, Computerized Resource Scheduling.
Resource Allocation Method
Introduction, Methods, Resource Allocation Methods, Securing Project Rescheduling.
Splitting and Multitasking
Multi-Tasking, Multi-tasking and project performance, Is Multi-tasking really so prevalent? Purpose of
Multitasking, Stop Multitasking, Exposure of Multi tasking.
Multi Project Resources Scheduling
Introduction, Multiple Projects, Methods, Resource allocation syndrome.
Critical Chain Scheduling
Introduction, Critical Chain Schedules, Resource Behaviors and Risk Mitigation, Project Control with Buffer
Management, Buffer Management and Risk Mitigation, Project development role.
Critical Chain Scheduling Methods
Introduction, Concept, Planning with CCM, Introduce Buffers, Monitoring the project, Estimating and
Scheduling, Multi-project Environment.
Application of Critical chain scheduling
Introduction, Problems and Challenges, Challenges, Benefits, Projects, The critical chain - special case.
Suggested Readings:
Construction Project Scheduling and Control, Saleh Mubarak, John Wiley and Sons
Project Scheduling: a research handbook, Erik L. Demeulemeester and Willy S. Herroelen, Kluwer Academic
Publishers

CHAPTER 1
Resource Scheduling
Learning Objectives
Describe the types of project constraints.
Understand the nature of resource constraints.
Explain the steps and issues involved in scheduling resources in a project
environment.
Explain the benefits of resource scheduling.
1.1 Introduction
Can you envision starting a long car trip to an unfamiliar destination without a map or
navigation system? You're pretty sure you have to make some turns here and there, but you
have no idea when or where, or how long it will take to get there. You may arrive eventually,
but you run the risk of getting lost, and feeling frustrated, along the way. Essentially, driving
without any idea of how you're going to get there is the same as working on a project without
a schedule. No matter the size or scope of your project, the schedule is a key part of project
management. The schedule tells you when each activity should be done, what has already
been completed, and the sequence in which things need to be finished.
Luckily, drivers have fairly accurate tools they can use. Scheduling, on the other hand, is not
an exact process. It's part estimation, part prediction, and part 'educated guessing.' Because of
the uncertainty involved, the schedule is reviewed regularly, and it is often revised while the
project is in progress. It continues to develop as the project moves forward, changes arise,
risks come and go, and new risks are identified. The schedule essentially transforms the
project from a vision to a time-based plan.
1.1.1 Schedules also help you do the following:
They provide a basis for you to monitor and control project activities.
They help you determine how best to allocate resources so you can achieve the project
goal.
They help you assess how time delays will impact the project.
You can figure out where excess resources are available to allocate to other projects.

They provide a basis to help you track project progress.
With that in mind, what's the best way of building an accurate and effective schedule
for your next project?
Project managers have a variety of tools to develop a project schedule – from the
relatively simple process of action planning for small projects, to use of Gantt Charts
and Network Analysis for large projects. Here, we outline the key tools you will need
for schedule development.
1.1.2 Schedule Inputs
You need several types of inputs to create a project schedule:
Personal and project calendars – Understanding working days, shifts, and resource
availability is critical to completing a project schedule.
Description of project scope – From this, you can determine key start and end dates,
major assumptions behind the plan, and key constraints and restrictions. You can also
include stakeholder expectations, which will often determine project milestones.
Project risks – You need to understand these to make sure there's enough extra time to
deal with identified risks – and with unidentified risks (risks are identified with
thorough Risk Analysis).
Lists of activities and resource requirements – Again, it's important to determine if
there are other constraints to consider when developing the schedule. Understanding
the resource capabilities and experience you have available – as well as company
holidays and staff vacations – will affect the schedule.
A project manager should be aware of deadlines and resource availability issues that
may make the schedule less flexible.
1.1.3 Scheduling Tools
Here are some tools and techniques for combining these inputs to develop the schedule:
Schedule Network Analysis – This is a graphic representation of the project's
activities, the time it takes to complete them, and the sequence in which they must be
done. Project management software is typically used to create these analyses – Gantt
charts and PERT Charts are common formats.

Critical Path Analysis – This is the process of looking at all of the activities that must
be completed, and calculating the 'best line' – or critical path – to take so that you'll
complete the project in the minimum amount of time. The method calculates the
earliest and latest possible start and finish times for project activities, and it estimates
the dependencies among them to create a schedule of critical activities and dates.
Learn more about Critical Path Analysis.
Schedule Compression – This tool helps shorten the total duration of a project by
decreasing the time allotted for certain activities. It's done so that you can meet time
constraints, and still keep the original scope of the project. You can use two methods
here:
Crashing – This is where you assign more resources to an activity, thus decreasing the
time it takes to complete it. This is based on the assumption that the time you save
will offset the added resource costs.
Fast-Tracking – This involves rearranging activities to allow more parallel work. This
means that things you would normally do one after another are now done at the same
time. However, do bear in mind that this approach increases the risk that you'll miss
things, or fail to address changes.
1.2 Project Stages:
One of the biggest reasons that projects over-run is that the 'final' polishing and error-
correction takes very much longer than anticipated. In this way, projects can seem to be '80%
complete' for 80% of the time! What's worse, these projects can seem to be on schedule until,
all of a sudden, they over-run radically.
A good way of avoiding this is to schedule projects in distinct stages, where final quality,
finished components are delivered at the end of each stage. This way, quality problems can
be identified early on, and rectified before they seriously threaten the project schedule.
1.2.1 Project Review
Once you have outlined the basic schedule, you need to review it to make sure that the timing
for each activity is aligned with the necessary resources. Here are tools commonly used to do
this:

'What if' scenario analysis – This method compares and measures the effects of
different scenarios on a project. You use simulations to determine the effects of
various adverse, or harmful, assumptions – such as resources not being available on
time, or delays in other areas of the project. You can then measure and plan for the
risks posed in these scenarios.
Resource leveling – Here, you rearrange the sequence of activities to address the
possibility of unavailable resources, and to make sure that excessive demand is not
put on resources at any point in time. If resources are available only in limited
quantities, then you change the timing of activities so that the most critical activities
have enough resources.
Critical chain method – This also addresses resource availability. You plan activities
using their latest possible start and finish dates. This adds extra time between
activities, which you can then use to manage work disruptions.
Risk multipliers – Risk is inevitable, so you need to prepare for its impact. Adding
extra time to high-risk activities is one strategy. Another is to add a time multiplier to
certain tasks or certain resources to offset overly optimistic time estimation.
After the initial schedule has been reviewed, and adjustments made, it's a good idea to have
other members of the team review it as well. Include people who will be doing the work –
their insights and assumptions are likely to be particularly accurate and relevant.
1.2.2 Key Points
Scheduling aims to predict the future, and it has to consider many uncertainties and
assumptions. As a result, many people believe it's more of an art than a science. But whether
you're planning a team retreat, or leading a multimillion-dollar IT project, the schedule is a
critical part of your efforts. It identifies and organizes project tasks into a sequence of events
that create the project management plan. A variety of inputs and tools are used in the
scheduling process, all of which are designed to help you understand your resources, your
constraints, and your risks. The end result is a plan that links events in the best way to
complete the project efficiently.
1.3 Project Constraints
The primary impact of project constraints is the likelihood of delaying the completion of the
project. There are three types of project constraints: technological, resource and physical. The

technological constraints relate to the sequence in which individual project activities must be
completed. For example, in constructing a house, pouring the foundation must occur before
building the frame. Resource constraints relate to the lack of adequate resources which may
force parallel activities to be performed in sequence. The consequence of such a change in
network relationships is delay in the completion date of the project. Physical constraints are
caused by contractual or environmental conditions. For example, due to space limitations an
activity such as painting a wall may have to be performed by only one person.
In general, from a scheduling perspective, projects can be classified as either time constrained
or resource constrained. A project is classified as time constrained in situations where the
critical path is delayed and the addition of resources can bring the project back on schedule
and the project completed by the required date. However, the additional resource usage
should be no more than what is absolutely necessary. The primary focus, for purposes of
scheduling, in time constrained projects is resource utilization. On the other hand, a project is
resource constrained if the level of resource availability cannot be exceeded. In those
situations where resources are inadequate, project delay is acceptable, but the delay should be
minimal. The focus of scheduling in these situations is to prioritize and allocate resources in
such a manner that there is minimal project delay. However, it is also important to ensure that
the resource limit is not exceeded and the technical relationships in the project network are
not altered.
1.4 Resource Constraints
1.4.1 Definition
The first step in resource modeling is to decide exactly what resources are considered
important enough to be modeled. While most resource modeling is concerned with people or
workers (such as welders or computer programmers), it may also include other resources such
as machines (such as a computer of a particular specification), or space on a project where
space is restricted and where this restriction limits the amount of other resources which can
be deployed at any one time. Often resources are specified in terms of the number of units of
resource required, e.g., 5 welders or 3 computer programmers. Alternatively, resources may
be specified in terms of the hours or days that a specific resource is required, e.g., 40 welder
hours or 24 computer programmer days. Resources may be considered as consumable, such
as materials that may be used once and once only, or non-consumable, such as people, which
may be used again and again. The way in which consumable resources are used is not critical

as long as they are used efficiently. However, the way in which non-consumable resources
are used can have a significant impact on the project. For example, there is a significant
difference between requiring 16 units of a non-consumable resource for one week, thus
requiring 16 units to be made available at that time, and requiring 1 non-consumable unit for
16 weeks, thus only requiring 1 unit which can be reused 16 times.
Resource modeling is therefore mainly concerned with non-consumable resources with an
important caveat. It should never be assumed that the quantity of resources deployed and the
task duration are inversely related. Thus one should never automatically assume that the work
that can be done by one man in 16 weeks can actually be done by 16 men in one week.
Furthermore, there are many situations in which tasks may have to be carried out in a serial
fashion, while in other situations; only one or two persons can be usefully employed due to a
limited number of workers. Understanding the nature of the job and the size of the work team
needed to do the job is an essential aspect of resource modeling. Resource definition may also
include the creation of resource profiles which show how many units of each resource are
available for use in the project at any given time. In multi-project situations, this is not an
easy matter, as resources may be required to work on several projects simultaneously and
there determination of the resources required for one project must also consider the use of the
same resources for other projects.
1.4.2 Constraints
The most important resources that project managers have to plan and manage on day-to-day
basis are people, machines, materials, and working capital. Obviously, if these resources are
available in abundance then the project could be accelerated to achieve shorter project
duration. On the other hand, if these resources are severely limited, then the result more likely
will be a delay in the project completion time. Depending on the type of resources, the costs
of providing an abundance of such resources to accelerate project completion time can be
very high. However, if resources are readily available and excess premiums are not incurred
to use them on the project, then project cost should be low, as some project costs are resource
related while others are likely to be time dependent. In general, projects with a shorter
duration are less expensive. The longer the duration of the project, the higher will be overall
project cost due to the increase in fixed costs such as overheads. The reality is that as long as
the work on a project is ongoing it will continue to draw resources into its orbit. Whatever the
parameters of the project, it is unlikely that the relationship between cost and duration is
linear. For any particular project, the decision to place the project on the curve between the

point of least duration with its associated higher resource requirements and a point of
increased duration with its associated lower resource requirements depends on the particular
parameters of the project.
When a project plan is first devised it is likely that the plan will identify peaks of resource
requirements. However, given the finite nature of resource availability, it may be impractical
to meet such peak resource needs. Ideally, there should be an even demand for resources over
the entire project duration, with a smooth increase at the beginning of a project and a smooth
decrease at the end. Given the limited nature of resources, thoughtful consideration should be
given to the project resource requirements; the project plan should be refined when necessary
so that it is practical. The process of refining the plan to effectively manage and schedule
resources (sometimes referred to as resource modeling) comprises four major stages: resource
definition, resource allocation, resource aggregation, and resource leveling (which includes
resource smoothing).
1.4.3 Allocation
Resource allocation, also called resource loading, is concerned with assigning the required
number of those resources identified in the previous step to each activity identified in the
plan. More than one type of resource may be attributed to a specific activity. For example,
fixing the plates on a ship's hull may require 10 fitters, 20 welders, 15 laborers and a certain
type of welding machine. From a practical standpoint, resource allocation does not have to
follow a constant pattern; some activities may initially require fewer resources but may
require more of the same resources during the later stages of the project. At this stage, the
impact of any resource allocation decision is not known and we cannot yet answer questions
such as:
Is lack of resources on this particular activity having an adverse effect on the duration
of the whole project? Such an activity is more likely to be on the critical path.
By excessive use of resources are we completing this activity more quickly than
necessary in terms of the overall project duration? Such an activity is not likely to be
on the critical path.
1.5 Resource Aggregation
Resource aggregation, or resource loading, is simply the summation, on a period-by-period
basis, of the resources required to complete all activities based on the resource allocation

carried out in the previous stage. The results are usually shown graphically as a histogram.
Such aggregation may be done on an hourly, daily, or weekly basis, depending on the time
unit used to allocate resources. When a bar chart is used as the planning tool, the resource
aggregation is fairly simple and straightforward. For a given bar chart, there is a unique
resource unit aggregation chart which can be drawn underneath the bar chart. However, a
separate graph will be required for each resource unit. An example is shown in Figure 1.1
below, where, for a particular resource, the required resource units for each time period are
annotated on the bar chart. The total number of resource units for each time period can then
be summed and a resource aggregation or load chart can be produced.
Figure 1.1 Resource Unit Aggregation Chart
However, when a network is used for planning, the resource aggregation procedure is not so
simple or straightforward. As the network is not drawn to a time-scale, there is not a direct
link between the network and the demand for resources. Therefore, a schedule must be
prepared which tabulates activities in terms of time. However, this highlights another
difficulty, namely that those activities which are not on the critical path do not have fixed
starting and finishing times but are constrained by the earliest and latest starting and finishing
times. However, this seeming difficulty offers the planner considerable scope for adjusting
the demand for resources. This will be discussed, but the limits, within which resources can
be adjusted, without extending the overall project duration, are the resource requirements
between the earliest starting times and the latest starting times. This is illustrated in Figure
1.2, which shows the differing resource requirements that arise when both earliest and latest
start times are considered and also highlights the resource requirements for those activities
which are on the critical path.

Figure 1.2 Resource Unit Aggregation Chart Showing Resource Requirements
1.6 Resource Leveling
Having established the resource requirements through resource allocation and aggregation,
we will now examine the next phase of the planning and resource management process--
resource leveling. We will now compare those requirements with resource availability by
developing resource profiles. Disregarding factors such as economic considerations, if
sufficient resources are available so that supply always exceeds demand then, we should have
no problem. However, the most likely scenario is that, at some point, demand will exceed
supply. Such a scenario is illustrated in Figure 1.3.
Figure 1.3 Resource Demand Compared to Resource Availability

Resource leveling is the process that ensures resource demand does not exceed resource
availability. The ideal scenario would be a build up of resource usage at the beginning of the
project and a reduction at the end of the project. However, the approach to resource leveling
will also depend on whether resources are dedicated to a particular project or shared across
several projects and whether there is a need to keep all resources fully utilized.
We will begin by analyzing the issues involved in resource leveling for a situation where a
bar chart has been used as the primary planning technique for a simple project. The reason for
this is that resource leveling must be considered within a time framework and bar charts are
drawn to a time scale while networks are not. Examine Figure 1.1, where the time-scale for
the activities comprising the project are shown in a bar chart, which also shows resource
requirements for one particular resource unit. An examination of the bar chart and its
associated resource chart in Figure 1.1 shows that improvements can be made to the level of
resource requirements by:
Delaying or bringing forward the start of certain activities
Extending the duration of certain activities and so reducing the demand for resources
over the duration of the activity or by a combination of both of these adjustments
However, there are problems with using the simple bar chart as a tool for resource leveling.
For example, we do not have any information about the interdependency of tasks. Therefore,
if we delay a task by starting later than originally planned or by extending the duration of the
task, we cannot evaluate the exact impact this will have on the overall project. Referring to
Figure 8.1 again, if we assume that the maximum amount of resource availability is 14 units,
then we have a problem in week 2 because 18 units of resources are required in that week. In
order to reduce the resource demand in week 2, we may have to extend Activity A into week
3 and spread the resource demand over three weeks, or delay the commencement of Activity
B. However, the exact impact of these changes on the overall project duration cannot be
easily determined.
Another issue is that the critical path(s) cannot be easily determined, although we may be
able to deduce which activities are critical by inspection. Clearly, if we do not wish to extend
the overall duration of the project we must avoid extending or delaying activities which are
on the critical path. Finally, the availability of slack or float is not clear. Knowing this is
important because it is this attribute that can be utilized to adjust our resource requirements.

Resource leveling can be accomplished more easily if resource requirements to complete an
activity are expressed in terms of hours or days required. The definition of resource
requirements using such units of measure can help us determine if an activity should be
completed in a short time through the use of many resources or over a longer period of time
through the use of fewer resources. In practice, however, there is a limit to the number of
resources that can be deployed and, therefore, a limit to the amount by which any activity
duration can be shortened.
We will now examine situations where networks are used as the primary planning method.
Generally, there are two approaches to leveling and smoothing the resources required:
Time-limited resource considerations
In this case emphasis will be placed on completing the project within a specified time.
This time will usually have been determined by network analysis. Adjustments in the
timing of any activity, and the resources required at a given time, must be undertaken
within the float (slack) available. Obviously there can be no adjustment of activities
which are on the critical path.
Resource-limited resource considerations
In this case the project must be completed with the resources available even if this
means extending the project duration. If the total resource demand exceeds the
resource availability at any time then some of the activities must be delayed until
there is sufficient resource availability.
1.6.1 Resource Smoothing
Resource smoothing is part of the resource leveling process. In itself, resource smoothing is
the process that, not withstanding any constraints imposed during the leveling process,
attempts to determine a resource requirement that is "smooth" and where peaks and troughs
are eliminated. For example, even if 7 units of a given resource are available at any one time,
utilizing 5 of these units each week is preferable to 4 one week, 7 the next, 2 the next and so
on. Even if there is no limit to the amount of any one resource available, it is still desirable
that resource usage is as smooth as possible. Given that the resource requirements of those
activities on the critical path are fixed, some order or priority needs to be established for
selecting which activity and which particular resource associated with this activity should be
given priority in the smoothing process. In determining which activity should be given
priority, a subjective judgment should be made about the type of resource (or resources)

associated with each activity; priority should be given to the activities whose resources are
considered to be most important. Beyond this consideration, activities should be ranked in
order of total work content and total float or slack available for that activity. A useful device
for prioritizing is to consider the ratio of total work content/total float remaining and give
priority to activities with the highest value of this ratio.
Solving the resource scheduling problem for optimal solutions is extremely complex,
particularly for large project networks with many different resource types. However, several
heuristics are available to solve such problems. These heuristics allocate resources to
activities to minimize project delay based on certain priority rules. The two most commonly
used heuristics are the serial and the parallel methods. In the serial method of resource
allocation, activities are sorted into a list and resources are allocated to each of these activities
one at a time until resources are allocated to all activities. In the parallel method, however,
resources are allocated on a period by period basis rather than each activity. In this method
only those activities whose preceding activities have been completed will be considered. If
two or more activities compete for the same resources, then allocation of resources is based
on certain prescribed priority rules. Compared to the serial method, the parallel method has
been the most widely used heuristic. The following priority rules, in the order presented, have
been found to be the most effective in minimizing project delay.
Minimum slack
Smallest duration
Lowest activity identification number
Regardless of the scheduling heuristic used, the primary impact of resource constrained
scheduling is the loss of flexibility due to the reduction in slack. Furthermore, the reduction
in slack also increases the number of critical or near-critical activities.
1.7 Time-Constrained Network
This example has several parts.

Figure 1.4 Time-Constrained Network Example
First, compute the early, late, and slack times for the activities in the network in Figure 1.4,
assuming a time-constrained network. Which activities are critical? What is the time
constrained project duration?
Figure 1.5 Time-Constrained Network Example Showing Early, Late, and Slack Times
Now, assume you are a computer using software that schedules projects by the parallel
method and the following heuristics. Schedule only one period at a time!
Minimum slack
Smallest duration
Lowest activity identification number

Figure 1.6 Scheduled Resource Load Chart with ES and Slack Updates
We see that the parallel method schedules resources to various activities through leveling
and smoothing. This is accomplished in the above problem by delaying and reducing the
slack on activities 3, 5 and 6. Using the load profiles presented above, graphical resource
aggregation charts, similar to the ones presented earlier in this lesson, can be developed.
Next, keep a log of each activity change and the update you make each period--e.g., period 0-
1, 1-2, 2-3, etc. The log should include any changes or updates in ES and slack times each
period, activities scheduled and activities delayed. The log is shown in Table 1.1 below.
Table 1.1 Log of the Parallel Method of Scheduling
PERIOD ACTIVITY CHANGES
0-1
2 Schedule activity 2 first by the minimum slack rule
1 Schedule activity 1
3 Delay activity 3 ES to period 1. Reduce slack to 0.
5 Delay activity 5 ES to period 6. Reduce slack to 0.
1-2
3 Delay activity 3 ES to period 2. Reduce slack to -1.

2-3
3-4 3 Schedule activity 3
5-6 --- No changes
6-7 --- No changes
7-8 --- No changes
9-10 --- No changes
10-11 --- No changes
11-12 --- No changes
We see that the parallel method schedules resources to various activities through leveling
and smoothing. The log presented above shows how this was accomplished in the above
problem by delaying and reducing the slack on activities 3, 5, and 6.
Now, list the order in which you scheduled the activities of the project. Which activities of
the schedule are now critical? The order is (2, 1, 3, 4, 5, 6) and the critical activities are 2, 3,
5, and 6 as these are the activities with the least or negative slack. Finally, recompute the
slack for each activity given the new schedule. What is the slack for activity 1? 4? 5? For this,
see the answer to the second question. The slack for 1 = (0), 4 = (2), and 5 = (0).
1.8 Computerized Resource Scheduling
The resource scheduling examples that we solved above used the manual approach. For large
networks, however, this is not a feasible approach. Fortunately, all the better quality
computer packages for project management, besides network analysis, also feature the ability
to schedule activities taking into account resource constraints. Thus for most people engaged
in project management today, a computerized approach is preferred. While a full description

of the way in which current packages perform resource scheduling is beyond the scope of this
topic, these packages commonly use the serial scheduling and parallel scheduling algorithms.
The basic features of both these algorithms were described earlier in this lesson, even though
the computer packages use more sophisticated versions of these algorithms. Given the nature
of the resource constraints, each method may produce a feasible schedule; however, the
schedules need not necessarily be the same. Furthermore, if the same problem is solved by
two different project management packages, different schedules may be generated.
Review Questions
1. Why is it important of Resource modeling?
2. What is resource levelling?
3. What is parallel method schedules resources?
4. Give some resource scheduling examples?
Discussion Questions
Discuss the tools required in Project reviewing?
Application Exercises
1. Explain the different types of project constraints?
2. What are scheduling tools? Explain with examples?
3. Explain the primary impact of project constraints?

CHAPTER 2
Resource allocation method
Learning Objectives
To understand about Resource allocation.
Understand the resource allocation report.
Explain the methods of allocation of resources.
To gain the idea of Resource leveling.
2.1 Introduction
Resource allocation is the process of determining the best way to use available assets or
resources in the completion of a given project. Companies attempt to allocate resources in a
manner that helps to minimize costs while maximizing profits, typically by using strategic
planning methods to structure the operation, establish operational guidelines, and implement
policies and procedures that move the business toward the achievement of its goals. The
actual process will vary, depending on the type of project undertaken and the collection of
tangible and intangible assets on hand.
As it relates to project management in general, resource allocation involves the scheduling
and use of materials, equipment, and labor in order to achieve the identified goal. This means
that the allocation process will require determining how to arrange the plant floor to its best
advantage, so that raw materials can move through the manufacturing process with the
greatest degree of efficiency. At the same time, designing tasks so that employees can
achieve the highest levels of production is also important. With the proper allocation and use
of resources, it is possible to limit the waste of raw materials, generate high production rates
per hour, and, in general, allow a company to produce more finished goods during a typical
production day.
While the focus of this process is often on assigning or allocating tangible resources to
different tasks necessary to the success of the project, this type of management strategy also
takes into consideration intangible assets that may be present. For example, a new business
that is attempting to make the best use of available resources may note that a particular
employee has inherent talents that would benefit the company over the long term. Here, the

company may choose to assist that employee in developing his or her talents, ultimately
earning a return on the resources devoted toward that development. Many companies use this
model to develop employees for promotion to supervisory and management positions in later
years, effectively providing the business with a consistent supply of full-qualified leaders for
the next generation.
Resource allocation often focuses on what is happening today, but the process can also be
used to prepare for future scenarios. For example, a business may put together a contingency
plan that allows for the redistribution of resources in the event that one or more of its product
lines experiences a significant decrease in sales. Companies that operate multiple locations
often design contingency plans that help to redistribute or reallocate resources in the event
one of those locations is rendered inoperable by some type of disaster. This type of allocation
preparedness allows the business to continue providing goods and services to customers with
a minimum of interruption, which in turn helps to minimize losses and keep profits as high as
possible under the new circumstances.
2.1.1 Report
Imagine that you use your Quick Base application to manage projects and their related tasks.
You've assigned fourteen tasks to Penny and they're all due on Friday. She'd never say it, but
she can't possibly finish on time. Meanwhile, Fred's yapping to his buddies on the phone
without a thing to do. If only there were a way to measure how much work you've put on
each person's shoulders.
There is! It's Quick Base's Resource Allocation tool. This nifty feature can show you if
you've over or under-committed a staff member, and let you make changes in a snap. The
Resource Allocation report shows you what percentage of your resources' time is filled. At a
glance you can see that Fred has assignments that fill only 20% of his week, while Penny's
assignments add up to 250% of her 40 hour work week. If she can find another 60 hours, no
problem. If not, you may want to transfer some of her tasks to Fred and others.
To access and configure the resource allocation report:
If you've converted your Microsoft Project plan into a Quick Base application using Quick
Base's Synchronization tool, or created an application from Quick Base's Project
Management app templates, your application Dashboard features a number of links.

If your application didn't start life as a Microsoft Project application or one of the templates
mentioned above, you can still use this feature—as long as the table you want it to focus on
includes the following fields:
Resource Name - You need to have a field that includes a name of a resource. This
is usually a user type field called Resource Name or Assigned To.
Note: The resource allocation tool works only with regular user fields; it does not
support the use of list-user fields.
Start - This must be a date field.
Finish - This also must be a date field.
If the table in question meets all these requirements, you can use the resource tool. But, you'll
need to do some setup:
1. Sign into Quick Base.
2. Access the setup screen.
Quick Base displays the Resource Allocation configuration screen.
3. Select the table from the dropdown which contains the task or assignment records
you're tracking. After you do so, Quick Base displays additional fields.
Tip: If your application contains an Assignments table that links Resources to Tasks,
select the Assignments table.
4. Choose a resource field. Select the User field that specifies who's tasked with an item.
Depending on your application, this field is probably named something like Assigned
To or Resource Name.
5. Choose a start date field.
To measure allocation, Quick Base needs to know which field you use to measure the
duration of a job. Within the Start Date dropdown, select the name of the field which
you use to specify the date a task begins.
6. Choose a finish date field.
Round out the picture by telling Quick Base which field users enter a Finish or
completion date. Select the field from the Finish Date dropdown.
7. Tell Quick Base how you measure staff contributions.
In order to measure resource allocation, Quick Base needs to know how you assign
work to each person. Within the In the projects resources are assigned to
tasks section, select one of these three options:

always at 100%. Choose this radio button if your resources work full-time on
the tasks you assign to them. With this setting, Quick Base counts each day in
a task's duration as a 100% commitment. To get a better idea of how this
works, consult the examples that follow discussion of your options.
by some % of the resource's time. Select this option if any of your resources
only complete a portion of a particular task. Quick Base will ask you to choose
the field you use to measure percent effort. So, if you haven't already, you'll
need to create a numeric percentage type field in your Tasks or Assignments
table. The idea is, when you assign a task, you can indicate what percentage
will be completed by the person you've assigned it to. Then the Allocation
report adds this to its calculations. Read on to get some examples of how those
calculations work.
by a specific amount of work (like days or hours). If you track staff effort in
increments of time, like days or hours, select this option. When you do, Quick
Base asks you to choose the field you use to measure effort in time. so, if you
haven't already, you'll need to create a numeric type field in your Tasks or
Assignments table. When you create or assign a task, you'll use this field to
type the number of hours or days an assigned staffer will work on that
particular item. To get your Resource Allocation report to take this number
into consideration, click the Please choose a time loading field dropdown and
select this numeric field. Finally, beneath that dropdown, tell QuickBase if that
field measures time in days or in hours by clicking the appropriate radio
button. If you choose Hours, Quick Base lets you specify how many hours you
and your colleagues work each day. Why? The program needs to know how
long your workdays are.
8. Click Display Resource Allocation.
9. Save the report.
You've created a unique report whose details are stored in the URL you see in your browser's
address bar. If this is a report you want to return to again and again, you'll need to create a
shortcut to this URL. To do so, you can bookmark the page in your browser. If you want to
share this report with your users, go one better and create a hyperlink to the report on your
application's Dashboard page. Add a new hyperlink that opens the report you created or
replace the destination of Report on Resource Allocation link that comes with many project
management app templates. Quick Base displays the Resource Allocation table. If you

decide you want to change any settings you just made, click your browser's back button to
return to the configuration screen.
2.1.2 Reading the Resource Allocation Report
When you've set all your preferences and clicked Display, the report you designed appears.
Each row is a resource and each column represents a week indicated by the date of the
Sunday that kicks off each week. The percentages you see represent each person's allotted
work for the week. But what does that percentage number really mean? QuickBase
calculates that number based on the choices you made when you created the allocation
report. Each figure represents the percentage of a week's work that a given resource is
scheduled to be working on specific jobs.
.
When the Resource Allocation Report first displays, it includes information for ALL task or
assignment records. If you want to see a specific subset (like only tasks belonging to a
certain project or those scheduled to start after a particular date) you can specify that by
selecting a report from the dropdown beneath the table.
2.1.2.1 Reallocating resources
The numbers in the report shown above are out of whack. How can you reallocate these
resources? To do so, click on any value and Quick Base shows a list of the underlying task
or assignment records. Even out the workload by editing them. Assign several to a different
person, for instance. This report is just that: a report. It doesn't perform load balancing. You
must do that manually.

2.2 Methods
2.2.1 Assignment Method
An assignment method is an approach to the allocation of resources, from personnel to
equipment that will result in the most optimal distribution and utilization of those resources.
Assignment methods are used not just in the business world, but also in organizational
structures and a variety of other applications. There are many different ways to approach
resource problems, and periodic reevaluations may reveal new ways to handle them,
especially in changing work environments where needs and resources may change quickly.
Businesses use an assignment method to make budgeting decisions, deciding where to invest
funds and how to distribute monies to different departments and projects. They may consider
past performance, ongoing projects, and things in development when they decide how to
allocate the assets. The goal is to make money available while discouraging waste in a
department, to keep the department functional and lean. Companies may also want to retain
funds for emergencies, investments, and other needs that could arise during their operations.
Equipment and facilities can also be allocated with an assignment method. Businesses have a
finite number of physical resources like computers and warehouses, and need to use them
effectively. It might devote new computers and resources like more bandwidth and storage to
a department working on a big project, for instance, so the project's needs won't outstrip its
available resources. Conversely, a small department might need much less, and would find
new computers or equipment like tablets redundant for its operations.
People can also be treated as resources and sent to various departments and regions under an
assignment method. This can commonly be seen with a sales force, where a company wants
personnel in the right markets at the right times. It can recall salespeople to move them to
different districts, beefing up representation where necessary and cutting back in
communities where these personnel are not as necessary.
The same assignment method approach is used for things like assigning Internet protocol (IP)
addresses, registration numbers for aircraft, liquor licenses, and a wide variety of other
unique identifiers and privileges. The assignment method can help an agency decide how
many to offer, and how to distribute the offer to make it fair and reasonable. In a county with

a small population, for example, few drivers' license numbers are needed by the department
of motor vehicles, while in an urban county with a big population; a huge number might need
to be allocated.
An assignment of trade is a term that is used to describe a situation in which one of the
parties involved in a forward trade decides to assign that trade to a party that was not part of
the original deal. The use of this particular approach is more common with deals that involve
mortgage-backed securities that are part of a deal in a to be announced (TBA) market, and is
usually employed when there is a desire to avoid either the delivery of the securities involved
or to get around making a delivery of those securities. This type of strategy can also be
employed as a means of eventually trading all the relevant assets involved with a loan to that
outside party, who in turn makes a covenant to orchestrate a delivery into the original to be
announced trade.
The underlying purpose of an assignment of trade is usually to control how and when trading
activity on the assets associated on a loan will be delivered in a TBA market. This is
sometimes necessary to ensure that the maximum amount of return is generated from the
deal, while also preventing the rise of any additional risk to the parties involved in the
original deal. By involving a third party in the arrangement, it is easier to manipulate the
delivery of one or more of the securities backing the mortgage loan, both in terms of either
receiving or issuing that delivery. Under the best of circumstances, the strategy helps to forgo
a loss that would have occurred otherwise while still providing the latest party in the
arrangement to receive some sort of benefit from the deal.
The strategy of an assignment of trade goes beyond simply selling one of the underlying
securities to a third party. Typically, the deal will include a covenant by current holders to
sell entire loans to that third party, who in turn is also agreeing to purchase those whole loans.
An originator of a mortgage loan can use this process to effectively reduce risk associated
with holding the loan, while the buyer has the chance to use the transaction to generate a
steady stream of income from the ownership of those mortgage-backed securities associated
with the acquired loans.
Like any type of investment strategy, an assignment of trade does carry some degree of risk.
Default on the mortgage loans associated with the securities can mean losses to whomever
currently holds those assets. This means that if the assignment of trade is complete when the

default on the mortgages involved occurs, it is the third party who ultimately bears the loss.
At the same time, if those mortgage-backed securities are associated with loans that have
floating or variable rates of interest, there is also the opportunity for that investor to enjoy a
greater return than originally projected.
2.2.2 Resource Leveling
Resource leveling is a type of allocation process that seeks to match the demand for specific
resources with the availability of those same resources. The idea is to make sure that when
and as those resources are needed as part of the day to day process of doing business, they are
on hand and ready for use. Managing this balance between demand and availability typically
requires accurately projecting future needs and taking steps to acquire the resources in a
manner that benefits the production process.
One way to understand the concept of resource leveling is to consider a manufacturing plant
that requires certain raw materials in order to produce a line of goods. In order to keep costs
within reason, the business will project the influx of orders from customers and the number of
finished units required to fill those orders in a timely manner. That information is used to
determine the volume of raw materials needed to create those units within the time frame
allotted. Orders are placed so that the raw materials arrive just ahead of when they are needed
to keep the production flowing without any interruption.
It is important to note that resource leveling is not just about knowing what is needed to keep
a production line going, but when to have those resources delivered and available. In many
nations, taxes are assessed on the inventories of raw materials that are kept on hand. By
structuring the delivery of those materials so they do not languish in a warehouse for weeks
on end before entering the production process, companies enjoy less of a tax burden, a move
that helps to enhance the overall profitability of the operation.
At the same time, resource leveling requires accounting for any shifts in demand that would
also affect the arrival of resources at the plant site. For example, if a large customer should
cancel an order, the business would in turn revise the delivery schedule for various lots of
raw materials so that only the resources needed to fill other orders are received. In the event
that a new customer places a large order and requests delivery as soon as possible, there may
be a need to work with suppliers to increase the frequency of materials deliveries in order to

keep up with the increased demand. From this perspective, resource leveling should be
viewed as an ongoing process and not a single event that is considered complete at any given
point in time.
The allocation of resources is an economic theory concerned with the discovery of how
nations, companies or individuals distribute economic resources or inputs in the economic
marketplace. Traditional business inputs are land, labor and capital. Entrepreneurship or
enterprise may also be included in this group since entrepreneurs or enterprises are usually
responsible for the allocation of resources. The economic concept of private resource
allocation is an important area of study in the free market system and the economic theory
known as "the invisible hand."
Many economists believe that "the invisible hand" theory is the driving force for allocating
resources in the free market economic system. Under this theory, the allocation of resources
is created through the self interest, competition and supply and demand of individuals and
companies in the economic marketplace. Individuals and companies distribute resources
through self regulation by using only the inputs they need and selling or giving away their
leftover economic resources or inputs. Through this allocation of resources, the economic
market place grows and expands as more individuals and companies have access to resources.
Each economic resource or input has an important place in the economic marketplace.
Historically, land includes natural resources, such as timber, wildlife, soil and rock. In
modern terms, this economic resource includes buildings, equipment or other major assets
owned by individuals and companies needed to produce consumer goods or services. Labor is
the manpower companies use to transform raw economic resources into finished goods or
services. Capital usually represents the money acquired or made from the sale of consumer
goods and services produced by the other two economic resources. Economics is concerned
with how these resources are allocated to determine the best use for a nation‘s natural
economic resources and the labor of its citizens.
An allocation of resources analysis also looks at the costs involved with acquiring economic
resources or inputs and how efficiently these resources are transformed into valuable goods
or services. This analysis may also attempt to determine the competitive advantage nations or
companies have when using their economic resources or inputs to create goods or services.
Rather than using inefficient production processes or methods to develop goods, nations or

companies may be better off selling their economic resources to other nations or companies
and earn higher amounts of capital resources. Using the competitive advantage method for
the allocation of resources can be a beneficial way to improve the quality of life of
individuals living in the nation or working for private companies.
2.3 Resource Allocation Methods
Resource allocation methods determine what method or policy the Database Resource
Manager uses when allocating a particular resource to a resource consumer group or resource
plan. Oracle provides the following methods shown in Table 2.1 for allocating resources to a
resource consumer group or resource plan:
Table 2-1 Methods for Allocating Resources
Method Resource Resource Recipient
Round-robin method CPU allocation to sessions Resource consumer groups
Emphasis method CPU allocation to consumer groups Resource plans
Absolute method Parallel degree limit Resource plans
2.3.1 CPU Allocation for Resource Plans: Emphasis Method
The emphasis CPU allocation method determines how much emphasis is given to sessions in
different consumer groups in a resource plan. CPU usage is assigned using levels from 1 to 8,
with level 1 having the highest priority. Percentages specify how to allocate CPU to each
consumer group at each level.
The following rules apply for the emphasis resource allocation method:
Sessions in resource consumer groups with non-zero percentages at higher-priority
levels always get the first opportunity to run.
CPU resources are distributed at a given level based on the specified percentages. The
percentage of CPU specified for a resource consumer group is a maximum for how
much that consumer group can use at a given level. If any CPU resources are left after
all resource consumer groups at a given level have been given an opportunity to run,
the remaining CPU resources fall through to the next level. If a consumer group does

not consume its allotted resources, then the resources are passed to the next level, not
given to the other consumer groups at the same level.
The sum of percentages at any given level must be less than or equal to 100.
Any unused CPU time gets recycled. In other words, if no consumer groups are
immediately interested in a specific period of CPU time (due to percentages), the
consumer groups get another opportunity to use the CPU time, starting at level one.
Any levels that have no plan directives explicitly specified have a default of 0% for
all subplans/consumer groups.
The emphasis resource allocation method offers the following advantages:
Setting percentages enables you to bring CPUs online and offline and to add and
remove servers without having to change CPU percentages.
The amount of CPU resources specified is not proportional to the number of servers,
so there is a fine level of control even with a small number of servers.
Setting percentages avoids the starvation problem associated with priorities. Users do
not run at priorities; instead, they run based on the percentages specified for their
resource consumer group. In addition, percentages can be used to simulate a priority
scheme.
2.3,1,1 Parallel Degree Limit for Resource Plans: Absolute Method
The parallel degree limit allows the administrator to specify a limit on the degree of
parallelism of any operation. This parameter is only allowed in directives that refer to
resource consumer groups. Currently, the only resource allocation method for a limit on the
degree of parallelism is the absolute method. Absolute refers to the fact that a number (rather
than a percentage or fraction, for example) specifies how many processes may be assigned to
an operation.
2.3.2 Parallelizing by Block Range
Oracle parallelizes a query dynamically at execution time. Dynamic parallelism divides the
table or index into ranges of database blocks (rowid range) and executes the operation in
parallel on different ranges. If the distribution or location of data changes, Oracle
automatically adapts to optimize the parallelization for each execution of the query portion of
a SQL statement.

Parallel scans by block range break the table or index into pieces delimited by high and low
rowid values. The table or index can be nonpartitioned or partitioned. For partitioned tables
and indexes, no rowid range can span a partition although one partition can contain multiple
rowid ranges. Oracle sends the partition numbers with the rowid ranges to avoid partition
map lookup. Compile and run-time predicates on partitioning columns restrict the rowid
ranges to relevant partitions, eliminating unnecessary partition scans (partition pruning).
This means that a parallel query which accesses a partitioned table by a table scan performs
the same or less overall work as the same query on a non-partitioned table. The query on the
partitioned table executes with equivalent parallelism, although the total number of disks
accessed might be reduced by the partition pruning. Oracle can parallelize the following
operations on tables and indexes by block range (rowid range):
Queries using table scans (including queries in DML and DDL statements)
Move partition
Split partition
Rebuild index partition
Create index (non-partitioned index)
Create table ... as select (non-partitioned table)
2.3.3 Parallelizing by Partition
Partitions are a logical static division of tables and indexes which can be used to break some
long-running operations into smaller operations executed in parallel on individual partitions.
The granule of parallelism is a partition; there is no parallelism within a partition except for:
Queries, which can be parallelized by block range as described above
Composite partitioning, in which the granule of parallelism is a sub-partition
Operations on partitioned tables and indexes are performed in parallel by assigning different
parallel execution servers to different partitions of the table or index. Compile and run-time
predicates restrict the partitions when the operation references partitioning columns. The
operation executes serially when compile or run-time predicates restrict the operation to a
single partition.
The parallel operation may use fewer parallel execution servers than the number of accessed
partitions (because of resource limits, hints, or table attributes), but each partition is accessed

by a single parallel execution server. A parallel execution server, however, can access
multiple partitions.
Operations on partitioned tables and indexes are performed in parallel only when more than
one partition is accessed. Oracle can parallelize the following operations on partitioned tables
and indexes by partition:
CREATE INDEX
CREATE TABLE ... AS SELECT
UPDATE
DELETE
INSERT ... SELECT
ALTER INDEX ... REBUILD
Queries using a range scan on a partitioned index
2.4 Securing Project Rescheduling
2.4.1 Project silos
The company project managers keep their own project plans on their local drive, and a shared
resource pool isn‘t used. In this case, Karen Smith needs a DBA for three weeks beginning
the December 9. Joe Green needs a DBA 25 percent of the time for his three-month project
beginning November 15. Both project managers want to use Frank Kelly. Karen drops by
Frank‘s desk and asks what he‘s working on. He tells her that he‘s doing normal fire fighting
and supporting the CRM project in his "spare time". Karen knows that the CRM project is
scheduled to finish in November. Because this is the third time they‘ve pushed out the date,
Karen decides that the November end date should hold firm. Karen also believes that since
her project is critically important, even if the CRM project slips it shouldn‘t be too difficult to
pull enough strings to get Frank out of fire fighting for the three weeks she needs him.
Satisfied that she has a reasonable staffing solution, Karen sends an e-mail to Frank‘s
manager letting him know that she‘s planning to use Frank in December and she‘s confirmed
that his schedule is clear.
At the same time, Joe is going through a similar process. He too knows that the CRM project
should be completed in November. But even if the CRM project isn't completed, Joe needs
only about eight to 10 hours a week of Frank‘s time. Joe is confident that Frank can fit in

some time somewhere. As a good PM, he also drops a note to Frank‘s boss saying that he‘ll
need Frank for a couple of hours a week starting November 15.
Frank‘s boss receives both notes and sadly shakes his head muttering, ―these people.‖ He
knows that the CRM project is running late and that a couple of production systems are being
persnickety (requiring a great deal of Frank‘s time). But in the past he‘s found that both
Karen and Joe overestimate the amount of support they need. Frank's boss also doesn't want
to join the fight, so he sends an e-mail to the PMs that reads: "Sure, things are a little dicey,
but we‘ll work it out somehow."
It may appear that he is, but in reality he isn‘t. Joe and Karen only think they have a
commitment from Frank or from his boss. Because there isn‘t any common resource
scheduling pool, the PMs have no method in place for identifying the problem. When things
really do start to go wrong in late November and December, the impact can quickly escalate
to the point where multiple projects are put at risk.
2.4.2 Failure of resource pools
When organizations begin to realize the folly of this situation, many of them take the logical
step of implementing a software tool designed to give them a view of their resource pool. If
we replay the same scenario in a shop that uses a tool to track shared resources, the picture
becomes clearer. Frank‘s boss can now see that Frank is scheduled at 200 percent for a three-
week period (100 percent with Karen, 75 percent on normal maintenance, and 25 percent for
Joe). Ignoring the fact that the CRM project will probably slip again, adding another 25
percent to Frank‘s workload, it should be obvious that the situation is fairly critical. So in our
second scenario does the situation get resolved? My experience shows that in many cases the
situation doesn't get resolved but plays out much like the first scenario: No one has the
mechanism for resolving the conflicts. Organizations have come to believe that over
allocation of resources is standard operating procedure.
2.4.3 Prioritized projects
Now let‘s play out the scenario for a third time in an organization that has embraced some
level of workforce planning by looking at their projects at the portfolio level. In this case the

visibility of the problem moves up a level, and management has accepted the role of decision
maker and tiebreaker.
When Karen‘s project was in the initial proposal stage, her requirement for a DBA for three
weeks in the December timeframe showed up right away as a problem. With five projects
scheduled to complete in December and with the holidays, Karen would be able to see from
the start that she has two options: Bring in some outside help by hiring a contractor or delay
the project start date by a month to move her project outside the congested period. At this
point senior management decides that there‘s no real reason to delay the project, and they
accept Karen‘s recommendation that the three weeks' worth of work is perfect for a
contractor. When Joe‘s project was approved, there were no obvious conflicts in resources.
Joe needed a DBA 25 percent of the time, and Frank has 25 percent left open on top of his
maintenance and enhancement work.
In this scenario the problem comes to the surface when the CRM project slips for the fourth
time. The project steering committee recommends to the portfolio management team that the
project be extended yet again, and the impact of this decision can be evaluated against the
other requirements in the organization. Reallocating DBAs isn‘t really the job of the portfolio
management committee, but what the committee can do is to see which projects would be
affected if Joe‘s project were given priority. In our example, the decision is made to transfer
25 percent of Frank‘s troubleshooting work to a new DBA who has completed a number of
training courses and to free up Frank for more project work like Joe‘s. The other work the
new DBA is scheduled to do is then postponed.
2.4.4 Building a culture of decision making
There are a few assumptions that are implicit in scenario number three. The first is that the
organization has chosen to manage its portfolio of projects. This means that there is a
commitment to review and allocate resources against a host of conflicting demands. It also
means that the ostrich mentality has been rejected. This strategy takes guts and backbone to
implement and agreement from the entire executive staff that the CIO and the CIO's
organization have been fully empowered to facilitate these discussions.
Another assumption buried in this scenario is the commitment by the organization to train
and align its current resources with future demands. Most organizations go through a very

difficult time when their resources have one set of skills and all their future projects require
another set of skills. When money was no problem, contractors could always fill the gap. In
today‘s tight economic environment, however, it is actually much more cost effective to
determine what skills will be needed in the future and who should be trained in those skills.
Unfortunately, this strategy also requires a commitment on management‘s part to objectively
assess its staff and their skills and then train, transfer, or terminate employees as needed.
The final assumption buried in this scenario is that all project managers and all support
managers have the discipline to document their resource requirements and that they have the
skills and knowledge to make sure that these resource requirements are realistic based on
either previous projects or their own experience. In order to ensure that this is true, a
company needs to reinforce this behavior in its project teams and offer support through a
Center of Excellence or engage a PMO to help where their own experience or knowledge is
insufficient.
2.4.5 Creating change from the bottom up
In the last couple of years, every project-centered organization I‘ve talked to has placed the
issue of resource management at the top of their list of serious problems. Projects spin out of
control because too few people are trying to handle too many projects without a clear way to
make the pieces of the project puzzle fit. Some of the new tools on the market seem to offer a
quick fix, but, as one of our scenarios illustrates, even with a resource management tool it‘s
still possible for a project to fail if the organization isn‘t willing to admit that people can be
over allocated only in theory rather than in fact.
Resource over allocation can be solved at the organizational level only by establishing clear
project priorities and a clear process for mediating the inevitable conflict in priorities. So if
the problem can be fully solved only at the organizational level, is there anything a nimble
project manager can do to help the situation?
You should consider recruiting other project managers into a Community of Practice (CoP).
Specific recommendations on how to set up a CoP can be found in the article "With a little
help from my friends: Exploring communities of practice in project management". The key is
to get a group of PMs together and to establish a planning committee that would work to keep
PMs from stepping all over one another. Simply making the decision to avoid letting the

situation reach the crisis point and to open up the communication channels will begin to
reduce the probability that resources are mythically over allocated.
Another tool we can use to reduce resource conflicts is risk management. As a general
practice, I begin every project by identifying my critical resources and developing a
contingency plan for replacement or substitution of those resources in the event of an
emergency. In the example above, Frank was clearly a resource everyone counted on. While
most organizations are only lucky enough to have one Frank, it is possible to identify
consultants and upgrade the skills of other personnel to remove an overreliance on one
person. By establishing nothing more than the most minimal practice of risk management,
resource problems can be brought to light early in the project life cycle rather than later when
the solutions are more limited and more expensive.
In the final analysis, resource over allocation is a failure of prioritization, a failure of
planning, and a failure to accept that reality always imposes constraints. The nimble project
manager understands that things will always change and that even in the best of systems there
will be times when multiple projects are competing for the same resource. The only way to
really solve this problem is by eliminating unnecessary conflicts in the initial planning stages
through prioritization and project timing and by establishing the discipline to make conscious
decisions about which projects slip and which stay on track when Murphy‘s Law comes into
play.
Review Questions
5. Why is it important of Resource modeling?
6. What is Resource leveling?
7. What are Resource allocation methods?
8. What are Prioritized projects?
Imagine that you use your Quick Base application to manage projects and their related
tasks. You've assigned fourteen tasks to Penny and they're all due on Friday. She'd
never say it, but she can't possibly finish on time. Meanwhile, Fred's yapping to his
buddies on the phone without a thing to do. If only there were a way to measure how
much work you've put on each person's shoulders?

4. How to measure the resource allocation?
5. What are the different methods of allocation of resources?
6. Explain what do you mean by Securing Project Rescheduling?

CHAPTER 3
Splitting and Multitasking
Learning Objectives
To understand about Multi-Tasking.
Understand about project performance.
Explain the methods of Preparing Project Plan.
To gain the idea of multitasking aspects.
3.1 Multi-Tasking
In most project environments multi-tasking is a way of life. This seemingly harmless activity,
often celebrated as a desirable skill, is one of the biggest culprits in late projects, long project
durations, and low project output. At the same time it is one of the least understood factors in
managing projects.
For companies where projects are of strategic importance, the stakes are very high. Whether
it is delivering their product or service, bringing new products to market, or expanding/
upgrading their operations with new facilities, systems, or capabilities, the financial impact of
being able to reduce project durations and costs, increase the volume of completed projects,
or simply deliver more projects on-time is enormous. So understanding how this often
overlooked practice of multi-tasking is of critical importance to most companies.
3.1.1 Multitasking and the Myth of Productivity
Many people have studied multitasking over the last decade, and most of them have come to
the same conclusion: Multitasking doesn't make us more productive! Several studies have
found that multitasking can actually result in us wasting around 20-40 percent of our time,
depending on what we're trying to do.
The simple reason that multitasking doesn't work is because we can't actually focus on more
than one task at a time. But we think we can – so we multitask to try and get more done.

Imagine trying to talk to someone and write an email at the same time. Both of these tasks
involve communication. You can't speak to someone and write a really clear and focused
email at the same time. The tasks are too conflicting – your mind gets overloaded as you try
to switch between the two tasks.
Now think about listening to someone as you try to write an email. These two tasks are a bit
easier to do together because they involve different skills. But your attention to the person
will fade in and out as you're writing. You simply can't fully focus on both things at once.
The biggest problem with multitasking is that it can lower the quality of our work – we try to
do two things or more things at once, and the result is that we do everything less well than if
we focused properly on each task in turn.
When we switch tasks, our minds must reorient to cope with the new information. If we do
this rapidly, like when we're multitasking, we simply can't devote our full concentration and
focus to every switch. So the quality of our work suffers. The more complex or technical the
tasks we're switching between, the bigger the drop in quality is likely to be. For instance, it
would be almost impossible to write a good-quality presentation while having an emotionally
charged conversation with a co-worker!
Another major downside to multitasking is the effect it has on our stress levels. Dealing with
multiple things at once makes us feel overwhelmed, drained and frazzled. On the other hand,
think of how satisfied you feel when you devote your full attention to one task. You're able to
focus, and you'll probably finish it feeling as if you've not only completed something, but
done it well. This is called being in flow, and it's a skill that can be developed with some
practice.
3.2 Multi-tasking and project performance
Multi-tasking is the act of stopping a task before it is completed and shifting to something
else; in software development the term ―thrashing‖ is often used to describe this practice.
When a task is stopped and started there is the immediate effect of a loss of efficiency. Each
time a person has to re-start a task, time is required to become re-familiarized with the work
and get re-set in where he was in the process. It is very much like the physical set-ups done

on a machine in production. Each time you tear down a machine to do another task, you have
to set it up to run the part again.
While the loss in efficiency is not insignificant, especially in ―knowledge work,‖ it is far from
the most important reason multi-tasking is so damaging. What happens when a task is
interrupted mid-stream is that its completion is delayed. Most people in project management
will readily agree that it is not important when a task finishes, it is important when the project
finishes. The diagram below shows three tasks a given resource must do, related to three
different projects, and when they are expected to finish: Task A after 10 days, B after 20, and
C after 30.
Fig 3.1
But if the resource has to stop and start the task even just once in the process, the actual
completion times of the tasks quickly extends, as shown below. Task A now finishes only
after 20 days instead of 10, task B at 25 days rather than at 20 days, and task C may still
finish on-time at 30 days, without considering the impact of the loss in efficiency.
Fig 3.2
The delays on tasks A and B immediately translates into are delays on the downstream tasks
in those projects, who now can only start at Day 20 and 25 respectively. The impact on
project A is illustrated below. Even in a very small project like this one with just four tasks,
and with only one instance of multi-tasking, the project is delivered almost 30% late. It‘s not
hard to see how the more likely scenario of having several or many instances of multi-tasking
during a project can cause the delays to accumulate considerably and lengthen project
durations considerably.

Fig 3.3
In many companies the impact of multi-tasking is obscured by the fact that in spite of its
prevalence most projects still finish on time. While this reliability is nice, it masks the even
more significant opportunity to cut project durations substantially. If projects are being
delivered on or close to schedule, and multi-tasking is occurring, it can only mean that the
task estimates used in the plan are significantly inflated. In other words, we are planning for
the lost time due to multi-tasking, as this is the only way that the time losses could be
recovered. In such cases, reducing the multi-tasking offers enormous potential to cut the
planned project durations substantially, without eroding delivery performance. These
companies are in a great position to reap the benefits of delivering more projects faster.
For years we have put the project managers, executives, and teams through a simple project
simulation game using beads, first with multi-tasking, and then a second time, blocking it.
The results are nearly always that the time to complete each of the two projects is cut in half,
enabling them to double the output, and cut individual durations in half, simply by
eliminating multi-tasking. And the same happens when companies drive out the multi-tasking
in their own projects.
3.3 Is Multi-tasking really so prevalent?
Given the substantial negative impact on durations and project volume, it makes sense to
explore just how common multi-tasking is. Since multi-tasking is difficult to see or measure
precisely, we need to look at some other things to answer this question. The first issue is to
understand the opportunity to multi-task. The way to see if your organization has the

―opportunity‖ to do bad multi-tasking is ask how many jobs/ tasks an individual has on their
desk at any given point in time. If there is more than one task that could be worked on a
person‘s desk then there is the opportunity for multi-tasking. When we ask managers how
many tasks are on any given persons desk at one time, the not surprising answer is usually
more than five.
The next way to check is to ask people how often they get interrupted or asked to work on
something else that is ―hot‖, ―urgent‖, or ―important‖. In most companies one need not even
ask this as ―constantly shifting priorities‖ is usually one of people‘s biggest complaints in
projects. Every meeting that shifts or alters the priorities of projects, or adds new important
things for someone to do, is a source of multi-tasking. How often does it happen in your
organization?
Another way to look at it is to recognize that in most organizations where multiple projects
are being done simultaneously, the resources who do the work on a project have to serve
multiple, different project managers. For these project managers what is most important tends
to be their projects. As a result they typically create pressure on resources to do their work
first, institutionalizing multi-tasking. And when the multi-tasking starts to creep in, it initiates
a negative spiral that only increases the pressure to multi-task. If one resource starts the
multi-tasking, it delays the completion of their tasks, putting some projects behind. This
increases the pressure on project managers and executives to adjust priorities to compensate,
which in turn creates more, bad multi-tasking. It‘s not hard to see how this spiral quickly
becomes the reality we see in many organizations where managers at all levels are quickly
pulled into managing work priorities across the organization on a daily basis.
On top of it, many resources who work on projects also support daily operational functions
like QA/ QC, production, engineering, customer service. This support role means that they
are frequently presented with unexpected, usually urgent things to do which readily drive
more multi-tasking. The result is that in the majority of companies there is the opportunity
and the pressure to create a significant amount of bad multi-tasking.
3.4 Purpose of Multitasking
Our experience with hundreds of companies is that there are three central reasons
organizations find themselves in the trap of multi-tasking:

Lack of understanding of the impact of multi-tasking
Incorrect assumptions
The desire to do a good job
The simple fact is that most people and organizations do not understand how damaging multi-
tasking is. Our clients, who see the impact illustrated in the bead exercise, mentioned earlier,
are stunned and amazed that eliminating the practice results in a doubling of output and a
halving of the project durations, with no other improvements. Once people do start to
understand how damaging the practice is they become much more conscious of it, and start to
change their behavior and the behavior of their organization.
But understanding is not enough. The drivers of multi-tasking are built into the processes,
measurements, and systems most companies manage their projects. We strive hard to keep
people busy all of the time, to maximize the output of all of our resources and be efficient.
Performance measures on project managers and executives motivate them to focus on
delivering individual projects, without understanding of the impact of their actions on the rest
of the pipeline. Conventional scheduling and pipelining tools pay no attention to these factors
and routinely overload resources making multi-tasking nearly inevitable.
The second reason is ‗incorrect assumptions.‘ Chief among these is the belief that ―the earlier
you start a project, the earlier it will finish.‖ While this is probably a valid statement in a
single project environment where resources do not need to work on multiple projects, starting
new projects earlier only increases the work in process in a multi-project environment and
with it the likelihood of multi-tasking. People will get out of a building during a fire alarm
much faster if they don‘t all rush at the door at once. Though it seems counter-intuitive,
projects will finish earlier and we will get more of them done, if we start them later.
Again here the obstacle for companies in applying these principles is that these erroneous
assumptions are built into the processes, measures, and systems we use to manage projects.
The pressure from upper management and sales to add more projects or start them earlier can
make it virtually impossible for managers below to cope with the pressure to multi-task.
Conventional software, nearly all of which is based on Critical Path methodology, fails to
provide managers with a way to accurately evaluate task priorities across projects. Critical
Path can identify which tasks have priority over others within a given project, but it breaks
down when considering tasks on different projects. How many times does it happen that

someone works on an urgent task, only to learn later that it ended up sitting a downstream
step waiting on something else, or because the priorities shifted again?
The final reason for the pervasiveness of multi-tasking is that people want to do a good job.
People multi-task in response to a perceived need of the organization: an urgent job, a hot
task, a breakdown, a customer complaint, etc. Shifting to work urgent, pressing jobs gives
people a chance to be heroes, to save the day, or put out the fire. In fact if you have multi-
tasking in your organization, it is an almost sure sign that you have people who care about
and are working hard to do a good job for the organization. It is essential to help people to
realize the impact of multi-tasking, so they shift their belief of what it means ―to do a good
job.‖ But this must be backed by the needed process, measurement, and system changes or
their efforts will be overwhelmed by these other forces.
In order to maintain a competitive edge, project managers, particularly technology project
managers, must be able to cope with multiple projects with no less an expectation of
perfection than if their workload consisted just of a single project. The excuse of being ―too
busy‖ to be a great project manager simply doesn‘t work. It can‘t. This is why, more than
ever before, project management is not for everyone.
But multitasking can be done - can be learned - and typically becomes better with experience.
If you are drowning in your project workload and are about to have a complete meltdown,
take a deep breath, step back a moment and take time to reflect on the following techniques:
3.4.1 Preparing Project Plan
It is difficult to think clearly when you are bombarded with one crisis after another. The truth
is, however, there is no better time to step back and remember the fundamentals of project
management than now. The two most important fundamentals are planning and
communication.
First and foremost, recall your project plan. If you don‘t have one, it‘s probably one of the
reasons you are having a nervous breakdown to begin with. Although the temptation is great
to dive right into the project and keep it moving during extremely busy times, you can‘t take
shortcuts in planning. If you don‘t take the time to plan diligently, you won‘t be able to
follow your plan (or communicate expectations and progress). You also won‘t be able to
influence it in the future. Careless planning leads to careless execution. Instead, frontload
your project at the beginning by taking the time to create a complete project plans. Your time

invested will quickly yield returns by turning into a tool which will do most of your hard
work for you moving forward.
3.4.2 Time Management (Prioritize Productively)
When it rains it pours, and for many project managers who are overloaded with work and
seem to be constantly fighting one crisis after the other, it just doesn‘t seem to stop. If it
happens to you, step back and reorganize your project schedules by way of priority in a way
that is traceable and transparent. You should be able to break your project into small parts
with clearly identifiable project milestones.
3.4.3 Prepare to Change (and to Keep Changing)
Setting priorities and developing a plan is just the beginning (especially if priorities are
shifting as one crisis follows another). Constantly changing priorities can become a burden
and put project resources under immense physiological strain. As the project leader, be aware
of how much gear-switching your resources can tolerate before they start tuning out and
becoming less productive. Ride momentum on changes that result in traction-gain and
prepare to fix bottlenecks and make alterations if your tweaks don‘t kick in and produce
results quickly.
3.4.4 Reducing Bad Multi-tasking
The impact on project performance from reducing multi-tasking is profound. Without so
many interruptions and delays on individual tasks the work flows much more quickly and
smoothly. Without adding resources or working people any harder, more projects get
completed, faster. And without the constant pressure to re-prioritize work, and with more
projects tracking on-time, the organizational climate improves dramatically. With these
improvements follow the business results companies in project environments are universally
seeking. The typical results we have seen companies achieve are:
On-time completions to 95+%
Project durations cut by 1/3 or more
Project output 25%-100%
3.5 Stop Multitasking

If we want to improve the quality of our work, lower our stress levels, and become more
efficient, then we need get out of the multitasking habit. Below are some suggestions to help
you cut back on multitasking:
Plan your day in blocks. Set specific times for returning calls, answering emails,
and doing research.
Manage your interruptions. Keeps a log showing that interrupts you the most,
and how urgent the requests are. Once you've compiled a week's worth of
interruptions, politely but assertively approach your colleagues with a view to
managing and reducing their interruptions.
Learn how to improve your concentration so you can focus properly on one
task at a time. Doing this may feel awkward at first if you frequently multitask.
But you'll be surprised at how much you get done just by concentrating on one
thing at a time.
Every time you go to check your email or take a call when you're actually
supposed to be doing something else, take a deep breath and resist the urge. Focus
your attention back to what you're supposed to be doing.
If you get an audible or visual alert when emails come in, turn it off. This can
help you avoid the temptation to check your inbox whenever you get new mail.
Whenever you find yourself multitasking, stop. Take five minutes to sit quietly at
your desk with your eyes closed. Even short breaks like this can refocus your
mind, lower your stress levels, and improve your concentration. Plus it can give
your brain a welcome break during a hectic day.
There will be times when something urgent comes up and you can't avoid
interruptions. But instead of trying to multitask through these, stop and make a
note of where you left your current task. Record any thoughts you had about how
to move forward. Then deal with the immediate problem, before going back to
what you were doing. This way you'll be able to handle both tasks well, and you'll
leave yourself with some clues to help you restart the original task more quickly.
If you find your mind wandering when you should be focusing on something else,
you need to guide your thoughts back to what you are doing by putting yourself
in the moment. For example, you might be sitting in an important team meeting,
but thinking about a speech you'll be giving soon. Tell yourself, "I am in this
meeting, and need to focus on what I'm learning here." Often, acknowledging the
moment can help keep you focused.

3.6 Exposure of Multi tasking
In some companies the impact of multi-tasking is obscured because even though multi-
tasking may be wide spread most projects still finish on time. While this reliability is nice, it
masks the even more significant opportunity to substantially cut project durations. If projects
are being delivered on or close to schedule, and multi-tasking is occurring, it means that the
task estimates are significantly inflated. In other words, we are planning for the lost time due
to multi-tasking, as this is the only way that the time losses from multi-tasking could be
recovered. In such cases, reducing the multi-tasking provides the opportunity to reduce
planned project durations without eroding delivery performance. These companies are in a
great position to reap the benefits of delivering more projects faster.
For years we have put project managers, executives, and project teams through a simple
project simulation game using beads. When a group of beads are moved, it represents the
completion of a task. Two different projects are simulated, first with multi-tasking and then
without multi-tasking. The results typically show that the time required to complete the two
projects is halved when multi-tasking is eliminated, which enables a doubling of the output.
Our experience is that results are repeated hen companies drive out the multi-tasking in their
own projects.
Review Questions
9. Why is Multitasking and the Myth of Productivity?
10. Explain Multi-tasking and project performance?
11. Should multitasking be required? Explain?
12. What are the steps involved in Preparing Project Plan?
Explain in detail the purpose of Multitasking? State this with example?
7. How to measure the resource allocation?
8. Why multitasking is sometimes not required?
9. Explain what is exposure of Multi tasking?

CHAPTER 4
Multi project resources scheduling
Learning Objectives
To explain about Projects.
To analyse about multiple Projects.
To recognise the methods used in Project Scheduling.
To explain the rules based on time constraints.
To identify Resource allocation syndrome.
4.1 Introduction
Projects are limited in quality by three factors:
resources,
time,
scope.
By optimizing both human and financial resources under a fixed duration, a project manager
can maintain or increase the scope and quality of a project. More often, with a fixed scope
and duration, effective project management seeks to maintain quality by optimizing
resources. Frequently, the availability of resources assigned to a project is limited and not
sufficient to accomplish all the required activities, without compromising quality.
In a survey of 176 private and public companies in Canada in 1997, 61 percent of
respondents reported project failures. Of the failed projects, more than three-quarters
exceeded schedules by 30 percent or more, and more than half exceeded their budgets by a
substantial margin. The primary cause of project failure was poor project planning, and
projects failed more often because of scheduling overruns than budget overruns. In these
situations, project managers who do not optimize resources will reduce the quality of the
project or cause delays in activity completion. In a survey of 365 American companies in
1995, only 16 percent of projects were completed on time, on budget, and within
specifications. On average, completed projects were 74 percent of the content of the original
scope.

Since this annual survey began in 1995, there have been some improvements in project
performance such as decreasing failures by 15 percent in 2004. Cost overruns have been
reduced for challenged projects from 180 percent to 43 percent. Still CHAOS estimates that
United States project waste accounts for $38 billion in lost dollar value and $17 billion in cost
overruns.
The benefits to working in an environment with multiple projects include increased learning
opportunities and a rich work environment. However, a large number of projects have scarce
time resources and inadequate routines, and project overload leads to a lack of recuperation
and missed deadlines.
Considering restricted per-period availabilities of multiple resource types, a project must be
finished as early as possible without wasting resources that project managers could use more
efficiently elsewhere. Compounding the problem, companies manage various projects
simultaneously, sharing a pool of renewable resources.
4.2 Multiple Projects
Managing multiple projects has been termed the resource-constrained multiple-project
scheduling problem (RCMPSP).5 Managing this RCMPSP can be accomplished by exact
procedures, metaheuristics, or simple priority rules. For real-world problems with a large
number of jobs, optimizing a resource and cost schedule using exact procedures such as
dynamic programming, or metaheuristic techniques such as search algorithms are
computationally difficult, time-consuming, expensive, and unnecessary.6 Instead
construction companies, urban maintenance schedules, auditors, and software design
companies have used simple heuristic (rules-of-thumb) priority rules to establish priorities for
resources.
The advantage of using priority rules for managing resources is that the rules are
straightforward, which makes them easy to implement. They are also the most commonly
used methods in experimental literature to simulate ideal scheduling of scarce resources for
multiple projects. Also, most commercial scheduling software programs rely on these priority
rules.

To implement simple priority rules, a framework of a scheduling scheme must be present.
This framework includes using parallel, bidirectional, dynamic, and global planning. With the
appropriate scheduling scheme, priority rule setting is as effective as exact procedures and
met heuristics in managing resources.
Healthcare research is unique. If the projects are simply repetitive in nature, managers can
use the Projects in Controlled Environments (PRINCE) model for routine research
supervision. However, healthcare research projects are not repetitive. In contrast, software
engineering projects have a client that has set detailed specifications for the project, and there
are ongoing communications and managed expectations. Healthcare research, especially
academic health services research, has a broad scope and the details cannot be defined at the
start of the project, making planning an ongoing process. In addition, the topic is usually a
one-time subject for academic researchers who have received a grant that may be used to hire
new staff and form new collaborations. With a new team, considerable effort must be put into
early planning and early learning resulting in early schedule slippage, which is the greatest
early warning sign for project failures.
When early schedule slippage occurs, there is no chance of project overruns because the grant
value has been specified. Projects then are compromised in quality by poor planning and have
little advantage for catching up. There is also limited streamlining with non-repetitive tasks
that require judgment. Continual judgment demands cause further delays. With multiple
projects flexibility in planning has been shown to be desirable, but flexibility in execution is
undesirable. Thus, healthcare research requires ongoing planning and execution of
nonrepetitive activities or decisions, since delays in planning contribute significantly to
project failure.
The purpose of this paper is to investigate the effectiveness of management of multiple
projects in healthcare research. This was achieved by first reviewing and summarizing the
literature to identify best practices for managing multiple projects, second by using best
evidence to create a survey, and third by using the survey to identify current practices for
project management of faculty, directors, and research managers. Finally, team members
compared actual management priority setting practices versus best practice. Further, we
present recommendations for setting priorities in the management of multiple projects in
healthcare research when resources are constrained.

4.3 Methods
The electronic databases searched included International Abstracts in Operational Research,
EconLit, ABI/INFORM Global, ProQuest Nursing & Allied Health, Business Source
Complete (Limited to Project Management and Academic Journals), Management &
Organization Studies: A SAGE Full-Text Collection, and OVID (Medline, Embase,
CINAHL). Literature was searched for managing multiple projects in healthcare research,
assignment of priority rules when managing projects in healthcare research, implementation
of simple priority rules in manufacturing/operations setting. Key words used includes:
project planning,
multiple projects,
priority rules,
RCMPSP.
The most common priority rules and the situations in which they performed best were
identified.
4.3.1 Survey
Despite the abundance of priority rules, no previous instrument to assess priority rules was
available. The survey was developed and pretested on a group similar to the target
population. Comments lead to revisions of the survey instrument.
The finalized survey was sent by e-mail to a small convenient sample of healthcare
researchers, including department heads, managers, directors, and faculty and experienced
project managers within an urban academic institution. From the nature of the institution, all
were involved in clinical and health services research. This group was selected because they
were senior staff and faculty who had success in project management, and in most cases had
no formal training in project management such as the citation Project Management
Professional (PMP) designation, or had an MBA or equivalent advanced degree in
management.
The survey instrument was divided into three parts. In part, respondents were asked how
often they used each of most common priority rules. They were allowed to classify their
response as:
―Always,‖

―Very Often,‖
―Sometimes,‖
―Rarely,‖
―Never,‖
―Not Applicable.‖
In next part, we asked the respondents to rank the three most common priority rules, from
first to second to third choice. Further, we asked for details on how many projects they
currently manage, the average project duration, the shortest and longest project, and the
number of staff they have in each project. The choice of top three priority rules were
compared to project characteristics.
A total of 278 references were found that dealt with multiple projects. No direct evidence of
the use of setting priorities was found regarding managing multiple projects in healthcare
research, nor on the implementation of simple priority rules in manufacturing/operations
setting. The literature located on priority rules or RCMPSP provides surveys on types and
number of resource constraints, and the activity and project characteristics. These surveys
provide inputs for the more substantial published literature that provides evidence on optimal
priority rules in computer simulations. Several papers reported on managing projects in
healthcare research and several articles discussed project management in healthcare research.
4.3.2 Common Priority Rules
A review of the literature identified seven priority rules that had robust superiority in
achieving due date and efficient resource management. The following is a description of
these seven most effective priority rules described in the research literature that were
included in the survey instrument. The first priority rule identified First Come First Served
(FCFS), where the first eligible activity is assigned the highest priority. This procedure is
representative of scheduling heuristics found in many dynamic scheduling environments. In
FCFS, activities are not screened by work content or due date. The project manager gives
priority to the earliest arrived activity. In particular, the project manager will not begin a new
activity until the current activity is completed. This could be called the simple checklist
method. A manager adds items to a list of activities to perform, and then assigns items at the
top of the list regardless of activity characteristics.

Table: 4.1
Similar to FCFS is the Shortest Activity for the Shortest Project (SASP), which gives
precedence based on the minimum of the sum of project duration and activity time. Here the
length of the project is considered as well as the length of the activity. SASP could be
answering daily e-mail, while activities that have a longer duration are set aside until the
person completes the little things. This could be called the modified checklist method. A
manager adds items to a list of activities to perform, and then assigns items that are feasible
in a short period of time with preference for short projects.
An opposite of SASP is Maximum Total Work content (MAXTWK). This simple priority
rule looks at the activities that require the most resources and the manager assigns these the
highest priority. The manager assumes that the little tasks that take small amounts of
resources and time will be completed in parallel with the larger tasks.
Similar to MAXTWK is the Resource Scheduling Method (RSM). Under this priority rule,
the manager assigns resources to activities that would increase the project duration if
resources were inadequate. The process has two steps. In the first step, the project manager
determines the timeline of the project and then identifies the sequence of critical activities. In
the second step, the project manager reviews the ability to perform activities subject to the
resource constraints, and then adjusts the schedule of activities subject to these resource
constraints. The goal is to minimize project duration. By using the two-step approach, this
method assigns priorities to activities that are time sensitive subject to resources. This method
is most effective in construction-industry projects.

One priority rule that looks at activities in the overall project flow is Most Total Successors
(MTS). MTS assigns priority to the activities with the largest number of successor activities
that require completion before another activity can begin. For two similar projects, the
priority is given to the project with the most number of activities remaining. This rule ignores
the time constraint of a due date and resource constraints, and is most efficient when two
similar competing projects begin at the same time and have the same due date.
A number of rules are based strictly on time constraints. These include Latest Start Time
(LST), Latest Finish Time (LFT), and Minimum Slack (MINSLK). MINSLK is equivalent to
the Min LST rule and was not included in the survey instrument. The LST is the latest an
activity can start and not extend the overall project duration. In contrast, the Earliest Start
Time (EST) is the earliest possible time (usually in days into the project) that an activity can
be started. Slack is the difference in the EST and LST. Difference between EST and Early
Finish Time (EFT) is the duration of the activity. Similarly, the difference between LST and
Late Finish Time (LFT) is also the activity duration.
Fig 4.1

Limitations of this research include the small sample size of the survey, and the limited scope
of the study, as it was conducted at one urban research center. There is also an obvious
selection bias. The respondents were all at the senior level, suggesting they must have had
success in project management to reach that level. In addition, some respondents provided
feedback on how to improve the survey. Other key information could be collected, such as
the dynamic nature of the projects whether these projects started at similar times, making
some rules more applicable, as well as staff experience and budget details. Finally, the survey
could gather project failure information such as whether projects were compromised in scope
or if budgets or timelines were met.
The setting of priorities must also be considered with other best practice principles for project
management to have efficient use of research resources. Other examples of best project
management practice are limiting tasks to 5 to 10 days, having a project with fewer than 10
members, assigning responsibility for awareness to contingencies, building appropriate slack
and financial buffers, managing expectations, and encouraging informal and formal
communications. In the future, individuals who are designated as project management
professionals (PMP) from the Project Management Institute may become more common. This
designation will establish the project manager as a professional who understands and can
implement the best practice principles.
4.4 Resource allocation syndrome
4.4.1 Introduction
In many organisations, employee workloads consist of a mix of project and operational
assignments. Due to endemic shortfalls in staffing, such folks particularly those who have
key skills and knowledge that generally have little or no spare capacity to take on more work.
However, soon comes along another ―important‖ project in urgent need of staffing and the
rest, as they say, is tragedy: folks who are up to their necks in work are assigned to work on
the new project. This phenomenon is a manifestation of the resource allocation syndrome,
discussed by Mats Engwall and Anna Jerbrant entitled,
4.4.2 Background
Scheduling and resource allocation is a critical part of project planning in multi-project
environments. Those who work in such settings know (often from bitter experience) that,

despite the best laid plans, it is easy to be over-allocated to multiple projects. Engwall and
Jerbrant‘s work delves into the factors behind resource over-allocation via a comparative case
study involving two very different environments: the contracts department of a railway
signaling equipment firm and an R&D division of a telecoms company.
Specifically, the work addresses the following questions:
Are there any (resource allocation) issues that are common to multi-project / portfolio
environments?
What are the mechanisms behind these issues?
As they point out, there are several articles and papers that deal with the issue of
resource allocation on concurrent projects. However, there are relatively few that
tackle the question of why problems arise.
4.4.3 Methodology
As mentioned, the aim was the surface factors that are common to multi-project
environments. To this end, they gathered qualitative data from a variety of sources at both
sites which included:
interviews,
studies of project
technical documentation,
company procedures
direct observation of work practices.
The first study was carried out at the contract division of a mid-sized railway signalling
equipment firm. The division was well-established and had a long history of successful
projects in this domain. As might be expected given the history of the organisation, there was
a mature project management methodology in place. The organisation had a matrix
management structure with 200 employees who were involved in executing various projects
around the world. The work was managed by 20 project managers. Most of the projects were
executed for external clients. Further, most projects involved little innovation: they were
based on proven technologies that project teams were familiar with. However, although the
projects were based on known technologies, they were complex and of a relatively long
duration (1 to 5 years).

The second study was done in the R&D division of a telecom operator. The division, which
had just been established, had 50 employees who worked within a matrix structure that was
organised into five specialist departments. Since the division was new, the project
management procedures used were quite unsophisticated. Projects were run by 7 project
managers, and often involved employees from multiple departments. Most of the projects
run by the division were for internal customers – other divisions of the company. Also in
contrast to the first study, most projects involved a high degree of innovation as they were
aimed at developing cutting-edge technologies that would attract new subscribers. However,
even though the projects involved new technologies, they were of relatively short duration
(0.5 to 2 years).
4.4.4 Results
As might be expected from a study of this nature, there were differences and similarities
between the two organisations that were studied. The differences were mainly in the client
base (external for the contract division, internal for the other), project complexity (complex
vs. simple) and organisational maturity.
Despite the differences, however, both organisations suffered from similar problems. Firstly,
both organisations had portfolios with extensive project interdependencies. As a
consequence, priority setting and resource reallocation was a major management issue.
Another issue was that of internal competition between projects – for financial and human
resources. In fact, the latter was one of the most significant challenges faced by both
organisations. Finally, in both organisations, problems were dealt with in an ad-hoc way,
often resulting in solutions that caused more issues down the line.
From the common problems identified, it was clear that:
In both organizations, the primary management issue revolved around resources. The
portfolio management was overwhelmed issues concerning prioritization of projects
and, distribution of personnel from one project to another, and the search for slack
resources. However, there were no resources available. Furthermore, when resources
were redistributed it often produced negative effects on other projects of the portfolio.
This forced the management to continuous fire fighting, resulting in reactive behavior

and short-term problem solving. However, the primary lever for portfolio
management to affect an ongoing project in trouble was resource re-allocation.
There are a couple of points to note here. Firstly, resource re-allocation did not work.
Secondly, despite major differences in between the two organisations, both suffered
from similar resource allocation issues. This suggests that this resource allocation
syndrome is a common problem in multi-project environments.
4.4.5 Understanding the syndrome
Based on data gathered, it was identified that a number of factors that affect resource
allocation are:
Failure in scheduling: this attributes the resource allocation syndrome to improper
scheduling rather than problems of coordination and transition. The fact of the matter
is that it is impossible for people to shift seamlessly from one project to another.
There is at the very least the overhead of context switching. Further, projects rarely
run on schedule, and delays caused by this are difficult to take into account before
they occur.
Over commitment of resources: This is another common problem in multi-project
environments: there are always more projects than can be handled by available
personnel. This problem arises because there is always pressure to win new business
or respond to unexpected changes in the business environment.
Effect of accounting methods: project organisations often bill based on hours spent
by personnel on projects. In contrast, time spent on internal activities such as
meetings are viewed as costs. In such situations there is an in-built incentive for
management to keep as many people as possible working on projects. A side-effect of
this is the lack of availability of resources for new projects.
Opportunistic management behaviour: In many matrix organisations, the allocation of
resources is based on project priority. In such cases there is an incentive for project
sponsors and senior managers to get a high priority assigned by any means possible.
On the other hand, those who already have resources assigned to their projects would
want to protect them from being poached to work on other projects.

The factors were identified based on observations and from comments made by interviewees
in both organisations. Resource allocation focuses on the first two points noted above:
scheduling and over-commitment. The problem is thus seen as a pure project management
issue one that deals with assigning of available resources to meet demand in the most
efficient way. In reality, however, the latter two points play a bigger role. As the author‘s
state:
Instead of more scheduling, progress reports, or more time spent on review meetings, the
whole system of managerial procedures has to be reconceptualized from its roots. As current
findings indicate: the resource allocation syndrome of multi-project management which is not
an issue in itself is rather an expression of many other, more profound, organizational
problems of the multi-project setting.
The syndrome is thus a symptom of flawed organisational procedures. Consequently, dealing
with it is beyond the scope of project management. The key takeaway from the paper is that
the resource allocation issues are a consequence of flawed organisational procedures rather than poor project
management practices. Project and portfolio managers responsible for resource allocation are only too aware of
this. However, they are powerless to do anything about it because, as Engwall and Jerbrant suggest, addressing
the root cause of this syndrome is a task for executive management.
Review Questions
13. What are multiple Projects?
14. What do you mean by PRINCE?
15. What are the factors that affect resource allocation?
16. What are some responsibilities of Project and Portfolio managers?
Discuss the basic of syndrome? Explain the use of syndrome with examples?
10. Explain the Common Priority Rules? State examples?
11. State the different rules that are based strictly on time constraints?
12. What is Resource allocation syndrome?

CHAPTER 5
Critical Chain Scheduling
Learning Objectives
To explain about Critical Chain scheduling.
To analyse the development aspect of project Scheduling.
To recognise Risk Assessment/Acceptance.
To explain about Product development projects.
To identify Critical Chain approach.
5.1 Introduction
A Critical Chain schedule takes advantage of the 2-point estimate process to translate the
dependency network into a reliable project promise. Reliability comes first from feasibility
assured by explicitly including resource dependencies as well as handoff dependencies in the
determination of the critical chain/path of the project.
Secondarily, the two estimates developed in the planning process are used to aggregate and
concentrate safety where it will do the most good to protect the project‘s promises and its
intended value. The body of the schedule the network of tasks and resources used to identify
the critical chain that makes use of the smaller of the two estimates. The difference between
the ―safe‖ estimate and that ―aggressive but achievable‖ estimate for critical chain tasks is
used to develop the primary characteristic of the critical chain schedule that the buffers. A
project buffer, which protects the final project due date from the variability in performance
on those tasks is built from the estimates associated with the critical chain tasks. Feeding
buffers, which are related to chains of tasks that feed into or merge with the critical chain, are

similarly sized and placed to isolate the critical chain from the integration effects of those
chains, essentially helping to keep the critical.
5.1.1 Critical Chain Schedules and Risk Assessment/Acceptance
Once developed, assessment of the full schedule, including the contribution of the buffers to
project lead-time, provides a clear view into the identified potential of schedule risk for the
project. In non-Critical Chain environments, when contingency is included, it is often hidden,
either in management reserve, or in internal and external commitments. The common practice
of keeping these components off the table hides their true impact and implications. The open
and explicit communication of buffers that allows a clear assessment of what could happen
―in the best of all possible worlds,‖ versus what might happen if individual concerns
accumulate to affect project performance.
The ultimate risk of a project is not delivering the promised value in the required time frame.
If the schedule results in a lead-time that does not support business needs of the project, the
critical chain schedule provides two primary sources for reduction which are the critical chain
and the project buffer. Assumptions that have been made on key critical activities can be
revisited to assess whether additional actions or activities can be added to the project to
reduce variability and the size of the project buffer, or whether task handoffs can be
restructured to allow more parallel activity and reduce the length of the critical chain. At
some point, limits on corrective action are reached, resulting in a buffered schedule that
reflects the accepted risk of the project‘s lead-time and schedule promise.
5.1.2 Critical Chain Schedules and Integration Risk Avoidance/Mitigation

While a lot of emphasis is placed on the project buffer and its protection from critical chain
variability, feeding buffers are just as important. They serve to protect project promises from
a universal source of risk found in every project that involves parallel activity. Integration
risk, i.e., the statistical nature of merging parallel paths, is the primary source of changing
critical paths in traditionally managed projects. If a set of parallel paths of activity each have
a relatively safe 85% probability of completion by certain point in time, it takes only 4 such
paths to turn the chance of an on-time start for the task they integrate into to 52% which is
not much more than that of a flip of a coin. When one considers that projects are typically
made up of integrations of integrations or integrations, there is little wonder that critical paths
change during the life of a projects, and that there is difficulty bringing projects in on time
without relying on heroics or hoop-jumping.
A common tool for assessing this characteristic of risk in traditional critical path project
schedules is Monte Carlo simulation, which provides a view of the impact of these
integrations on the probability of promised project completion. The critical chain schedule
takes these integrations into account up front by explicitly building feeding buffers to deal
with the variability in feeding chains (rather than relying on random amounts of slack or
float). While Monte Carlo simulations advise on the probability of keeping promises,
buffered critical chain schedules are designed to avoid integration risk and keep that
probability high.
5.1.3 Process
Most projects are managed by carefully watching the calendar, comparing where we are
today against some baseline schedule. That schedule typically consists of a series of start and
due dates for consecutive tasks, with due dates of predecessors matching start dates of
successors. Like a train schedule, if a task arrives at its completion on or before its due date,
that portion of the project is considered to be ―on track.‖ Successor resources plan other work
and their availability around those dates. If the predecessor is finished early, the successor
resource may not be available to pick up the handoff. Even if the resource is available, there
is commonly little or no urgency for the successor to start, since we‘re ―ahead of schedule,‖
and that resource will typically tend to other priorities.

The problem with this common practice is that while it is important for trains to arrive at and
depart from their stations at appointed times, project value is more often tied to the absolute
speed from beginning to end. The sooner the entire project is completed; the sooner project
benefits can be accrued. A more appropriate metaphor to guide projects is a relay race, in
which resources are encouraged to pick up the input handoff as soon as it is available, ―run
with it‖ in a full, focused, sustainable level of effort, and hand off the output as soon as it is
complete.
This behavior is exacerbated in environments where schedules are built upon estimates that
are considered commitments by the resources, and therefore contain a substantial amount of
localized safety in each task to protect that commitment. If a project is deemed ―on track,‖
and a resource realizes that there is chance of completing the work well within the ―safe‖
estimate, the desired sense of urgency is again diminished. As a result, resources are
momentarily comfortable sharing their time among several tasks or issues, extending out the
time that they would otherwise be able to hand off their output to the next leg of the relay
race.
Milestone schedules, like training schedules, become, at best, self-fulfilling prophecies, at
least in terms of expectations of speed. They may still take longer due to being derailed by
Murphy‘s Law because they have wasted what might have been early finishes which are now
not available to offset tasks that take longer than anticipated.
5.2 Critical Chain Schedules, Resource Behaviors and Risk Mitigation
Critical Chain schedules address this question of lost safety in two ways. First, the usual
system of task due dates itself is eliminated. The only dates in a critical chain schedule are
launch dates for chains of tasks that have no predecessors, and final due dates associated with

deliverables that are external to the project and which are protected by project buffers. Start
dates of tasks are linked directly to the completion of their predecessors, and communicated
through the buffer management project control process. If you have no due-dates, you have
gone a long way in eliminating due-date behaviors and in repealing Parkinson‘s Law.
Secondly, the safety is moved out of the tasks to the buffers, thereby eliminating the idea of
commitment that needs to be protected on one hand or that is good enough on the other. With
the underlying assumption that the work of a task will take as long as it takes, no matter what
the schedule model assumes, resources are directed to work on tasks without distraction until
complete and handoffs are delivered. At least tasks won‘t be delayed by outside influences.
More importantly, management also must support the ability to do so, avoiding unnecessary
distractions or conflicting priorities. If resources run their leg of the relay race in an effective
and efficient manner, some tasks will take longer than anticipated in the schedule and some
will take less. The project is in a position to take full advantage of early finishes. In this way,
the cumulative risk associated with due-date behaviors is replaced by the consumption and
replenishment of buffers.
5.2.1 Synchronization - Scheduling multiple projects
The TOC multi-project solution recognizes that the effectiveness of individual projects can be
threatened if the organization tries to push more projects through its pipeline than it is
capable of. Scheduling that the actual promising of individual project completions must take
into account any constraining aspects of that pipeline. While the common existence of
practices like multi-tasking or due-date behaviors typically prove out to outstrip any actual
resource constraint, the possibility of such a constraint is useful as an implementation tool for
the multi-project aspect of the approach.
The process of synchronizing project launches to the ability of a commonly, heavily used
resource to deal with those projects helps to minimize pressures to multi-task from the start.
This process starts with a review of projects in the portfolio for the identification of potential
candidates for the choice of a gating/synchronizing resource. The choice of one that is
commonly used across projects and relatively heavily used compared to other resources will
suffice.
The second step is to prioritize the current projects, in terms of criticality of current
commitments, value to the organization, and use of the synchronizing resource. To the extent
that there is no easy consensus of strategic priority for existing projects, basic TOC principles

of throughput per constraint unit and throughput dollar days can be applied to this effort. The
objective of this prioritization is to provide an order in which projects are scheduled through
the synchronizing resource.
Once these priorities, procedures and processes are in place, individual project schedules can
be developed and put into the calendar through the synchronizer schedule. If chosen
correctly, and further protected with capacity buffers, the careful scheduling of this
commonly, heavily used resource will result in a set of schedules in which any concerns
about contention for other resources will be with the ability of buffer management to provide
direction.
5.2.2 Synchronization and Risk Avoidance
When you consider the duration-multiplying effect of multi-tasking, it should be clear that
multi-project risks of cross-project interference could dwarf risks associated with the
individual projects. If project value is time sensitive, the delays suffered by projects due to
resource time slicing across projects can be very expensive indeed.
The replacement of systemic pressure to multi-task with synchronization, combined with the
management of resources for ―relay race‖ behaviors will go a long way to reduce
programmatic risk and to speed project completions across the portfolio. The combination of
the two will help avoid having to deal with hard-to-predict cross-project risks. In addition, the
required careful consideration of the makeup of the pipeline and the active management of
the critical resources identified and used as the synchronization mechanism will aid in
understanding potential weak links for future improvement.

Most importantly, if combined with effective and supporting processes for planning,
scheduling, and control, synchronization of a project portfolio serves to minimize the overall
risks to optimum bottom line performance of the organization that owns the projects and their
outcomes.
At several points in this paper, the need for and benefit of effective project control has been
highlighted. Planning, scheduling and synchronization are all processes that will create a
model of expectation for the project organization. But that model needs to be managed once it
comes into contact with reality. Appropriate resource behaviors, especially the required focus
on the most important task at hand, require the occasional guidance to clarify priorities in a
shifting situation. And if the critical chain scheduling process is used, something needs to be
used to replace task due-dates to assess the health of project promises.
5.3 Project Control with Buffer Management
The buffers introduced in the Critical Chain scheduling methodology do not only serve to
protect project promises in a static manner. They also provide an ongoing view of the health
of the project as reality impacts the expected model that is the original schedule. As tasks
take longer than the schedule anticipates, buffers are consumed. As they take less time, those
buffers are replenished. Awareness of project buffer consumption relative to the completion
of the critical chain (and to the expected variability of the remaining work on the chain)
provides an important forward-looking focal point for managing project execution.
A number of straightforward ways of assessing buffer consumption make it clear to everyone
involved when and where corrective actions need to be taken. Effective Buffer Management

is a critical factor in successful implementations of Critical Chain-based project management
systems.
Buffer Management typically involves a combination of real-time access to buffer condition
and periodic ―buffer management meetings.‖ Real-time, daily updates of project and buffer
status are feasible in a Critical Chain environment due to the simple data needed to update
active tasks. That data requires only one number at the end of each day a current estimate of
time to complete the task at hand. Immediate issues can be quickly identified through this
process.
Periodic multi-project buffer management meetings, typically involving project owners,
project managers, and resource managers, start with buffer status of the portfolio‘s projects.
Those with buffers ―in the green‖ require little if any discussion. Those ―in the yellow‖ or ―in
the red‖ are rightfully the focus of the meeting, with project managers highlighting identified
opportunities and actions for buffer recovery. These meetings are also useful for supporting
regular, forward-looking risk management as well, again with an eye to current buffer
condition and to its ability to absorb the impact of identified risks.
5.3.1 Buffer Management and Risk Identification
Consistent buffer management is a major contributor to the establishment of a risk
management culture in a particular project environment. Risks and their positive flip side
opportunities are, by definition, potential future occurrences that require a forward-looking
approach to support their identification. The everyday process of developing an estimate-to-
complete task status keeps short and immediate-term risks in the forefront of the mind of the
reporting resources. In addition, the elimination of task estimates as commitments and the
related transfer of safety to the buffer should support a greater willingness to raise concerns,
if the buffer is there to absorb them and they are not expected to have to have an immediate
solution to protect their personal performance.
Buffer management also provides a clear view of the cumulative risk effects of project
performance. Buffer consumption at any point in time is the result of all previous work,
which can eat away at the buffer quietly but insidiously as the project progresses. If buffer
consumption is tracked against the amount of chain completed, or alternatively if buffer
remaining is tracked against the amount of buffer required to protect what remains of the
chain, trends of diminishing buffer condition or the crossing of pre-determined thresholds
will serve to identify indications of risk for the project as a whole.

5.3.2 Buffer Management, Risk Assessment and Response Control
Once a possible risk is identified via its impact on buffers, assessment of whether is deserves
further attention is required. There are two mistakes that can be made in dealing with
identified risks not acting on them if action is indicated and acting on them if they don‘t
really matter. Project managers are probably sufficiently paranoid so that the risk of not
acting is relatively remote. However, that same paranoia can sometimes drive analyses and
actions that are not really necessary. With the unnecessary actions only appears to be
distracted in terms of resources and management from getting on with the necessary work.
Buffer charts, tracking buffers condition against chain completion or buffer required for
remaining work, can be utilized in a way that is not unlike the way control charts are used in
statistical process control for production environments. For an identified risk, a ―what-if‖
analysis can be easily performed, resulting in a view of the schedule or budget buffer after its
run-in with the concern. If sufficient buffer remains for protection of the promise from the
variation anticipated for the remaining work, then it is not worth the time and attention
necessary to develop corrective actions. In this way, buffer management as risk response
control has, embedded within it analysis useful for assessment of individual risks as well.
5.4 Buffer Management and Risk Mitigation
The quality of actions taken to avoid or mitigate identified risks is highly dependent on the
quality of thinking that goes into their design. The quality of thinking applied to a situation is
highly dependent on the environment in which it takes place. With buffer management as the
primary project control mechanism, consideration of corrective action takes place when
buffer status leaves what is commonly referred to as the ―green zone‖ and crosses into the

―yellow zone,‖ or when trends of accelerating buffer consumption are detected. These
assessment triggers occur when there is still considerable buffer, and therefore allow the
necessary thinking to take place in an environment that is not one of ―panic.‖
If, on the other hand, it does threaten to move the buffer ―into the red,‖ then the required
mitigation needed to protect the project promise in terms of buffer reclamation necessary to
bring it back to ―the green‖ provides guidance on the magnitude of the required corrective
action.
5.4.1 Risk
Critical Chain-based Project Management and the Theory of Constraints Thinking Processes
provide a range of tools and processes to support Risk Management and the protection of
project value. A common thread them is a forward-looking approach to the management of
projects. Planning with Network Building looks forward to the objectives of the project
before considering the path of activities to get there. The Critical Chain Schedule looks
forward to the final project deliverables without being distracted by intermediate task due
dates that only serve to sub-optimize schedule performance. ―Relay race‖ resource behaviors
look forward with fine focus on the making timely handoffs with quality. Synchronization
looks forward to the capabilities of the pipeline. Buffer Management eschews percent
complete or earned value of completed work as water over the dam, and instead looks
forward to the work remaining, and its variation and risks.
Management of uncertainty and risk in an effort to deliver promised project value with
certainty is what project management is all about, and risk and uncertainty lie in the future.
Critical Chain Scheduling and Buffer Management is not only a technique for the
development and tracking of project schedules. It is a coherent and comprehensive approach
to project management that encompasses and effects other processes and practices associated
with project management as well. Most importantly, its implications for looking forward and
taking appropriate actions for accepting, avoiding, and mitigating risk are significant and
beneficial.

5.5 Project development role
Product development projects, like many other types of projects, often can exceed their
planned schedule by 50% to 100%. Often this is attributed to uncertainty or the unforeseen.
To compensate for this age-old dilemma, managers and project personnel have learned to
compensate by adding additional time to their schedule estimates. Yet even when they do,
projects still overrun their schedules.
The Critical Chain Method (CCM) or Critical Chain Project Management (CCPM) is an
outgrowth of the Theory of Constraints (TOC) developed by Eliyahu Goldratt to scheduling
and managing manufacturing. TOC focuses on identifying and fixing bottlenecks in order to
improve the throughput of the overall system. Likewise, Critical Chain focuses on
bottlenecks. For example, one pharmaceutical company was experiencing significant delays
with drug approvals. After investigation, it found that the bottleneck was statisticians to
analyze clinical trial data. The cost of hiring statisticians was more than offset by the revenue
from getting products to market sooner.
Using the Critical Chain Method, projects can be completed more quickly and with greater
scheduling reliability. The difference between traditional and Critical Chain scheduling is in
how uncertainty is managed. In traditional project scheduling, uncertainty is managed by
padding task durations, starting work as early as possible, multi-tasking, and focusing on
meeting commitment dates. The following bullet points illustrate some of the problems
associated with traditional project scheduling:

Padding task durations (providing worst-case estimates) is done to ensure a high
probability of task completion. The knowledge that there is so much safety time built
into tasks results in various time wasting practices, e.g., waiting until the last moment
to complete a task. As a result, all the safety time can be wasted at the start of the task
so that, if problems are encountered, the task over-runs.
Starting work as early as possible, even when not scheduled, is a response to worst-
case estimates. When workers give worst-case estimates, they don‘t expect to stay
busy with just one task so they multi-task, working on several tasks at once by
switching between them. The result is that everything takes a long time to complete
and very little completes early.
With the focus on meeting commitment dates (start and finish), output from a task
completed early will rarely be accepted early by the next person needing this output.
So, any effort spent in finishing early will be wasted. Early delivery of one task can‘t
be used to offset lateness on another. Lateness, however, is always passed on and the
lost time can‘t be made up without cutting the specifications or increasing resources
allocated to subsequent tasks, if possible.
In Critical Chain scheduling, uncertainty is primarily managed by
a. using average task duration estimates;
b. scheduling backwards from the date a project is needed (to ensure work that
needs to be done is done, and it is done only when needed);
c. placing aggregate buffers in the project plan to protect the entire project and
the key tasks;
d. using buffer management to control the plan.
The key tasks are those on which the ultimate duration of the project depends, also known as
the Critical Chain. The specific steps to identify and manage a Critical Chain schedule are as
follows:
Reduce activity duration estimates by 50%. Activity durations are normal estimates,
which we know to be high probability and contain excessive safety time. We estimate
the 50% probability by cutting these in half.
Eliminate resource contentions by leveling the project plan. The Critical Chain can
then be identified as the longest chain of path and resource dependencies after
resolving resource contentions.

Insert a Project Buffer at the end of the project to aggregate Critical Chain
contingency time (initially 50% of the critical chain path length)
Protect the Critical Chain from resource unavailability by Resource buffers. Resource
buffers are correctly placed to ensure the arrival of Critical Chain resources.
Size and place Feeding Buffers on all paths that feed the Critical Chain. Feeding
buffers protect the Critical Chain from accumulation of negative variations, e.g.
excessive or lost time, on the feeding chains. This subordinates the other project paths
to the Critical Chain.
Start gating tasks as late as possible. Gating tasks are tasks that have no predecessor.
This helps prevent multitasking.
Ensure that resources deliver Roadrunner performance. Resources should work as
quickly as possible on their activities, and pass their work on as they complete it.
Provide resources with activity durations and estimated start times, not milestones.
This encourages resources to pass on their work when done.
Use buffer management to control the plan. Buffers provide information to the project
manager, for example, when to plan for recovery and when to take recovery action.
To support Critical Chain Project Management, specialized CCPM software tools are
needed to implement this philosophy.
The Critical Chain approach is perhaps the most important new development in project
scheduling in the last 30 years. Used properly, the Critical Chain approach is an extremely
powerful means of gaining more predictability, productivity and speed from your project
plans. It has been found to be an effective tool to protect projects from uncertainty and the
effects of Murphy‘s Law.
Review Questions
17. Explain Project Control with Buffer Management?
18. What do you mean by Synchronization of scheduled multiple projects?
19. What are the factors that affect Risk Mitigation?
20. What do you mean by resource behaviour for timely projects?
Discuss the Project development role?

13. Explain why Critical Chain approach is most important development in project
scheduling?
14. What is Critical Chain Schedules and Risk Assessment?
15. What is Integration Risk Avoidance?

CHAPTER 6
Critical Chain Scheduling Methods
Learning Objectives
To explain about Murphy's Law.
To analyse the critical chain theory.
To recognise Critical Path Method approach.
To explain about Bad Multitasking.
To identify monitoring a project.
6.1 Introduction
It all really boils down to the fact that the way we manage for uncertainty in projects is at the
core of improvement of project performance, defined as getting projects done both faster and
with better reliability of the promised final project due date. TOC/CC suggests the shifting of
focus from assuring the achievement of task estimates and intermediate milestones to
assuring the only date that matters that the final promised due date. As a matter of fact, the
scheduling mechanisms provided by CC scheduling allow/require the elimination of task due
dates from project plans. Its benefit is that it allows those who use it to partially avoid
"Parkinson's Law;" i.e., work expanding to fill the time allowed. Take away the idea of time
allowed, and you've got half the battle won. But how to do that is the question that requires us
to look at some current common project practices.
Project tasks are subject to considerable uncertainty, from both the unknowns of the invention
process (in development projects especially) and from the universal effects of "Murphy's
Law." As a result, task estimates that make up project schedules can contain considerable
"safety" in them to try to allow for these unknowns when planning the project. In addition,
many project organizations are multi-project enterprises, with resources frequently working
across projects on more than one significant task in any particular period of time. This
practice of multi-tasking, unfortunately common in many project organizations in many
industries, also leads to expanded project lead times because when a resource alternates
between tasks/projects, the task times for an individual project are expanded by the time that
is spent on the other projects' tasks. Project resources are aware that they're in this
multitasking environment and so their task estimates are further expanded (even

unconciously multiplied by factors of as much as two or three) to account for this practice in
project task commitments. The combination of the effect of the multi-tasking environment
and the need to cover uncertainty lead to "realistic" project task estimates that contain
considerable "safety" above and beyond the actual work time required for a task, and
subsequent project plans and commitments that include these expanded times.
The TOC approach addresses this expansion of project plans with two mechanisms. First, we
remove the safety from the tasks, and aggregate it as "buffers" of time that are sized and
placed in the schedule to protect the final due date of the project from variability in critical
tasks and that protect critical tasks from variability in non-critical tasks that feed them. These
buffers now allow us to shorten task time estimates to aggressive target durations, shortening
the time within which resources strive to to achieve their tasks. These short target durations
(approximately 50% confidence estimates, whose expected overruns are isolated from the
actual project commitments by the buffers), also support the second mechanism. They are so
short that the resources are uncomfortable succumbing to multi-tasking or other distractions.
This behavior supports the additional requirement posed by the CC methodology for
management to enable resources to focus on tasks and to eliminate the multiplying effect of
multitasking on project lead times. This is intuitive to many of us we often isolate project
teams from multitasking in special task forces or "skunk works" when projects are of special
importance. What the TOC approach allows us to do is apply this common sense solution to
the overall project environment.
Using the critical chain theory involves delaying activities‘ schedules until the activities are
scheduled close to their late schedule instead of being scheduled to their early schedule as is
traditionally done in scheduling projects. Because the late schedule essentially places all of
the activities on the critical path, a buffer is placed into the schedule to allow delays in the
project activities without delaying past the promised project completion date.
According to Goldratt, delaying the work of the project to more closely follow the late
schedule has the advantage of allowing the project team to learn from the experience and
knowledge gained in doing other parts of the project?
Traditionally, project schedules have four dates associated with each activity: early start,
early finish, late start, and late finish. Most project managers use the early schedule dates to
schedule their projects. This means that if all the activity work takes place in the early starts

and early finish dates, that work is done as soon as possible. It also means that if anything
goes wrong, there will be the maximum amount of time available to do the work needed to
recover from the problem.
As we saw in our discussion on buffered schedules, scheduling without buffer and using the
project activity‘s most likely durations can have a 50 percent probability of completing the
project on the promise date. It made sense to buffer the project completion by two standard
deviations and creates a promise date that was two standard deviations later than the promise
date predicted by the most likely durations.
Goldratt goes one step further in buffering schedules. Most schedules that we see in
discussions like this one or in classroom situations are rather simple in comparison to real
project schedules. One of the ways they differ is in the magnitude of float. In sample projects,
for convenience, examples are given with relatively few activities and short, easy to
understand schedules. In reality project schedules are longer and more complicated and
frequently have large amounts of float in many activities. In fact, normal projects will have
more activities off the critical path than on it. For this reason we need to pay more attention
to the activities that are not on the critical path.
To use Goldratt‘s terminology, a project schedule has critical and non-critical chains of
activities. The critical chain of activities is the traditional critical path but includes the effect
of resources on the schedule. This means that the critical chain is the list of activities that
have no float after any resource conflicts have been resolved. This is really the definition of
the critical path as it is normally used. It is somewhat misleading that nearly all of the
examples, including ours, calculate the critical path without showing the effect of resource
conflicts.
All the activities in the project that are not on the critical chain are, by definition, noncritical
activities and have some float associated with them. In real projects these activities tend to
group themselves together to form subprojects within the project. These are what Goldratt
calls "feeder chains". The characteristic is that the feeder chains are relatively independent of
the critical chain until an activity on the critical chain depends on them. In case of feeder
chain and critical chain, feeder chain A, B, C, D has quite a lot of independence until the time
activity P on the critical chain depends on it. The same is true of other feeder chains.

The other important point here is that the feeder chains in real projects frequently have large
amounts of float as well. As projects grow, it becomes more likely that there will be groups
of activities that can be thought of as subprojects. These groupings of activities are not likely
to take as long as the activities on the critical chain and will therefore have considerable
amounts of float.
If the feeder chains are scheduled to their early schedule dates, early starts, and early finishes,
there is a disadvantage. The disadvantage is that if changes in requirements, risks, or other
problems occur in the project, much of the work in the feeder chains will already be done and
will have to be ripped out. This problem can be at least partially avoided by scheduling the
feeder chains more toward their late schedule. Delaying the schedule of the feeder chains will
also let us take advantage of lessons learned on the critical chain activities. These can be
applied to the feeder chain activities.
Of course, if the feeder chains are scheduled to their late schedule dates, this essentially puts
all the feeder chain activities onto the critical path. Remembering what critical path really
means, the feeder chain activities will cause a delay in the project completion date if they are
delayed. We don‘t want this, so we need to apply buffers as well. To set our schedule
correctly, taking all of these factors into consideration, we need to do the following:
Calculate the critical chain of the project after resolving resource conflicts and all of
the resource and other schedule constraints.
Buffer the critical path by calculating a two standard deviation buffer and applying it
by starting the project earlier than the early start date or promising the stakeholders a
project completion date later than the early finish date of the project.
Group the feeder chain activities into feeder chains.
Calculate the two standard deviation buffer for the feeder chain and schedule the
activities in the feeder chain according to their late schedule dates minus their buffer.
By scheduling this way the feeder chains have a 95 percent probability of being completed
within their buffered schedule and not affecting the critical chain activities. The critical chain
activities are also buffered so that the probability of missing the buffered promise date of the
project completion is 95 percent.
Under this, we have to reduce the task estimates, but we still have these buffers that include
the protection that was previously spread around and hidden in the tasks. As seen, it was

mentioned that using 50% confidence estimates for the task durations which indicates that, if
allowed to focus on the tasks, half of the time tasks will be done in less than the target plan
and half the time they will take longer. Due to the statistical nature of this uncertainty of
tasks, this leads those using the TOC approach to be able to use buffers that are significantly
shorter than the sum of the safety that was spread around in the previous scheduling
paradigm. After all, those that come in ahead of time will replenish the buffer that was
consumed by those that took longer than expected, assuring the protection of the only date
that counts -- the final project due date. So with the combination of reduced task estimates
due to the aggregation of safety and the reduction of buffer size, overall project plans can be
typically 20-30% shorter than traditional plans with similar initial risk.
There is also another benefit of the use of the buffers, beyond protection of due date
performance. They aren't just passive chunks of time in the schedule, but a rather also provide
the project manager and/or team with a clear indication of the health of the project at any
point in time. The tracking of the consumption of these buffers provides warnings and
indications of potential problems far before the project promise is in real trouble, allowing
development of recovery plans in an atmosphere other than one of crisis. Once a project plan
is implemented and underway, TOC's "Buffer Management" provides built-in risk
management and therefore enhanced reliability of meeting the project due date, even with the
shortened overall project lead time.
As a summary for individual projects, the TOC approach, by viewing the project as a whole
system instead of simply as a chain of independent tasks, allows for both shorter project lead
times and enhanced reliability. As explained, many project organizations are multi-project
environments. How can TOC provide guidance for enhancing the ability of a multi-project
organization to be more productive in the quantity of projects or new products undertaken
and delivered?
Project and task times, due to focus and buffering, are shortened. Therefore, first we expect
that the capacity hidden in and consumed by practices such as multi-tasking and task-based
safety can be unleashed to simply do more work in the same timeframe. But even beyond
that, the core of the TOC view of multi-project environments lies in recognizing that within a
project organization, there is some resource that can be considered a bottleneck or constraint
limiting the ability of the organization to do more projects. When we manage the individual
projects using the TOC approach, the lack of multi-tasking and embedded safety makes it

easier to ascertain the true capacity of project resources, and hence identify the constraint
resource. Once the organization as a whole is managed with the constraint in mind,
management attention becomes far more focused and decisions to further enhance project
capacity are easier to justify and implement.
Shorter project lead times, improved reliability of project due dates, and increased capacity of
the organization to take on more projects are not only predictable but have been observed in a
number of organizations that have used this approach to projects in a variety of industries.
6.2 Concept
Critical Chain Method concepts are that which was first introduced in 1984 by Goldratt. The
main factor for the success of these ideas is that it finds solutions to the classical problems we
encounter once we plan following the Critical Path Method (CPM) approach. CCPM (critical
chain Project Management) is basically a mix of the most recent best practices:
PMBOK: Plan & Control.
TOC (Theory of Constraints): Removal of bottleneck to solve system constraints.
Lean: Remove waste.
Six Sigma: Reduce any deviation from optimum solution.
6.2.1 The problems
Going back to CCM, the main problems it aims to solve are:
6.2.2 Over estimating
This is a problem that usually comes up when defining plans. In a few words, since:
estimation are always cut,
details, at the beginning of a project are not always clear;
tasks that have the biggest uncertainty are systematically over-estimated. We create
contingencies, to protect us from the fact that things we don't know will go wrong. This
process is then amplified because estimation are presented to many stakeholders, at many
levels, and often each level put its own contingency so that at the end the project duration is
usually over estimated.

6.2.3 Student Syndrome.
This happens in case of long projects or loose schedules: usually people will start working on
a task not when planned but when the delivery time will be near. The reasons are linked both
to the other issues we are presenting here (multitasking, parkinson law) and simply
psychological: people will not start working till they will not fell the pressure.
6.2.4 Parkinson’s Law.
This is a notorious empirical law (Work expands so as to fill the time available for its
completion) in Project Management. In other words if you assign 15 day to accomplish a task
that can be done in 10, then it will hardly happen that the work will be completed in 10 day,
but magically it will be completed in 15. Evidences of this law are well known to PMs.
6.2.5 Bad Multitasking
When multitasking is not correctly managed, the result is wasting of time. This is another
well know issue in real projects: when you assign more that one task to a resource, most of
the time you will get inefficiencies, because jumping from one to the other, instead of
completing one and then the other is only making the most critical task going late.
6.2.6 Handling of early finish
The problem in my opinion has even a theoretical reason in the CPM theory. In a few words,
even if we would be able to close a task in advance we wouldn't be able to get the most out of
this.
Indeed if the task is not on the critical path, closing it in advance doesn't give for sure a direct
advantage (maybe you get some resources free, but without planning you wouldn't be able to
use them) if on the other side the task is on the critical path, an early closing could not be so
relevant (in the sens that we could have other tasks that become critical) and, taking the
concept to the limit, we could need of replanning the project or part of it, finding maybe
another critical path. In any case CPM doesn't give a natural way to handle early close in the
project tasks, since it doesn't plan it.
6.3 Planning with CCM

CCM is trying to solve all the issues just present by proposing a new approach to the
preparation of the project plan. The key points of this new approach are:
Plans "Resource constrained" i.e. where the available resources are a constraint.
Scheduling according to the "Late Finish" principle and direct definition of the
critical path (here called critical chain).
Usage of Buffers (added to specific tasks) so that we are able to avoid slipping in the
schedule:
o Project Buffers (PB): Time buffer added at the end of the project (usually
50% of the total duration of the tasks in the critical path).
o Feeding Buffers (FB): Time Buffer added at the end of each sequence of non
critical tasks.
o Resource Buffers (RB): Time Buffer used as early warning to show that the
resource will be used in a specific. Such alert can be put some days before a
resource will actually start working.
Removal of contingency time and cut of the duration of all tasks of 50%.
Somehow the project becomes like a relay race where the "baton" (project flow) goes from
one task to the other, avoiding parallel runs and working only on completing the project,
where any early close gives higher probability of an early close of the overall project.
Define for each task dependencies and assigned resources
Fig 6.1
Plan backward and “as late as possible”
In planning with CCM schedule is done starting from the target date (or from the last task)
and adding the other tasks (according to the dependencies) in a backward process. Once we

close this phase we get the maximum date according to which we can start working on the
project without being late.
Please note that in this approach all tasks are added near the completion date. Sometime
delaying the work can lead to some benefits, for example we minimize Work in Progress and
reduce in initial costs.
Solve resources conflicts by eliminating multitasking
In case of resource conflict, activities will be delayed or started earlier but will not execute in
parallel, with the resource working on both. This means that if two activities use the same
resource, they will be in sequence, instead of lasting more and being shared. Obviously the
most critical activity will have the higher priority. At the end of the phase we should have for
every resource a sequence of not overlapping task assigned.
Identify the critical chain
Now we should be able to identify the critical path of the project. In CCM this is called
critical chain.
Fig 6.2
Cut every task by 50%
All tasks will be correctly estimated (even better estimated using statistical methods) and then
all estimation will be halved.

Fig 6.3
6.4 Introduce Buffers
After eliminating the resource contemptuous and the multi-assignment practice, the
introduction of buffers is the second new idea of CCM: we introduce buffers, i.e. period of
time that protect the project from the fact that if a deliverable is going to be late, the overall
project will not suffer this delay.
CCM uses buffers in critical point of a project and among two or more projects (multiproject
environment) with the idea of making the project steadier, against changes in it. Indeed
without buffer, every change is going to modify the plan. it is exactly the role of buffer to
stabilize the project, acting, somehow, as contingency.
As written up we use three kind of buffer:
o project buffer - We don't add buffer to the tasks of the critical path. We only
add an unique final buffer that should take in account all the
uncertainties within the tasks. This buffer should be around 50% of the
duration of the critical chain.
o feeding buffer - these buffers are added at the end of chains of tasks, that are
not part of the critical path, before connecting to critical tasks so that we take
in account for uncertainties in task not critical.
o resources buffer - These are buffers added as "wake-up calls" to alert
resources so that we are sure that they will be ready to work on task of the
critical chain.

Fig 6.4
At this point the plan is complete. For comparison below you can see the picture of the same
project as worked out by Ms Project by using a resource leveling.
Fig 6.5
6.5 Monitoring the project
Monitoring a project where CCM has been adopted needs to be done using techniques
different slightly different from the traditional ones. All tasks have a duration which is 50%
of the original one, so it doesn't make sense to monitor if the task is closed within the planned
date and to handle like "delay" if a milestone was missed. What makes sense to do, is
monitoring the buffers that were created during the planning phase. As a matter of fact it's
possible to build simple graphs that show the way buffers are consumed as the project goes
on.
If the consumption speed of our buffers is low, we can assume that the project is "on target",
if on the other side the speed is so fast that we can forecast that we will not be able to close
the project without using more buffer that what we planned, in this case we need to perform

some corrective actions, in the worst case to develop recovery plans or to completely replan
the project.
6.5.1 CCM in multi-project environments.
Working in multi-project environment simply amplifies the multitasking problems:
Multitask work generates inefficiencies
Links and Constraints number becomes bigger, making complex to manage project
changes
Focus decrease
CCM approach multi projects with the idea to maximize the capability of completing project
of a structure, based on the priorities and on the constraints coming from the resources. The
way to do it is simple:
Schedule the single projects, according to CCM,
Solve all resource contention problems, working most on the resources most used
among the projects and assuming that is the availability of resources that determines
the speed of the project. Goldratt defines these resources (the ones around which
project are scheduled) as ―drum resources‖
Define the start of the projects according to priorities and boundaries.
With these principles we should be sure that projects are scheduled based on constraints and
capacity of the organization. The final effect will be the one of a better resource usage and the
delivery of critical projects in advance to what happens using traditional schedule methods.
Following an example of schedule in traditional way

Fig 6.6
and the same example worked out by using CCM:
Fig 6.6
6.5.2 Conclusion
6.5.2.1 Project control
I'm quite positive towards CCM, especially in planning for software development; however
one of the areas that is still not comfortable in the project control. Accordingly, CCM is still

needs to develop specific tools in this subject. According to the literature, project analysis
should be done by means of:
Reporting on buffer usage
Comparison of completed task in the critical chain agaist percentage of buffers used,
in a way to estimate completion date of the project
Checking of consumption speed of buffers (or as percentage or as absolute days)
Anyway, think that to control projects only by analyzing buffer consumption, is not such a
strong technique, especially if compared to what is possible to do with CPM. As a matter of
fact we should dig into this area and maybe develop some stronger (mathematical) tools.
If then we move to the area of project costs, we should find a way to expand the concept of
buffer and introduce the "cost buffer", in a way to link the analysis of the cost of a project to
the normal buffer, otherwise cost analysis will be too much random.
6.5.2.2 Risk Analysis and Buffer
In some articles we find that the analysis of buffer consumption can also be linked to risk
analysis, however even in this subject it would be followed that a cautious approach at this
level of maturity, should not integrate the risk management within the buffer analysis, but we
should keep it separated.
6.5.2.3 Correct Estimation
Cutting estimation at 50% is a statement that we should analyze better. In the net it is
possible to find, however in the opinion not all treat the matter clearly as 60% o il 40% could
be good as well.
As suggested, it is important to use a series of estimation and statistical methods to find the
duration of the tasks. Once we have this estimation it is possible to cut the activities in a way
that will give us 50%, 60% or any other well determined percentage of likelihood of task
completion. In this way we would also be able to give a statistical meaning to our plan, as it
is possible to understand by looking at the next picture:

Fig 6.7
6.5.2.4 CCM compared to al CPM
Speaking of software development, CCM, especially at the beginning, can be used with
advanced teams that are aware of risks and characteristics of it and in specific cases (when
task are not fixed duration and don't involve an high number of resources).
As a matter of fact we have a new approach that gives a lot of advantages but deserves some
attention points:
looks easier but it's more complex
Plan with CCM is more complex than planning with CPM. Even tools that we may use are
"calibrated" on CPM, so a bigger work is needed.
You need to know better your project and its characteristics
First you need to have cleat tasks, durations, links and most of all resources. More it is
necessary move from one approach where estimation is unique to an approach where
estimation should be build on a statistical basis.
The statistics are much more important in CCM than in CPM: here the estimation process is
quite important to understand how we approximate buffers estimation and how we handle
them. Indeed buffer duration needs to be estimated as much correct as possible, since it is
from this estimation that we should get the theoretical maximum duration of the project.
6.5.2.5 CCM should be used instead of CPM only when more convenient

Not all projects can be managed in a natural way with this methodology. In my opinion CCM
is best suitable for projects where tasks don't have fixed duration. For example in a gap
analysis project where meetings are the core of the project, the best way is to use the CPM,
since usually it takes a lot of time to schedule all meetings and it is not easy to move them, in
case of some delay or early finish of the meetings. Maybe using a mixed approach, where all
the project is managed using CCM (or CPM) and some specific subprojects are managed with
CPM (or CCM) could bring some improvement, but this need to be checked.
Regardless all this issues CCM is a good planning method and that it make sense to exploit it
both in "real" (by starting with small software projects project, where there is a basic
uncertainty on the duration) both on the theoretical side, by developing better tools for
managing and controlling the project.
6.6 Estimating and Scheduling
Perhaps the most arduous task that afflicts project managers involves keeping today‘s
aggressive project schedules on track. Because resources are continually restricted more and
more and the highly skilled, high-priced resources are often required for multiple projects,
resource constraints become one of the highest risks to the project schedule. To help ensure
that project schedules are met, project managers have learned to concentrate on a project‘s
critical path. They have also learned that the resources used along the critical path the critical
chain of resources especially those resources shared among projects, must be proactively
managed.
This is where Critical Chain Project Management (CCPM) can aid the project manager—by
planning and managing a project‘s schedule through a unique optimization process that joins
the task-dependent critical path with the critical chain—the resource-dependent tasks that
impact the project completion date. The critical chain explicitly defines a resource-leveled set
of tasks. If the quantity of resources is unlimited, the critical path and the critical chain are
identical.
Unfortunately, the resource-leveling activity that identifies the critical chain often extends the
project‘s end date. To meet the original, predefined end date, the new schedule must be
optimized. Critical chain optimization, just like critical path optimization, looks at individual
tasks to determine which time estimates can be shortened. Critical chain optimization,
however, also focuses on a project‘s resources, keeping them levelly loaded through flexible

start times and quickly switching among tasks.
Critical chain optimizing recognizes that the entire safety margin originally built into every
project schedule might not be required and that all tasks, in theory, could be completed ahead
of schedule. Keep in mind, though, that as long as the safety margins exist in individual tasks,
the ability to shorten the overall project length is minimalized. Yet, if the safety margins are
all removed and even one critical task exceeds its estimated length, the completion date for
the entire project is jeopardized
6.6.1 Scheduling Buffers
CCPM methodology places safety margins—buffers—in the project schedule while pushing
individual tasks to completion in the shortest time possible. The project manager applies and
monitors four specific buffers that allow for contingencies where resource risks have the
greatest impact on a project:
The project buffer protects the project from missing its scheduled end date due to variations
along the critical chain. It places a portion of the safety margin time that was removed from
each task estimate into a buffer task, thus moving the times of uncertainty from individual
tasks to a pooled buffer task. The project buffer is inserted between the final scheduled task
and the scheduled project end date. The critical chain starts at the beginning of the project
and ends at the start of the project buffer, not at the end of the project. Time is added to or
subtracted from the project buffer as the actual time required to complete each task changes.
The feeding buffer minimizes the risk that late completion of a non-critical chain task will
affect the critical chain. The project manager inserts an amount of time at those points in the
schedule where inputs from non-critical chain tasks merge with critical chain tasks. The result
is very similar to a relay race where the speed of the race, in general, is able to be maintained
by the overlap in runners at the hand-off point.
The resource buffer is an alert that is sent to critical resources to ensure that they have time to
complete their current tasks and begin to prepare for the critical chain task so that work can
begin on the latter task as soon as the former task is completed. This buffer can be
implemented easily and provides immediate benefit with little or no cost.

The capacity buffer places on-call resources that are available to avoid schedule delays due to
unforeseen issues into the budget. Because this buffer adds additional cost to the budget, it is,
unfortunately, seldom applied such an expense goes against most organization‘s cost control
principles. Obviously, the capacity buffer makes more sense in a multi-project environment,
where the cost can be distributed over multiple project efforts.
The project manager focuses on managing these buffers during the monitoring and control
phases. Frequently updating the time-to-complete for individual tasks while closely
monitoring the consumption and replenishment of the buffers allows the project manager to
track actual project progress against the original schedule. The project manager can
effectively analyze current progress, implement corrective actions, and maintain focus on the
most critical aspects of the project.
6.6.2 CCPM Process
At a high level, the CCPM process for developing and controlling a project schedule is
composed of the following steps:
Reduce individual task estimates dramatically. This is done either by slashing the
estimate by 50 percent or by applying a three-point estimating process to each task.
Resource level the project to remove resource contentions. At this point, the critical
path is transformed into the critical chain.
Aggregate a portion of the reduced task estimates into a project buffer, and insert this
buffer at the end of the project.
Insert feeding buffers at points where non-critical chain paths intersect the critical
chain. The subordination of non-critical chain paths allows continued focus on the
critical chain.
Insert resource buffers where appropriate to reduce the probability that a critical
resource is unavailable when scheduled.
Insert capacity buffers where appropriate.
Limit or eliminate multitasking.
Schedule tasks with no predecessors to start as late as possible.
Encourage tasks to be completed as quickly as possible. Emphasize the importance of
start times and aggressive task completion rather than due dates.
Manage buffers to support preventive and corrective actions.

6.7 Multi-project Environment
Even though CCPM concepts are often applied in a single-project environment, they take on
additional significance in a multi-project environment. The most loaded resource shared
across projects, also called the drum resource, affects the overall completion date or schedule
of the individual projects because each project is forced to progress at the pace of the drum
resource.
Consequently, the critical chain and the paths that merge with it may result from resource
dependencies outside the scope of a single project. Providing visibility to resource conflicts
that exist outside the individual project is necessary to get a true picture of the overall project
management environment within any organization.
Conclusion
If your organization is highly networked, has a large number of projects requiring a few
critical resources or a drum resource, and primarily operates by using time as the dominant
leg of the triple constraint, then CCPM can be a meaningful addition to your project
management toolkit. But every organization, regardless of size and project management
inclinations, should consider gradually incorporating into its current project management
methodology the individual CCPM principles that are applicable.
CCPM may be the most important new approach to project scheduling in the last thirty years.
It is a method that can be applied to meet the ever-increasingly aggressive schedule
requirements that every project manager is facing while, at the same time, helping
organizations to maintain quality and productivity. It has been proven to be an effective
method to protect your projects from the inevitable slippages that occur in every project.
Review Questions
21. Explain Murphy's Law?
22. What is critical chain theory?
23. What are the benefits of benefit of using the buffer?
24. What is Critical Path Method approach?

Discuss the Project development role?
16. Explain Planning with CCM?
17. How many kind of buffer are used in CCM?
18. What is Monitoring a project in CCM indicates?

CHAPTER 7
Application of Critical chain scheduling
Learning Objectives
To explain about Critical Chain Scheduling and Buffer Management.
To analyse the Parkinson's Law.
To recognise problems and challenges in CCS.
To explain more about Murphy's Law.
To generalized the idea about resource buffer.
7.1 Introduction
The approach to project management known as "Critical Chain Scheduling and Buffer
Management" provides mechanisms to allow a "whole system" view of projects. It identifies
and protects what's critical from inevitable uncertainty, and as a result, avoids major impact
of Parkinson's Law at the task level while accounting for Murphy's Law at the project level.
Project managers and teams need to shift their attention from assuring the achievement of
task estimates and intermediate milestones to assuring the only date that matters the final
promised due date. Safety that is typically built into tasks to cover Murphy's Law is
inefficient, leading to longer than necessary (or acceptable) schedules, and apparently
ineffective, given the impact of Parkinson's Law from which many projects suffer.
7.2 Problems and Challenges
Project management must reconcile two conflicting aspects of projects that gives an
increasingly important need for speed in project delivery and the equally important need for
reliability in delivering the project as promised. Project management must deal with
uncertainty in an attempt to deliver project outcomes with certainty. One way of thinking
about how to deal with this conflict is to develop strategies to avoid expansion of project
lead-time (Parkinson's Law) while protecting against Murphy's Law.
The way we manage for uncertainty in projects is at the core of improvement of project
performance, defined as getting projects done both faster and with better reliability of the
promised final project due date. In most projects managed with commonly accepted practices,

this uncertainty is dealt with by focusing on delivery of tasks with the seemingly reasonable
belief that if individual tasks come in on time, the project will as well.
Developed through the application of the Theory of Constraints to the subject of projects,
"Critical Chain Scheduling" suggests the shifting of focus from assuring the achievement of
task estimates and intermediate milestones to assuring the only date that matters--the final
promised due date of a project. As a matter of fact, the scheduling mechanisms provided by
Critical Chain Scheduling require the elimination of task due dates from project plans. One
benefit is that it allows those who use it to avoid the significant impact of "Parkinson's Law;"
i.e., work expanding to fill the time allowed. Take away the idea of time allowed, and you've
got half the battle won. But how to do that is the question that requires us to look at some
current common project practices and how they lead to "Parkinson's Law."
Fig 7.1
People usually derive schedules and their component deadlines from estimates of duration
required by the various tasks that comprise the project. In many cases, project resources know
that they will be held accountable for delivering against their estimate, and equally, that the
organization needs to be able to count on their promise. Therefore, it is prudent that they
include not only the amount of focused effort/time they expect the work to take, but also time
for "safety" to protect their promise. This safety must deal with the uncertainty involved in
the work (Murphy's Law), the impact of distractions and interruptions they live with in their
organization, and, in many cases, the effect of dealing more than one such project at a time.
When looked at as a whole, these estimates are not really a single number, but rather they are
statistical entities, reflecting the probability of task completion in a certain amount of time.

An aggressive estimate, reflecting only the amount of work required might have a 50% level
of confidence, while a longer realistic estimate, one against which the resource is comfortable
committing to, might be closer to an 85-95% range of confidence.
So task estimates have plenty of safety in them, above and beyond the actual expected time to
do the work. Often this safety is the larger part of the estimate, doubling or tripling the
amount of time the work would require if done in a vacuum.
Fig 7.2
In some occasional cases, it may simply be an issue of excessive problems or erroneous
assumptions overwhelming the safety, but the difficulty of bringing in projects on time is so
common that there must be something else happening in the system contributing to the effect.
Perhaps it's in the way the safety is used.
In most projects, estimates are turned into a project schedule a list of dependent tasks with
associated start-dates and due-dates. People plan their work around these dates and focus on
delivering their deliverables by these dates. They also try to plan other work so they are free
to work on the project task at the start date.
The problem comes in when the scheduled time arrives. It often happens that there is other
"urgent stuff" on one's desk when the task shows up in the in-box. And in any event, we have
until the promised date to finish the work, which at this point looks like a long way off due to
the safety included in the estimate. We are comfortable putting off or "pacing" the work in
favor of other stuff because the due date is out there.

The "urgent stuff" takes precedence until we see the due date sneaking up on us, or, as the
following graphic shows, the due date is within even the aggressive expected duration of the
work itself. Sometimes it sneaks up quietly enough that when we look, we realize that it has
now become urgent and gets our attention.
Fig 7.3
So now the originally scheduled project task is hot. If our office has a door, we close it. We
let voice mail pick up our calls. We work at home to get the job done without distractions.
The only problem is the problems.
The safety that we included was not only for the non-project distractions, but also for the
unknowns (the "Murphy") associated with the task itself. We can't know what problems will
crop up until we start the work. And we've started the work later than planned, after eating up
most, if not all, of our safety attending to other important work. There isn't time left to
recover from the problems in time to meet the due date, at least without heroics, burnout, or
loss of quality.
So task deadlines are hard to meet...and cascade through the project, putting the promise of
the final delivery into jeopardy, which creates new "urgent stuff" which impacts other
projects...and so on and so forth.
Even if, by some miracle, you do finish a task early, since the next task is keying off your
original deadline as a start date for their task, will the required resource be available to pick it
up? Or will they feel an urgency to pick it up, since now they have not only their safety, but
also your early delivery to protect their due date? I think not. So the project is pretty well

doomed to meeting the final target date at best, but in all likelihood either missing it, or just
making it with burnout heroics or compromised quality.
7.2.1 Parkinson's Law
This all occurs due to the combination of task due dates and realistic, prudent, "safe"
estimates. We protect our project due dates by protecting task due dates with safety. Then,
from the point of view of the project, we waste that safety due to the comfort it provides, and
put the project promise in jeopardy.
If there were a way of managing projects without task due dates and the undesirable
behaviors they instigate, it would have to deal with several non-trivial challenges:
How can we systematically protect the promise date of an entire project from Murphy
and uncertainty without nailing all the tasks to deadlines on a calendar, which brings
Parkinson and wasted safety time into the picture?
How can we systematically take advantage of early task finishes when they can help
us to accelerate the project and maybe allow us to finish it early, freeing up the
resources to address other projects?
How can we manage the execution of a project -- how do we know what shape our
project is in once it gets started, if we don't have due dates to track?
One solution to these challenges is found in the approach to project management known as
Critical Chain Scheduling and Buffer Management.
7.3 Challenges
7.3.1 Achieving Speed and Reliability
How can we systematically protect the promise date of an entire project from Murphy and
uncertainty without nailing all the tasks to deadlines on a calendar, which brings Parkinson
and wasted safety time into the picture? Three things can help to avoid Parkinson's Law.
Build the schedule with target durations that are too tight to allow/encourage
diversion of attention.
Get rid of task due dates.

Charge management with the responsibility to protect project resources from
interruptions rather than getting in their way with unnecessary distractions.
As previously mentioned, estimates typically include not only the amount of focused effort
and time they expect the work to take, but also "safety" to deal with:
The uncertainty involved in the work itself (Murphy's Law).
The impact of distractions and interruptions they live with in their
organization/environment, and, in many cases.
The effect of dealing more than one such project at a time.
The Critical Chain methodology requires that the schedule be built with only the time to do
the work without any safety. This is the time we expect the work to take if allowed to focus a
full sustainable level of effort on it and if there are no significant problems. We usually
describe this estimate in terms of having a 50% confidence level. In case of management
paradigm shift comes into play because the resources are expected to strive for these "target
durations," in no way can/should the be considered commitments. Otherwise, performance
measurement pressures will result in building safety back in, re-expanding the estimates.
This now leads directly to and supports the second requirement for repealing Parkinson's Law
which is the elimination of due dates. There's an almost Zen-like statement associated with
project tasks that suggests that no matter what any estimate says, "The work will take as long
as the work takes." If we're building a schedule on the basis of aggressive, 50% confidence
durations, we can't expect people to meet them all the time, and therefore there is no way we
can think in terms of due dates.
7.3.2 Early Completion
The first two challenges cross paths at this point. The preceding discussion begs the question
"Without dates, how do we know when particular resources need to be available?" This is
closely related to our second challenge, "How can we systematically take advantage of early
task finishes when they can help us to accelerate the project and maybe allow us to finish it
early, freeing up the resources to address other projects?" Early finishes are simply a special
case of not having predictable dates to tie to our activities.

In the Critical Chain world, there are two kinds of resources; resources that perform critical
tasks and resources that perform non-critical tasks. The ones we really have to worry about in
this context are the critical chain tasks, since they most directly determine how long the
project will take. We want to make sure that critical chain resources are available when the
preceding task is done, without relying on fixed due dates.
There are two simple steps required to accomplish this. Step one: Ask the resources how
much of an advance warning they need to finish up their other work and shift to interruptible
work so that when the preceding project task is complete, they can drop what they're doing
and pick up their critical task. Step two: Require resources to provide regular, periodic
updates of their current estimate of the time to complete their current task. When the estimate
to complete task A matches the advance warning needed by the resource on task B, let the B
resource know the work is on its way and that it should get ready to pick it up.
Compared to traditional project management, this is a bit of a shift away from focusing on
"what we've done" via reporting percent of work complete to focusing on what counts to
assess and address project status of how much time is left to accomplish unfinished tasks.
This process puts us into a position such that we're no longer nailed to the calendar through
due-dates, we can move up activity as its predecessors finish early, and we can avoid the
impact of Parkinson's Law.
7.3.3 Dealing with Murphys Law
But we're not yet done with the first challenge, especially the part about protecting against
Murphy's Law. We've now got a tight schedule supported by these resource alerts to assure
that the critical resources are available when needed and that they can pick up the work when
tasks are finished earlier than expected. The problem is that these "50% estimates" don't do
too much to help us promise a final due date for the project. Through management support to
allow focus, short target durations to maintain that focus, and no due dates or deadlines
distracting us from what needs to be done, we've pretty dealt with Parkinson, but we've left
ourselves wide open to suffer Murphy's slings and arrows. We need to protect the due date
from variation in the tasks, again, especially critical tasks.

Fig 7.4
Let's look back at our original view of the task estimates -- what might be considered the
"90% confidence" estimates that we have usually built our schedules on. The difference
between our 50% and 90% estimates is safety. Instead of spreading it around, among the
tasks, where it usually gets wasted, let's take a "whole system" view and concentrate it where
it will help us. The safety associated with the critical tasks can be shifted to the end of the
chain, protecting the project promise from variation in the critical chain tasks. This
concentrated aggregation of safety is called a "project buffer."
There is an additional advantage to this aggregation of safety in the form of buffers. Because
the tasks' target durations are 50% confidence estimates, we might expect that half the time
they'll come in early and half the time they'll be late. Since the early tasks (which we were
very rarely able to take advantage of in traditional project management) will help to offset
some of the late ones, we don't need all the protection that used to be spread around. So the
project buffer can be smaller than the sum of the parts. I won't go into the statistics here, but
we can usually cut the total protection at least in half and still be safe, resulting in a project
lead-time that can be significantly shorter than in the old paradigm for a project promise of
similar risk.
Now let's turn to the non-critical tasks. Let's assume that they're also allowed to focus on the
task at hand and pass it along as soon as it is done--which should be a universal way of life if
we really want to get projects done in a timely fashion. But we don't want to micro-manage
everybody to the degree we do the critical tasks with the resource availability alerts. Yet we
do want to assure that, if things go wrong in the non-critical, we don't want them to impinge
the ability of the critical tasks to stay on track.

The traditional approach is to start these tasks as early as possible, and hope that the slack or
float is enough to absorb the variability. It might, but then again, it might not. Why not use
the buffer approach like we did with the critical chain and the project due date? In this case,
concentrate the safety associated with chains of non-critical tasks (again, reduced due to
aggregation) as a buffer protecting the start of the critical chain task they feed into--"feeding
buffers."
Note that the feeding buffers are also relied upon to deal with resource timeliness for non-
critical tasks/resources; we don't use the "work-coming alerts" because even if the feeding
buffer is consumed, the worst case is that the critical tasks are delayed and maybe eat some
project buffer. The feeding, non-critical tasks are two buffers away from impacting the
project promise. Also, you gain more by keeping non-critical resources focused on the work
at hand and to assure they finish work that can be passed on to other resources rather than
interrupt them for other non-critical stuff.
We have now built a Critical Chain Schedule. A major distinction from a schedule based on
critical path methodology is the proactive approach of using feeding buffers to keep the
critical chain critical up front rather than relying on reacting to a changing critical path.
Another distinction is the use of a resource-constrained critical path as the project's critical
chain.
Fig 7.5
The Critical Chain Schedule avoids expansion from Parkinson's Law by eliminating due dates
and allowing us to take advantage of early task finishes. This schedule is also protected

against untimely availability of critical resources by the alerts of work coming from
preceding tasks. The project promise is protected from variation (Murphy) in the critical
chain by the project buffer and the critical chain is protected from variation in non-critical
work by the feeding buffers.
7.3.4 Managing Execution
How can we manage the execution of a project -- how do we know what shape our project is
in once it gets started, if we don't have due dates to track? The key is the set of feeding and
project buffers and a process known as "Buffer Management."
As tasks are completed, we know how much they have eaten into or replenished the buffers.
Because we are now getting updated estimates of time-to-completion from currently active
tasks, we can stay on top of how much of the buffers are consumed in an ongoing fashion. As
long as there is some predetermined proportion of the buffer remaining, all is well. If task
variation consumes a buffer by a certain amount, we raise a flag to determine what we might
need to do to if the situation continues to deteriorate. If it deteriorates past another point in
the buffer, we put those plans into effect.
Fig 7.6
This process allows us to stay out of the way of the project resources if things are on track,
build a contingency plan in something other than a crisis atmosphere, and implement that
plan only if necessary.

7.4 Benefits
The preceding description of Critical Chain Scheduling and Buffer Management includes,
embedded in it a number of benefits that can be obtained by projects that make use of the
approach. These include the following:
An aggressive target duration schedule, along with elimination of task due-dates,
minimizes impact of "Parkinson's Law."
Buffers allow resources to focus on work without task due-date distraction and
efficiently protect against "Murphy's Law" with shorter project lead-times through
concentrated safety protecting what is crucial to project success.
Resource alerts and effective prioritization of resource attention allow projects to take
advantage of good luck and early task finishes while buffers protect against bad luck
and later than scheduled finishes.
Buffer Management provides focus for schedule management, avoids unnecessary
distraction, and allows recovery planning to take place when needed, but well before
the project is in trouble.
There are additional benefits of this approach when the concepts that underlie it are expanded
to multi-project environments. While beyond the scope of this article, suffice it to say for
now that the use of buffers to prioritize resource attention will allow such organizations to
allow the focus on the task at hand to speed projects in the context of multi-project programs.
The Critical Chain approach to single projects allows the multi-project environment to avoid
the lead-time multiplying effect of multi-tasking.
To achieve these benefits, it must be recognized that the implementation of Critical Chain
Scheduling and Buffer Management is not a simple technical change of how we build and
monitor projects, but requires broad management changes. Some of the significant shifts
include:
Stop spreading safety, hidden and wasted in the tasks. Concentrate safety in strategic
places that protect what is important to the project from Murphy's Law. This can only
happen effectively when resources trust management and project owners to accept
that their tasks-- target durations are not commitments and that the buffers are
sufficient to protect the project.

Stop the behaviors that waste time in the project. Avoid task due-date focus and
Parkinson's Law. Old habits are hard to break. Project managers must stop publishing
date-laden project schedules.
Avoid resource multi-tasking and the lead-time multiplication it results in. Focus on
the task at hand. Management must take responsibility for protecting resources from
competing priorities that drive multi-tasking.
Account properly for resource contention. Project managers, when building project
schedules must realize resource dependency is as real as task dependency when
determining what is critical for the project.
Track the consumption and replenishment of buffers. The project team must plan and
act to recover when necessary, as dictated by buffer status, but only when necessary,
in order to avoid unnecessary distraction of project resources who should be allowed
to focus on their work.
Putting Critical Chain Scheduling and Buffer Management in place is not quite as easy as
flipping a switch or turning on a new piece of software. It requires real change in how
projects, resources, and priorities are managed. But if project speed and reliability are
important to an organization, it may well be worth the effort to assess the potential benefits.
7.5 Projects
Product development projects, like many other types of projects, often can exceed their
planned schedule by 50% to 100%. Often this is attributed to uncertainty or the unforeseen.
To compensate for this age-old dilemma, managers and project personnel have learned to
compensate by adding additional time to their schedule estimates. Yet even when they do,
projects still overrun their schedules.
The Critical Chain Method (CCM) or Critical Chain Project Management (CCPM) is an
outgrowth of the Theory of Constraints (TOC) developed by Eliyahu Goldratt to scheduling
and managing manufacturing. TOC focuses on identifying and fixing bottlenecks in order to
improve the throughput of the overall system. Likewise, Critical Chain focuses on
bottlenecks. For example, one pharmaceutical company was experiencing significant delays
with drug approvals. After investigation, it found that the bottleneck was statisticians to

analyze clinical trial data. The cost of hiring statisticians was more than offset by the revenue
from getting products to market sooner.
Using the Critical Chain Method, projects can be completed more quickly and with greater
scheduling reliability. The difference between traditional and Critical Chain scheduling is in
how uncertainty is managed. In traditional project scheduling, uncertainty is managed by
padding task durations, starting work as early as possible, multi-tasking, and focusing on
meeting commitment dates. The following bullet points illustrate some of the problems
associated with traditional project scheduling:
Padding task durations (providing worst-case estimates) is done to ensure a high
probability of task completion. The knowledge that there is so much safety time built
into tasks results in various time wasting practices, e.g., waiting until the last moment
to complete a task. As a result, all the safety time can be wasted at the start of the task
so that, if problems are encountered, the task over-runs.
Starting work as early as possible, even when not scheduled, is a response to worst-
case estimates. When workers give worst-case estimates, they don‘t expect to stay
busy with just one task – so they multi-task, working on several tasks at once by
switching between them. The result is that everything takes a long time to complete
and very little completes early.
With the focus on meeting commitment dates (start and finish), output from a task
completed early will rarely be accepted early by the next person needing this output.
So, any effort spent in finishing early will be wasted. Early delivery of one task can‘t
be used to offset lateness on another. Lateness, however, is always passed on and the
lost time can‘t be made up without cutting the specifications or increasing resources
allocated to subsequent tasks, if possible.
Given these issues, it‘s not surprising that the most projects are always late. In Critical Chain
scheduling, uncertainty is primarily managed by:
i. using average task duration estimates;
ii. scheduling backwards from the date a project is needed;
iii. placing aggregate buffers in the project plan to protect the entire
project and the key tasks;
iv. using buffer management to control the plan.

The key tasks are those on which the ultimate duration of the project depends, also known as
the Critical Chain. The specific steps to identify and manage a Critical Chain schedule are as
follows:
1. Reduce activity duration estimates by 50%. Activity durations are normal estimates,
which we know to be high probability and contain excessive safety time. We estimate
the 50% probability by cutting these in half.
2. Eliminate resource contentions by leveling the project plan. The Critical Chain can
then be identified as the longest chain of path and resource dependencies after
resolving resource contentions.
3. Insert a Project Buffer at the end of the project to aggregate Critical Chain
contingency time
4. Protect the Critical Chain from resource unavailability by Resource buffers. Resource
buffers are correctly placed to ensure the arrival of Critical Chain resources.
5. Size and place Feeding Buffers on all paths that feed the Critical Chain. Feeding
buffers protect the Critical Chain from accumulation of negative variations, e.g.
excessive or lost time, on the feeding chains. This subordinates the other project paths
to the Critical Chain.
6. Start gating tasks as late as possible. Gating tasks are tasks that have no predecessor.
This helps prevent multitasking.
7. Ensure that resources deliver Roadrunner performance. Resources should work as
quickly as possible on their activities, and pass their work on as they complete it.
8. Provide resources with activity durations and estimated start times, not milestones.
This encourages resources to pass on their work when done.
9. Use buffer management to control the plan. Buffers provide information to the project
manager, for example, when to plan for recovery and when to take recovery action.
7.5.1 All project managers have to deal with uncertainty as a part of their daily work. Project
schedules, so carefully constructed, are riddled with assumptions, caveats and ,yes,
uncertainties - particularly in task (activity) durations. Most project management treatises
recognise this, and so exhort project managers to include uncertainties in their activity
duration estimates. However, the same books have little to say on how these uncertainties
should then be integrated into the project schedule in a meaningful way. Sure, well-
established techniques such as PERT do incorporate probabilities into a schedule via an
averaged or expected duration. But the final schedule is deterministic, and makes no explicit
allowance for delays. Any float that appears in the schedule is purely a consequence of an

activity not being on the critical path. The float, such as it is, is not an allowance for
uncertainty.
Since PERT was invented in the 1950s, there have been several other attempts to incorporate
uncertainty into project scheduling. Some of these include, Monte Carlo simulation and, more
recently, Bayesian Networks. Although these techniques offer more sophisticated estimates
of uncertainty, they don't really address the question of how uncertainty is to be managed in a
project schedule. What's needed is a simple technique to protect a project schedule from
Murphy, Parkinson or any other variations that invariably occur during the execution of
individual tasks. Eliyahu Goldratt proposed just such a technique in his business novel,
Critical Chain. Here we discuss the critical chain method, - a technique to manage uncertainty
in project schedules. In a discussion, general characteristics of activity or task estimates is
followed by a discussion on why the buffers or safety we build into individual activities do us
no good - i.e. why projects come in late despite the fact that most people add considerable
safety factors on to their activity estimates. This then naturally leads on to a discussion of
how buffers should be added in order to protect schedules effectively. This is the heart of the
Critical Chain method.
7.5.2 Characteristics of activity duration estimates
Consider an activity that you do regularly - such as getting ready in the morning. You have a
pretty good idea how long the activity takes on average. Say, it takes you an hour on average
to get ready - from when you get out of bed to when you walk out of your front door. Clearly,
on a particular day you could be super-quick and finish in 45 minutes, or even 40 minutes.
However, there's a lower limit to the early finish - you can't get ready in 0 minutes!. On the
other hand, there's really no upper limit. On a bad day you could take a few hours. Or if you
slip in the shower and hurt your back, you mayn't make it at all.
The distribution starts at a non-zero cutoff (corresponding to the minimum time for the
activity); increases to a maximum (corresponding to the most probable time); and then falls
off rapidly at first, then with a long, slowly decaying, tail. The mean (or average) of the
distribution is located to the right of the maximum because of the long tail. In the example, t0
(30 mins) is the minimum time for completion so the probability of finishing within 30 mins
is 0%. There's a 50% probability of completion within an hour, 80% probability of
completion within 2 hours and a 90% probability of completion in 3 hours. The large values

for t80 and t90 compared to t50 are a consequence of the long tail. OK, this particular
example may be an exaggeration - but you get my point: if you want to be really really sure
of completing any activity, you have to add a lot of safety because there's a chance that you
may "slip in the shower" so to speak.
It turns out that many phenomena can be modeled by this kind of long-tailed distribution.
Some of the better known long-tailed distributions include lognormal and power law
distributions. A quick review of the project management literature revealed that lognormal
distributions are more commonly used than power laws to model activity duration
uncertainties. This may be because lognormal distributions have a finite mean and variance
whereas power law distributions can have infinite values for both. In any case, regardless of
the exact form of the distribution for activity estimates, what's important and non-
controversial is the short cutoff, the peak and long, decaying tail.
Most activity estimators are intuitively aware of the consequences of the long tail. They
therefore add a fair amount of "air" or safety in their estimates. Goldratt suggests that typical
activity estimates tend to correspond to t80 or t90. Despite this, real life projects still have
difficulty in maintaining schedules.
A schedule is essentially made up of several activities connected sequentially or in parallel.
What are the implications of uncertain activity durations on a project schedule? Well, let's
take the case of sequential and parallel steps separately:
Sequential steps: If an activity finishes early, the successor activity rarely starts right
away. More often, the successor activity starts only when it was originally scheduled
to. Usually this happens because the resource responsible for the successor activity is
not free - or hasn't been told about the early finish of the predecessor activity. On the
other hand, if an activity finishes late, the start of the successor activity is delayed by
at least the same amount as the delay. The upshot of all this is that - delays
accumulate but early finishes are rarely taken advantage of. So, given a long chain of
sequential activities, you can be pretty sure that there will be delays!
Parallel steps: In this case, the longest duration activity dictates the finish time. For
example, if we have three parallel activities of duration 5 days per activity. If one of
them ends up taking 10 days, the net effect is that three activities, taken together, will

complete only after 10 days. In contrast, an early finish will not have an effect unless
all activities finish early. Again we see that delays accumulate; early finishes don't.
The discussion assumed that activities are independent. In a real project activities can be
highly dependent. In general this tends to make things worse than a delay in an activity is
usually magnified in a dependent successor activity.
We saw that dependencies between activities can eat into safety significantly because delays
accumulate while gains don't. There are a couple of other ways safety is wasted. These are:
Multitasking It is recognised that multitasking - i.e. working on more than one task
concurrently - introduces major delays in completing tasks. See these articles by
Johanna Rothman and Joel Spolsky, for a discussion of why this is so. Incidentally,
I've discussed techniques to manage multitasking on my blog.
Student syndrome this should be familiar to any one who's been a student. When
saddled with an assignment, the common tendency is to procrastinate until the last
moment. This happens on projects as well.
Parkinson's Law states that "work expands to fill the allocated time." This is most
often a consequence of there being no incentive to finish a task early. In fact, there's a
strong disincentive from doing so because the early finisher may be:
a. accused of overestimating the task
b. rewarded by being allocated more work.
1. Consequently people tend to adjust their pace of work to just make the scheduled
delivery date, thereby making the schedule a self-fulfilling prophecy.
Any effective project management system must address and resolve the above issues.
The critical chain method does just that. Now with the groundwork in place, we can
move on to a discussion of the technique. The second, more general, case discusses
the situation in which there is resource contention.
7.6 The critical chain - special case
In this we look at the case where there's no resource contention in the project schedule. In this
(ideal) situation, where every resource is available when required, each task performer is

ready to start work on a specific task just as soon as all its predecessor tasks are complete.
Sure, we'll need to put in place a process to notify successor task performers about when they
need to be ready to start work.
7.6.1 Preventing the student syndrome and Parkinson's Law
To cure habitual procrastinators and followers of Parkinson, Goldratt suggests that project
task durations estimates be based on a 50% probability of completion. This corresponds to an
estimate that is equal to t50 for an activity (you may want to have another look at the Figure 1
to remind yourself of what this means). Remember, as discussed earlier, estimates tend to be
based on t80 or t90, both of which are significantly larger than t50 because of the nature of
the distribution. The reduction in time should encourage task performers to start the task on
schedule, thereby avoiding the student syndrome. Further, it should also discourage people
from deliberately slowing their work pace, thereby preventing Parkinson from taking hold.
As discussed, a t50 estimate implies there's a 50% chance that the task will not complete on
time. So, to reassure task estimators / performers, Goldratt recommends implementing the
following actions:
Removal of individual activity completion dates from the schedule altogether. The
only important date is the project completion date.
No penalties for going over the t50 estimate. Management must accept that the
estimate is based on t50, so the activity is expected to overrun the estimate 50% of the
time.
The above points must be explained to project team members before you attempt to
elicit t50 estimates from them.
7.6.2 The resource buffer
The alert reader may have noticed a problem arising from the foregoing discussion of t50
estimates: if there is no completion date for a task, how does a successor task performer know
when he or she needs to be ready to start work? This problem is handled via a notification
process that works as follows: the predecessor task performer notifies successor task
performers about expected completion dates on a regular basis. These notifications occur at
regular, predetermined intervals. Further, a final confirmation should be given a day or two
before task completion so all successor task performers are ready to start work exactly when

needed. Goldratt calls this notification process the resource buffer. It is a simple yet effective
method to ensure that a task starts exactly when it should. Early finishes are no longer
wasted!
7.6.3 The project buffer
Alright, so now we've reduced activity estimates, removed completion dates for individual
tasks and ensured that resources are positioned to pick up tasks when they have to. What
remains? Well, the most important bit really - the safety! Since tasks now only have a 50%
chance of completion within the estimated time, we need to put safety in somewhere. The
question is, where should it go? The answer lies in recognising that the bottleneck (or
constraint) in a project is the critical path. Any delay in the critical path necessarily implies a
delay in the project. Clearly, we need to add the safety somewhere on the critical path.
Goldratt's insight was the following: safety should be added to the end of the critical path as a
non-activity buffer. He calls this the project buffer. If any particular activity is delayed, the
project manager "borrows" time from the project buffer and adds it on to the offending
activity. On the other hand, if an activity finishes early the gain is added to the project buffer.
Figure 7.2 depicts a project network diagram with the project buffer added on to the critical
path (C1-C2-C3 in the figure).
What size should the buffer be? As a rule of thumb, Goldratt proposed that the buffer should
be 50% of the safety that was removed from the tasks. Essentially this makes the critical path
75% as long as it would have been with the original (t80 or t90) estimates. Other methods of
buffer estimation are discussed in this book on critical chain project management.
7.6.4 The feeding buffer
As shown in Figure 7.2 the project buffer protects the critical path. However, delays can
occur in non-critical paths as well (A1-A2 and B1-B2 in the figure). If long enough, these
delays can affect subsequent critical path. To prevent this from happening, Goldratt suggests
adding buffers at points where non-critical paths join the critical path. He terms these feeding
buffers.
7.6.4.1 The first definition

This completes the discussion of the case where there's no resource contention. In this special
case, the critical chain of the project is identical to the critical path. The activity durations for
all tasks are based on t50 estimates, with the project buffer protecting the project from delays.
In addition, the feeding buffers protect critical chain activities from delays in non-critical
chain activities.
7.6.4.2 The general case
Now for the more general case where there is contention for resources. Resource contention
implies that task performers are scheduled to work on multiple tasks simultaneously, at one
or more points along the project timeline. Although it is well recognised that multitasking is
to be avoided, most algorithms for finding the critical path do not take resource contention
into account. The first step, therefore, is to resource level the schedule - i.e ensures that tasks
that are to be performed the same resource(s) are scheduled sequentially rather than
simultaneously. Typically this changes the critical path from what it would otherwise be. This
resource leveled critical path is the critical chain.
The above can be illustrated by modifying the example network shown in Figure 7.3. Assume
tasks C1, B2 and A2 (marked X) are performed by the same resources.

The resource leveled critical path thus changes from that shown in Figures 7.2 and 7.3 to that
shown in Figure 7.4. As per the definition above, this is the critical chain. Notice that the
feeding buffers change location, as these have to be moved to points where non-critical paths
merge with the critical path. The location of the project buffer remains unchanged.
Review Questions
25. Will Critical Chain work with Earned Value?

26. How does CC-based multi-project management work?
27. How does Critical Chain fit with PMI's PMBOK Guide processes and knowledge
areas?
28. Is there software that supports Critical Chain processes?
If Critical Chain comes from TOC thinking, what is the constraint that's involved?
19. Explain Parkinson's Law?
20. Explain Theory of Constraints in critical chain scheduling?
21. Can Critical Chain concepts be used to manage project cost?

9, Km Milestone, NH-65, Kaithal - 136027, Haryana
Website: www.niilmuniversity.in
“The lesson content has been compiled from various sources in public domain including but not limited to the
internet for the convenience of the users.The university has no proprietary right on the same.”

Best Project Scheduling Techniques.

More Related Content

Similar to Best Project Scheduling Techniques. (20)

More from NIILM University (8)

Recently uploaded (20)

Best Project Scheduling Techniques.