Finalizing the Schedule and Cost Based on
Resource Availability
Considering Resource Availability
• determine if you can accomplish the schedule
with the resources available
Leveling Resources
• is part of the broader topic of resource management.
some of the situations that organizations have to deal with
• Committing people to more than they can reasonably handle
in the given time frame, reasoning that they will find a way to
get it done but putting each of their projects in harm’s way in
so doing
• Changing project priorities and not considering the impact on
existing resource schedules
• The absence of a resource management function that can
measure and monitor the capacity of the resource pool and
the extent to which it is already committed to projects
• Employee turnover and promotions that are not reflected in
the resource schedule
Resource leveling is a process that the project manager
follows to schedule how each resource is allocated to tasks in
order to accomplish the work within the scheduled start and
finish dates of the task.
Resource Leveling
• As resources are leveled, they must be constrained to the ESLF window of the tasks to which they are assigned, or the
project manager must seek other alternatives to resolve the
conflict between resource availability and project schedule.
The resource schedule needs to be leveled for two reasons:
• To ensure that no resource is over-allocated. That is, you do
not schedule a resource to more than 100 percent of its
available time.
• The project manager wants the number of resources (people,
in most cases) to follow a logical pattern throughout the life of
the project. (the number of resources working on a project at
any time is fairly constant).
Resource-Leveling Strategies
You can use three approaches to level project
resources:
– Utilizing available slack
– Shifting the project finish date
– Smoothing
Utilizing Available Slack
• one or more of the project tasks are postponed
to a date that is later than their early start date
but no later than their late finish date.
• When you need to resolve the “stack-up” of tasks
on the schedule, first determine whether any of
the tasks has free slack.
• If moving the start date of the task does not
resolve the over-allocation, you have to use total
slack, and at least one other task will have its
early start date delayed.
Shifting the Project Finish Date
• the critical path may have to be extended to achieve an
acceptably resource-leveled schedule.
• This case could very well mean that the parallel scheduling
on the task network diagram that moved the original finish
date to an earlier one needs to be reversed.
• The start-to-start and finish-to-finish dependencies might
need to be set back to the linear finish-to-start type.
• If you find yourself caught between over-allocated
resources on a schedule that cannot be acceptably leveled
and a firm, fixed completion date, you may have to
consider reducing the scope of the project.
Smoothing
• Occasionally, limited overtime is required to
accomplish the work within the scheduled
start and finish dates of the task.
• Overtime can help alleviate some resource
over-allocation because it allows more work
to be done within the same scheduled start
and finish dates.
Alternative Methods of Scheduling
Tasks
• Rather than treating the task list as fixed and
within that constraint leveling resources, you
could resolve the leveling problem by
considering further decomposition of one or
more tasks.
• Further Decomposition of Tasks
• Stretching Tasks
• Assigning Substitute Resources
Further Decomposition of Tasks
• Suppose that a task requires one person for three days within a
five-day window. There are two days of slack in the schedule for
that task.
• The unavailability of the resource for three consecutive days
beginning on the ES date will require scheduling the task work to a
longer period of time.
• One solution would be to have the resource work for three
nonconsecutive days as early as possible in the five-day window.
• Suppose that the resource is available for the first two days in the
five-day window and for the last day in the five-day window.
• The project manager could decompose the five-day task into two
tasks — one two-day task and one one-day task. The two-day task
would then have an FS dependency on the one-day task.
Stretching Tasks
• Another alternative that preserves the continuity of the
task work is to stretch the work over a longer period of
time by having the resource work on the task at a
percent per day lower than was originally planned.
• In previous example: Suppose the resource is available
80 percent of each day in the five-day window, and you
need four days of work.
Stretching Tasks…
• In this simple example, the percentage was constant over the
five days, but it might also follow some profile.
• For example, suppose you needed the resource for three days
and the resource was available full-time for the first and
second days but only half-time for the remaining three days of
the five-day window.
• You could first split the task into two tasks—a two-day task
and a one-day task.
• The two-day task would fully use the resource and get two
days of work completed.
• The second task would be stretched to two days, and the
resource would be assigned half-time for two days to
complete the remaining day of work on the task.
Assigning Substitute Resources
• One approach would be to use less-skilled
resources and add to the total number of
hours requested. Here, the thinking is that a
less-skilled resource would require a longer
period of time to complete the task work.
• This strategy works only for noncritical path
tasks. Using it for a critical path task would
extend the completion date of the project.
Cost Impact of Resource Leveling
• Resource leveling almost always stretches the
schedule.
• The case where it doesn’t stretch the schedule
may occur when slack is available in the right
places in the schedule.
• Scheduling the work of a resource over a longer
period of time not only removes scheduling
conflicts, but also removes any over-allocations of
that resource.
Cost Impact of Resource Leveling…
• If the resources are billable based on the labor
expended, project costs do not increase.
• If there are resources that are charged on a
calendar basis, project costs will increase.
• If there are incentives for early completion
and penalties for late completion of a project,
a cost impact will be felt as well.
Implementing Micro-Level Project
Planning
• Micro-level planning is another step in the
decomposition of the tasks that are assigned to an
individual. It involves a decomposition to subtasks.
• Micro-level project planning begins with the lowestlevel task defined in the WBS.
• Because it appears in the WBS, it will have
management oversight by the project manager.
• The responsibility for completing this task within a
defined window of time will be assigned to a task
manager
Implementing Micro-Level Project
Planning…
• Continue the decomposition
• These tasks will each be less than two weeks’ duration, so the
subtasks that make them up will be of shorter duration. The
decomposition should be fairly simple and result in tasks of
one to three days’ duration.
• In figure 2.7: The shaded areas of the schedule are nonworkdays and days when a resource is not available.
• There is no need for software support, which simply adds
management overhead with little return on the investment of
time expended to capture and manage it.
Work Packages
• The work to be done within a task is called a work
package.
• The work package is a statement by each task
manager as to how he or she plans to complete the
task within the scheduled start and finish dates.
• if the task manager or anyone working on the task
were not available, someone else could use the work
package to figure out how to continue the work of
the task with minimal lost time.
Purpose of a Work Package
• In addition to the task descriptions, the
package includes start and end dates for the
task.
• The work package also can be adapted to
status reporting (measure what percent of the
task is complete).
Format of a Work Package
• Work package assignment sheet
– It contains some basic information about each
work package and its manager.
• Work package description report.
– a detailed description of the task plan.
Work Package Assignment Sheet
• is a report for the project manager only
• Task managers should be given only the
scheduled start and end dates for their tasks.
Work Package Description Report
• is a document prepared by the task manager in
which he or she describes the details of how he or
she will accomplish the work of the task.
• Not all tasks will require or should require work
package documentation.
• The documentation can be limited to critical path
tasks, near-critical path tasks, high-risk tasks, and
tasks that use very scarce or highly skilled staff.
Ch04: How to Plan a Project
Risk Management Life Cycle
risk identification
risk assessment
risk mitigation
risk monitoring &
control
Risk Management
Ch04: How to Plan a Project
Questions to be Answered by Your Risk Plan




