Finalizing the Schedule and Cost Based on Resource Availability

1. Finalizing the Schedule and Cost Based onResource Availability Considering Resource Availability • determine if you can accomplish the schedule with the resources available

2. 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

3. 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.

4. 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).

5. Resource-Leveling Strategies You can use three approaches to level project resources: • Utilizing available slack • Shifting the project finish date • Smoothing

6. 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.

7. 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.

8. 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.

9. 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

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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

17. 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.

19. 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.

20. 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).

21. 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.

22. 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.

24. 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.

26. Ch04: How to Plan a Project Risk Management Life Cycle risk identification risk assessment Risk Management risk mitigation risk monitoring & control

27. 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?

28. Ch04: How to Plan a Project Risk Categories • There are 4 basic industry accepted risk categories defined by PMI: • Technical • Project Management • Organizational • External

29. 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

30. 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

31. 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

32. 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)

33. Ch04: How to Plan a Project Simplified Risk Matrix Tool Figure 04-23

34. 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

35. 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

36. 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).

37. 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

38. Ch04: How to Plan a Project Qualitative Risk Assessment - Risk Matrix Static Risk Assessment Figure 04-25

39. 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

40. 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

41. 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.

42. 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

43. 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

44. ID # Risk Description Risk Owner P I Action to be Taken Outcome Ch04: How to Plan a Project Risk Log Entry

45. 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.

46. 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.