Determine if you can accomplish the schedule with the resources available Considering Resource Availability Finalizing the Schedule and Cost Based on Resource

• determine if you can accomplish the schedule with the resources available

Considering Resource Availability

Finalizing the Schedule and Cost Based onResource Availability

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 ES-LF

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 lowest-level 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 non-workdays 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.

Risk Management Life Cycle

risk identification

risk assessment

risk mitigation

Risk Management

risk monitoring & control

Ch04: How to Plan a Project

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?

Questions to be Answered by Your Risk Plan


There are 4 basic industry accepted risk categories defined by PMI: Technical Project Management Organizational External

Risk Categories


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

Risk Category: Technical 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

Risk Category: Project Management 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

Risk Category: Organizational 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)

Risk Category: External Risks


Simplified Risk Matrix Tool

RISK CATEGORIES AND RISKS

SCOPE TRIANGLE ELEMENTS

Scope Time Cost Quality Resources

Technical

Project Management

Organizational

External

Figure04-23


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

Figure04-24


These are the conditions or situations that may unfavorably affect project success.

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)

Definition of Risk Assessment

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

Qualitative Risk Assessment - Risk Matrix

Probability

Loss

L

L

M

M H

H

Ignore

Consider

Take Action

Figure04-25


Static Risk Assessment

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

Quantitative Risk Assessment Worksheet

Figure04-26


Column entries are1=low risk, 2=medium risk, and 3 = high risk

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.

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 Mitigation – Response Options


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

Risk Log Entry

ID # Risk Description Risk Owner

Action to be Taken

Outcome

P

I


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

Contents of the Project Proposal


The deliverable from all the planning activities in the JPPS is the project proposal.

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.

Gaining Approval to Launch the Project


Documents

Determine if you can accomplish the schedule with the resources available Considering Resource Availability Finalizing the Schedule and Cost Based on Resource