What are the risks?
What is the probability that the risk will occur?
What might the losses be if the worst happens?
How can the losses be reduced?
Ch04: How to Plan a Project
Risk Categories

There are 4 basic industry accepted risk
categories defined by PMI:




Technical
Project Management
Organizational
External
Ch04: How to Plan a Project
Risk Category: Technical Risks



Includes quality and performance goals generally
relating to the technology of the project
Technology: suitability, reliability, and the
quality/performance standards surrounding the
technology.
Technology availability and complexity issues
Ch04: How to Plan a Project
Risk Category: Project Management Risks




Including poor allocation of the project’s resources
Inadequate project management structure – proper
planning processes to define critical deliverables for
each project phase
Inadequate planning, resource inexperience, poor use
of management disciplines
Cost and schedule risks due to the aforementioned
project management risks
Ch04: How to Plan a Project
Risk Category: Organizational Risks





Includes supportability risks, lack of prioritization of
projects
Inadequacy or interrupted funding, inadequacy or
interrupted resource assignment
Conflicts with other competing projects
Policies that do not support efficient management and
could also include supportability risks
Politics and agendas that impede the development of
the project's executing objectives
Ch04: How to Plan a Project
Risk Category: External Risks





Includes shifting legal or regulatory requirements
Supplier and contractor risks and contract issues
Economic collapse or work stoppages (strikes)
Programmatic or supportability risks caused by
external parties
Can also include deliverables from your teams that are
external to your own (IT or client)
Ch04: How to Plan a Project
Simplified Risk Matrix Tool
RISK
CATEGORIES
AND RISKS
SCOPE TRIANGLE ELEMENTS
Scope
Time
Cost
Quality
Resources
Technical
Project
Management
Organizational
External
Figure
04-23
Ch04: How to Plan a Project
Risk Identification - Candidate Risk Drivers
Prioritize (from A to J) the top ten risk drivers for your project.
____
____
____
____
____
____
____
____
____
____
____
____
____
Schedule is too aggressive
Overambitious performance
Too conservative a budget
Unrealistic expectations
Misunderstood contract terms
New/unfamiliar technology
Inadequate software sizing
Unsuitable development model
Unfamiliar new hardware
Poorly defined requirements
Frequent change requests
Poorly defined processes
Volatile business environment
____
____
____
____
____
____
____
____
____
____
____
____
Inadequately skilled personnel
Continuous requirements changes
Inadequate development plan
Unsuitable organizational structure
Testing facilities not available
Poor software engineering methods
Poor technology support
Lack of political support for project
Inconsistent client involvement
Loss of critical team member
Vendor/contractor relations
Market/competitor pressures
These are the conditions or situations that may
unfavorably affect project success.
Figure
04-24
Ch04: How to Plan a Project
Definition of Risk Assessment



Evaluating risks to assess the range of possible
outcomes.
To determine which events warrant response and more
importantly what type of response
Two factors are common


probability
severity (impact and/or loss)
Traditionally, this is the more difficult piece of formal risk
management…yet a defined and metric based approach
lessens the difficulty and subjectivity
Risk Assessment

If the probability is high and the impact is low, you may
be able to ignore the risk.

If the probability is low but the impact is high, you might
also be able to ignore the risk.

The decision is based on the product of the probability
of the event happening and the impact it will have.

For example, if the probability of losing a critical skill is
0.8 (probability is a number between 0 and 1.0) and
the impact is $50,000, the expected loss is $40,000
(0.8 × $50,000).
Risk Assessment

You should ignore the risk if the cost of avoiding the
risk is greater than the expected loss.

In other words, don’t solve a $100 problem with a
$1,000 solution.

In the two examples, you would most likely not ignore
the risk of losing the critical skill
Ch04: How to Plan a Project
Qualitative Risk Assessment - Risk Matrix
Probability
L
M
H
Ignore
L
Consider
Loss
M
Take Action
H
Static Risk Assessment
Figure
04-25
Dynamic Risk Assessment

In this approach, risk is continuously reassessed at
each phase of the project.

After the risk drivers have been identified, they must be
ranked from most likely to have an impact on the
project to least likely to have an impact on the project.

Label them A (most likely) through J (least likely) and
array the data
Ch04: How to Plan a Project
Quantitative Risk Assessment Worksheet
Column entries are1=low risk, 2=medium risk, and 3 = high risk
Figure
04-26
Quantitative Risk Assessment Worksheet…

In the example, the risk factor is 70 percent. This value
can be interpreted only in comparison to the risk factor
of completed projects.

There will be a pattern of project failures for projects
whose risk factor is above a certain number. If 70
percent is above that number, the example project is a
high risk for failure. The decision to do this project will
have to be offset by the business value the project
expects to contribute.
Ch04: How to Plan a Project
Risk Mitigation – Response Options

Accept - Do nothing because cure is more expensive than
risk consequences

Avoid - Elect to not do part of the project associated with
the risk (do risk/return analysis; revisit scope)

Contingency planning - Frame plans to deal with risk
consequence and monitor risk regularly (identify contingency
decision point)

Mitigate - Bring down risk probability by proactive
approaches (training, buy vs. build, etc.)

Transfer – e.g., outsource
Risk log

This document lists all risks that you want to manage and
describes what the risk is, who is supposed to manage the
risk, and what has been done to manage the risk event.

ID number— This always remains the same, even if the
risk event has occurred and been managed
Risk description— a short statement of the risk event.
Risk owner —the person who has the responsibility of
monitoring the status of the listed risk.
Action to be taken— Lists what the risk owner is going to
do to deal with the risk event.
Outcome — Describes what happened as a result of your
mitigation strategy




Ch04: How to Plan a Project
Risk Log Entry
ID #
Risk Description
P
I
Risk
Owner
Action to be
Taken
Outcome
Ch04: How to Plan a Project
Contents of the Project Proposal



Executive Summary: one page or a half page (2 minute speech)
Background: business conditions, opportunities, and problems
Objective: very general statement of what you hope to accomplish
through this project.


Overview of the approach to be taken
Detailed statement of work: : a high-level summary of what will
be done, when it will be done, who will do it, how much time will be
required, and what criteria will be used to measure completeness. (use
Gant Chart)
 Time and cost summary: a summary page of time and cost data

Appendices
The deliverable from all the planning activities in the JPPS is the
project proposal.
Ch04: How to Plan a Project
Gaining Approval to Launch the Project

The cost/benefit is not in your favor: trim the solution down
by eliminating functions with unfavorable cost-benefit ratios.

The risks of failure are too high: for example Replace new
technology with a more stable, well-known technology

The total project cost exceeds available funding:
trimming scope or decomposing the project into phases.

There are other projects competing for the same
resources.