1 PROJECT SCHEDULING LECTURE NOTES. 2 PROJECT SCHEDULING Software Project Scheduling is an activity...

1

PROJECT SCHEDULING

LECTURE NOTES

2

PROJECT SCHEDULING

Software Project Scheduling is an activity that distributes Estimated Effort across the Planned Project Duration by allocating the Effort to specific Software Engineering Task.

Project Scheduling is the culmination of a Project Planning activity that is a primary component of Software Project Management.

Project Scheduling establishes a “Road Map” for the Project Manager When combined with Estimation Methods and Risk Analysis.

3

PROJECT SCHEDULING

Scheduling begins with Process Decompositions. The characteristics of the Project are used to adapt an appropriate task set for the Work to be done.

A Task Network depicts each engineering task, its dependency on other tasks and its projected duration.

The Task Network is used to compute the Critical Path, a Timeline Chart and a variety of project information.

Using the Project Schedule as a guide, the Project Manager can track and control each step in the Software process.

4

BASIC SCHEDULING CONCEPT

The reasons for Software Project failure or late delivery has been mentioned inthe “Project Management” chapter earlier on. Such causes can be summarizedas follows:

WHY SOFTWARE IS DELIVERED LATE?

Most late delivery can be traced to one or more of the following root causes:

1. An unrealistic deadlines established by someone outside The Software Engineering group, and forced on Managers and Software practitioners within the group.2. Changing Customer Requirements that are not reflected in Schedule changes.3. An unhonest underestimate of the amount of effort and / or the number of resources that will be required to do the job.4. Predictable and/or unpredictable risk, that were not considered when the project commenced.5. Technical difficulties that could not have been foreseen in advance.6. Miscommunication among project staff that results in delay.7. A failure by project Management to recognize that the project is falling behind the Schedule and a lack of action to correct the problem.

5


UNREALISTIC OR UNDERESTIMATED DEADLINES

Assume that a Software Engineering team has been asked to build a Real time System that is to be introduced in the Market in nine months. After Careful Estimation and Risk Analysis the Project Manager comes to the conclusion that the Software will receive 14 months to be developed with available staff.

HOW SHOULD A PROJECT MANAGER PROCEED IF DEADLINE IS UNDERESTIMATED?

- First of all it is unrealistic to march into the customer’s office and demand that the “Delivery Date” be changed. Since the external Market pressure has dictated the date and that the product must be releases.

- Secondly, It is equally fool-hardy to refuse undertake (accept) the work from a career stand point. So what to do?

6


The following steps are recommended for Underestimated Deadlines:-

1. Perform a detailed Estimate using historical data from past projects. Determine the estimated effort and duration for the project.

2. Using an Incremental Process Model, develop a Software Engineering Strategy that will deliver ‘’Critical functionality’’ by the imposed deadline, but delay other functionality until later and Document the Plan.

3. Meet Customer with the Project Plan, explain Why the imposed deadline is unrealistic. Be certain to note that Estimates are based on performance on past projects. Also be certain to indicate the percent improvement that would be required to archive the deadline as it currently exists.4. Offer the Incremental Development Strategy as an alternative

The Options open to the Project Manager to propose are:-

a) Increase of Budget and buying additional Resources so that you can get the job done in 9 months as required.

b) Propose a reduction in Project Scope in the First Project phase, so that you can deliver the “Core System Functions” in 9 months and then at Phase 2 you can deliver the other secondary functions at the end of 14 months.

c) Dispense with reality and Wish that the project complete in 9 months (Believe a Software Myth). In which we will not be able to deliver anything to customer.

7

PROJECT SCHEDULING

The reality of a Technical Project is that hundreds of small tasks mustoccur in order to accomplish a large goal. Some of these tasks lie outside the main stream and may be completed without worry abut impact OnProject Completion Date.

Other tasks lie on the “Critical Path”. These tasks are called “Critical Tasks” fall behind schedule the completion date on the entireproject is put into jeopardy.

The Project Managers Objectives with regards to Project Scheduling are:

1. Define all Tasks.

2. Build a Network that depicts that’s dependencies.

3. Identify the tasks that are Critical within the Network.

4. Track task progress to ensure that delay is recognized. “ One Day at a time “.

8

EVOLUTION OF PROJECT SCHEDULES

It is important to note that the a Project Schedule evolves Over the time. During early stages of Project Planning, a Macroscopic Schedule is developed. Thistype of Schedule identifies all major Process Framework activities and the Productfunctions to which they are applied.

As the project gets underway, each entry on the Macroscopic Schedule is refinedinto a Detailed Schedule, where specific Software tasks are identified and Scheduled.

Scheduling for Software Engineering Projects can be viewed from two rather different Perspectives :-

1. An End-date for release of Computer-based System has already been established (irrevocable End-date). The Software organization is constrained to distribute Effort within the prescribed Time frame.

2. Rough chronological bounds have been discussed but that the End-date is set by the Software Engineering Organization. Effort is distributed to make best

use of Resources and the End-date is defined after careful analysis of the Software.

Unfortunately the first situation is encountered for more frequently than the second one.

9

BASIC PRINCIPLES OF SCHEDULING

A number of Basic Principles guide Software Project Scheduling:-

Compartmentalization Interdependency Time Allocation Effort Validation Defined Responsibilities Defined Outcomes Defined Milestones

10

THE RELATIONSHIP BETWEEN PEOPLE AND EFFORT

In a small Software Development Project a Single Person can Analyze Requirements, Perform Design, Generate codes and Conduct Tests. As the Size of Project increases, more people mustbecome involved because no company afford the luxury of a 10 man year effort with one personworking on it for 10 years).

There is a common myth that is still believed by many Managers who are responsible forSoftware – ‘’I f we fall behind Schedule, we can always add more Programmers and catch up

later in the Project.”

Unfortunately, adding people late in a Project has a two destructive effects on the Project,causing Schedules to skip even further.

a) The People who are added must learn the System and the People who teach them are the same people who are doing the work. Therefore, during teaching no work is done, and the Project falls further behind. b) More people increase the number of communication paths and the complexity of communication through additional time.

Over the years Empirical Data and Theoretical Analysis have demonstrated that Project Schedules are ‘’Elastic’’ since it is possible to compress a desired Project’s Completion date byadding additional resources to some extent.

It is also possible to extend a Completion date (by reducing the number of Resources).

11

THE PUTNAM- NORDEN- RAYLEIGH CURVE (PNR CURVE)

PNR Curve provides an indication of the relationship between Effort applies and Delivery Time for a Software Project.

Imp

ossi

ble

Reg

ion

E0

Ed

TMIN=0.75 Td

t d t 0 (2td)DEVELOPMENT TIME MAN/YEAR

E0 = m ( td4/ta

4 )

EFFORTCOST $

E0 = m ( td4 / ta

4 )

Where; E0 = Effort in Person-months

td = Nominal Delivery time for schedule

t0 = Optimal Development time (in Cost)

ta = Actual Delivery time desired.

12

PNR EXAMPLE:

Assume that a Project team has estimated a Level of Effort (Ea), that will be required to achieve a Nominal Delivery Time (td), that is Optimal in terms of Schedule and Available Resources.

Although it is possible to accelerate Delivery, the Curve rises very properly to the left of t(d). In fact, the PNR Curve indicates that the Project Delivery time cannot be compressed much beyond 0.75(td) .

If we attempt to further Compress, the Project moves into the “Impossible Region”, and risk of failure becomes Very high.

The PNR curve also indicates that the lowest Cost Delivery option (t0) = 2td.

The implication here is that Delaying Project Delivery can reduce Costs; Of course this must be weighted against the Business Costs associated with delay.

The number of Source Statement or Delivery Lines of Code (L) is related to Effort and Development Time by the equation. 1/3 4/3

L = (P * E t )

Where, E = Development Effort (Person-months). P = Productivity Parameter (Reflects a variety of factors that lead to high quality Software Engineering work.)

Typical Values for P = Ranges between 2000 - 12000. t = is the Project Duration in Calendar Months.

13

Rearranging this Software Equation we can assume that an expression for Development effort. 3 3 4

E = L / (P * t )

where E = Effort expanded in Person-Years over Development and Maintenance. t = Development Time in Person - years.

This leads to some interesting results.

Let us Consider a complex Real-time Software Project estimated at 33.000 LOC.

- Estimated Line of Code 33,000. - 12 Person - years of Effort. - Assigned 8 people Project team.

The Project can be completed in approx 1.3 Person -Years.

If however, we extend the End-Date to 1.75 Person - years, the highly nonlinear nature of the model yields. 3 3 4

E = L /(P * t ) = ~3.8 yearsThis implies that extending the End-date for six months, we can reduce the Number of people from Eight to Four.

Benefits can be gained by using fewer people over a somewhat longer time span to accomplish the same objective

14

EFFORT DISTRIBUTION

The Software Project Estimation techniques leads to Estimate of Work Unit (e.g. person-month) required to complete Software development.

A recommended Distribution of Effort across the Software Process is often referred to as 40-20-40 % Rule.

- 40% of all Effort is allocated to Project front-end Analysis and Design phases

- 20% for coding (construction phase)

- 40% is applied to back-end Testing Phase

The Effort Distribution Rule should be used as a guideline only.

15

The Characteristic of each Project must dictate the Distribution of Effort.

• Work Expended on Project Planning rarely accounts for more than 2 -3 % of Effort, unless the Plan commits to large expenditures with high risk.

Requirements Analysis may consume 10-25 % of Project Efforts.

Analysis of Prototyping should increase in direct proportion with Project Size and Project Complexity.

A range of 20-25% of Effort is normally applied to Software Design.

Testing and subsequent Debugging can account for 30-40 % of Development Effort. (The criticality of Software dictates the amount of testing that is required. If software is human life related the Testing rate will be even higher).

16

CRITICS FOR 40 - 20 - 40 RULE

The 40-20-40 Rule is under attack since some Software Engineering Managers believe that More than 40% of overall Effort should be expended during Analysis and Design.

Some proponents of Agile Development Method argue that Less time should be expended on “Front-end’’ of Project Phase and that a team should move quickly to Construction Phase (Build phase).

17

DEFINING A TASK SET FOR THE SOFTWARE PROJECT

To develop a Project Schedule a Task Set must be distributed on the Project Timeline.

The Task Set will vary depending upon the Project Type and the degree of rigor with which the Software Team decides to do its work.

Although it is difficult to develop a comprehensive Taxonomy of SoftwareProject types, most Software organizations encountered the following ProjectsTypes:-

1. CONCEPT DEVELOPMENT PROJECTS.(PILOT PROJECT)

Initiated to explore some New Business concept of Application or some new Technology. ( When the potential for some new Technology must be explored)

2. NEW APPLICATION DEVELOPMENT PROJECTS

Projects undertaken as a consequence of a specific customer request.

18


3. APPLICATION ENHANCEMENT PROJECTS

Occur when Existing Software Undergoes major modifications to function, Performance on interfaces that an observable by the end-user.

4. APPLICATION MAINTENANCE PROJECTS

That connect, adapt or extend Existing Software on ways that may not be immediately obvious to the end-user.

5. REENGINEERING PROJECTS

Project undertaken with the intent of rebuilding an Existing System in whole or part. Even within a single Project type, many factors influence the Task set to be chosen.

19


The factors that influences the Task Set selection include :

- Size of the Project- No. Of potential users- Mission Criticality- Application longevity- Stability of requirements- Ease of customer/developer communication- Maturity of applicable technology- Performance consideration - Embedded/non embedded characteristics- Project Staff- Re-engineering factors

When taken in combination, these factors provide an indication of the

Degree of rigor with which the Software Process should be applied.

20


AN EXAMPLE TASK SET

Some Major Task set that can be considered in a Concept Development Project are :

1.1 CONCEPT SCOPING1.2 PRELIMINARY CONCEPT PLANNING1.3 TECHNOLOGY RISK ASSESSMENT1.4 PROOF OF CONCEPT1.5 CONCEPT IMPLEMENTATION1.6 CUSTOMER REACTION

These Major Tasks may be used to define a Macroscopic Schedule for a Project.

However the macroscopic Schedule must be refined to create a Detailed Project Schedule.

Requirement begins by taking each Major Task and decomposing it into a setof subtasks with related Work Products and Milestones

21


An Example of Task Decomposition

Consider decomposition of Major Task 1 (CONCEPT SCOPING)

TASK 1. CONCEPT SCOPING 1 .1. IDENTIFY NEED BENEFITS AND POTENTIAL CUSTOMER 1. 2 DEFINE DESIRED OUTPUT/CONTROL AND INPUT EVENTS

1..3 REVIEW WRITTEN DESCRIPTION OF NEED .........................

1.3.1 DEFINE THE FUNCTIONALITY/BEHAVIOR OF EACH MAJOR FUNCTION

1.3.2 REVIEW OUTPUT/INPUT OBJECTIVES

2. PRELIMINARY INVESTIGATION . etc…..

The Tasks and Sub-tasks form the basis for a Detailed Schedule for the Concept Scoping Activity.

22

DEFINING A TASK NETWORK

Individual Tasks and subtasks have ‘Interdependencies’ based on their sequence.

In addition, when more than one person is involved in a Software Engineering Project it is likely that development activities and Tasks will be performed in Parallel. When this occurs, Concurrent tasks must be coordinated so that they will be Complete when Later Tasks require their Work products.

A TASK NETWORK, also called ‘’Activity Network’’, is a graphical representation of the Task flow for a Project.

It is sometimes used as the mechanism through which Task sequence and dependencies are input to an automated Project Scheduling tool.

23

DEFINING A TASK NETWORK

The concurrent nature of Software Engineering activities leads to a number ofimportant Scheduling requirements.

Because parallel tasks occur asynchronously the Project Planner mustdetermine ‘Inter- task Dependencies’ to ensure continuous progress towardcompletion.

In addition, the Project Manager should be aware of Critical Tasks which arethose Tasks that lie on the Critical Path.

Critical Tasks must be completed on time if the Project as a whole is to becompleted on Schedule.

Interdependencies among Tasks may be defined using a Task Network.

24

PROJECT SCHEDULING METHODS

Scheduling of a Software Project does not differ greatly from Scheduling of any multitask Engineering effort. Therefore, generalized project Schedulingtools and techniques can be applied with little modification for SoftwareProjects.

PERT (Program (Project) Evaluation and Review Technique) and the CPM (Critical Path Method are two Project Scheduling Methods that can be applied to Software development.

Both techniques are driven by information already developed in early ProjectPlanning activities such as:-

- Estimates of Effort- A decomposition of Product function- Selection of the appropriate Process Model and task set- Decomposition of Tasks

25

PROJECT SCHEDULING METHODS

Tasks sometimes called the Project Work Breakdown Structure (WBS), aredefined for the Product as a whole or for individual function.

Both PERT and CPM provide Quantitative Tools that allow the SoftwarePlanner to:

a) Determine the Critical Pathb) Establish “Most Likely” Time Estimates for individual tasksc) Calculate “Boundary times” that define a time Window for a

particular task.

26

Work BreakedownStructure (WBS)

27

REPRESENTING & SCHEDULING PROJECT PLANS

The Most commonly used methods are :-

• GANTT CHART

• NETWORK DIAGRAMS (PERT CHART)

28

GANTT CHART

• A graphical representation of a Project that shows each task as a horizontal bar whose length is proportional to its time for completion.

• A GANTT Chart is a horizontal bar chart that illustrates a Project schedule.

• In the GANTT Chart Time is displayed on the horizontal axis and the Tasks/ Activities are arranged vertically from top to bottom, in order of their start dates.

• A detailed GANTT Chart for a large project might be quite complex and hard to understand. To simplify the chart Project manager can combine related activities into one Task.

29

GANTT CHART• A graphical representation of a Project that

shows each task as a horizontal bar whose length s proportional to its time for completion.

• GANTT CHART do not show how tasks must be ordered (precedence) but simply show when a task should begin and should end

• GANTT Chart is often more useful to for depicting relatively simple projects or sub projects of a large project, the activities of a single worker, or for monitoring the progress of activities compared to scheduled completion dates..

30

GANTT CHART

31

NETWORK DIAGRAM

PROJECT EVALUATION AND REVIEW TECHNIQUE (PERT)

• PERT Is a graphical depiction of Project tasks and their inter-relationships.

• The distinguishing feature of a Network Diagram is that the ordering of Tasks is shown by connecting with its Predecessor and Successor tasks.

• Network Diagramming is a Critical Path Scheduling Technique used for controlling Resources.

• CRITICAL PATH SCHEDULING A scheduling technique whose order and duration of a

sequence of task activities directly affect the Completion Date of a Project

32

PERT CHART

You would use a Network Diagram when Project Tasks:-

– Are well defined and have clear beginning and end point

– Can be worked on independently of other tasks

– Are ordered

– Serve the purpose of project

33

PERT CHART

• One of the most difficult and most error prone activities when constructing a Project Schedule is the determination of the TIME DURATION for each task within a Work Breakdown Structure (WBS), specially when there is a high degree of complexity and uncertainty about a task.

• PERT is a technique used to calculate the Expected Duration for a tasks.

• PERT is a technique that uses Estimates for:• Optimistic time (O), • Pessimistic time (P) • Realistic Time (R)

• To calculate the EXPECTED DURATION (ED) of a particular task.

34

PROGRAM EVALUATION REVIEW TECHNIQUE (PERT)

• PERT is a technique that uses Optimistic time (O), Pessimistic time (P) and Realistic Time (R) estimates to calculate the EXPECTED Duration (ED) of a particular task.

• The Optimistic time (O) and Pessimistic time (P) reflects the minimum and maximum possible periods of time for an activity to be completed.

• The Realistic time (R) or the Most likely time , reflects the Project Manager’s “Best Guess” of the amount of time required for a task completion.

35

PROGRAM EVALUATION REVIEW TECHNIQUE (PERT)

CALCULATING EXPECTED COMPLETION TIME (ET)

ED = [O + (4* R) + P] / 6

Because the Expected Duration should be closer to the Realistic Time (R), it is typically weighed Four times more than the Optimistic time (O) and the Pessimistic time (P).

Once you add these values together , it must be divided by 6 to determine the Expected Duration for a task.

36

HOW TO CONSTRUCT A NETWORK DIAGRAM (PERT CHART)

DEVELOPING A NETWORK DOAGRAM IS A FOUR STEP PROCESS:-

1. Identify each Project Task to be completed

2. Determine Time Estimates and calculate Expected Duration for each Activity

3. For each Task, identify the immediate Predecessor Tasks

4. Enter the Task with connecting Arrows based on Dependencies and calculate Start and End-Times based on Duration and Resources.

37

PERT CHART SYMBOLS

PERT Chart is consisted of TASKS and EVENTS.

An EVENT is called a Milestone, representing a point in time, such as the Start or Completion of a Task.

A circle or a Rectangle shape NODE is used to represent an EVENT.

Event ID ECT (Earlier Completion Time)

LCT (Latest Completion Time)

Every PERT Chart has one Beginning and one End NODE that represents theStart and Finish of a Project.

The Earliest and Latest Completion Time is both Zero in Starting Event. Task ID

A TASK is depicted by an ARROW Connecting Events. A Dashed Arrow represents a DUMMY TASK which is the dependency betweentwo Events without requiring any resource (Duration is zero).

38

SLACK TIME:-

The Slack Time available for any Task is equal to the difference between theEarliest Completion Time (ECT) and the Latest Completion Time (LCT)

SLACK TIME = (LCT – ECT)

CRITICAL PATH

Is a sequence of Dependent Tasks that have the Largest sum of EstimatedDURATION (ed) .

Critical Path is the Path that has no Slack Time built in.

– The Critical Path on PERT chart is shown with thick Dark line.

To find the Critical Path begin with identifying all alternative Paths thatexist from First Event to the Final Event on the PERT Chart.

40

PERT CHART

A PERT CHART EXAMPLE

A Project Planning Table is used to draw a PERT Chart.

The Project Planning Table is created from the Project Work BreakdownStructures (WPDS) Table, with some additional Project information suchAs:-

• Expected Duration (calculated using Three point Estimation Equation)• Preceding Event, • Succeeding Event, • Earliest Completion Time / Date (ECT)• Latest Completion Time / Date (LCT)

41

PROJECT PLANNING TABLE

TASK TASK EVENT PROCEEDING SUCCEDING EXPECTED ECT LCT

ID DESCRIPTION ID EVENT EVENT DURATION

A 2 1 3 3 3 3

B 3 2 4 2 5 5

C 4 3 5,6,7,8 2 7 7

D 5 4 8 7 14 14

E 6 4 8 6 13 14

F 7 5 8 3 10 14

G 8 4,5,6,7 9 2 14 14

H 9 8 NONE 5 19 19

42

A PROJECT PLANNING TECHNIQUE

PERT CHART

0

EVENT ID NO.

ECT

LCT

TASK ID

Expected TimeDummy TASk

0

0

A

3

2

3

3

B

2

c2

2

3

0

0

5

H3

5

5

4

7

7

D

5

14

14

E

66

13

14

14

148 9

19

19

G

2

7

10

14

CRITICAL PATH :- (A+B+C+D+DUMMY+H) = 19 DAYS PATH 1 IS CRITICAL PATH

CRITICAL PATH = (A + B + C + D + DUMMY TASK + H) (3 + 2 + 2 + 7 + 0 + 5 ) = 19 Person - day

43

GANTT CHART vs PERT CHART

• GANTT Chart visually shows the Duration of Tasks; whereas a PERT Chart visually shows the Sequence dependencies between tasks.

• GANTT Chart visually shows the Time Overlap of Tasks; whereas a PERT Chart does not show time overlap but does show which Tasks could be done in parallel.

• Some form of GANTT Chart can visually show Slack Time available within an Earliest Start Time and Latest Finish (Completion) Time..

• Giving that all Software Project have some Intertask Dependency as well as offering opportunities for Task Overlapping, PERT and GANTT Charts should not be considered as alternative Project Management approaches but rather Complementary techniques for Project planning, Scheduling, Evaluation and Control of Software Project development.

• PERT Chart is recommended for Large Projects with high ‘’Inter-task Dependencies’’ and the GANTT chart for simpler Projects.

44

GANTT CHART vs PERT CHART

• Most Project Managers find PERT Chart very helpful for Scheduling,

Monitoring and Controlling Projects.

• However, still most Software Project Managers seem to prefer GANTT Chart because of its simplicity and ability to produce various levels of Project Schedules (ie. Project Schedules for individual resorce etc.) as well as easyness of Reporting Project progress to all concerns.

• Most Project Planning CASE tools allow GANTT Chart to be temporarly displayed as PERT Chart for a different prespective.

• Microsoft Project CASE tool is a typical example that works this way.

45

GANTT CHART v.s PERT CHART

46

EARNED VALUE ANALYSIS (EVA)

47

EARNED VALUE ANALYSIS

Earned Value Analysis is a Quantitative technique for assessing progress as the software Project team moves through the work tasks allocated to the Project Schedule

• Provides a common value scale for every project task

• Total Hours to do the Project are estimated, and every task is given an Earned Value based on its Estimated (%) of Total .

• Earned Value is a measure of ‘’Progress’’ to assess ‘’Percentage of Completeness’’

48


STEPS IN DETERMINING EVA

1. The Budgeted Cost of Work Schedule (BCWS) for each task determined in Person-hours during estimation.

2. The BCWS value for all work tasks are summed to derive the ‘’Project Budget At Completion’’ (BAC)

BAC = ∑ (BCWS )

49


STEPS IN DETERMINING (EVA)

3. Compute Budgeted Cost of Work Performed (BCWP)

BCWP = ∑ (BCWS)

• BCWP is the sum of BCWS for all work tasks has actually been completed by a point in time on the project Schedule.)

• BCWS represents the Budget of Activities that were Planned to be Completed.

• BCWP represents the Budget of Activities that were actually completed.

50



Given Value for BCWS, BAC and BCWP important Progress Indicators

can be computed.

SHEDULED PERFORMANCE INDEX (SPI)

SPI = (BCWP / BCWS)

SPI is an Indication of the Efficiency with which the Project is utilizing

Scheduled resources.

SPI close to (1.0) indicates efficient execution of the Project Schedules.

51


Given Value for BCWS, BAC and BCWP important Progress

Indicators can be computed.

SCHEDULED VARIANCE INDEX

S VI = (BCWP - BCWS)

SVI is simply an absolute Indication of variance from the

Planned Schedule .

52


PERCENT SCHEDULED FOR COMPLETION

PERCENT SCHEDULED FOR COMPLETION = (BCWS / BAC)

This Indicator shows the Percentage of work that should have been completed by a certain time .

PERCENTAGE COMPLETE INDICATOR Percent Completed = (BCWP / BAC)

Provides a quantitative Indication of the Percentage of Completeness of the Project at a given point in time.

53


ACTUAL COST OF WORK PERFORMED INDICATOR

ACWP = ∑ (Actual Work expended on each Task)

The value of ACWP is the sum of the Effort Actually expended on a work tasks that have been completed by a point in time on the Project Schedule.

COST PERFORMANCE INDEX (CPI) CPI = (BCWP / ACWP)CPI value close to 1.0 provides a strong Indication that the Project is within its defined Budget.

54


COST VARIANCE INDICATOR (CV)

CV = (BCWP - ACWP)

CV is an absolute Indication of Cost Saving (against Planned Cost) or Shortfall at a particular stage of a Project

• EARNED VALUE ANALYSIS illuminates Scheduling difficulties before they might be apparent.

• EVA enables Project Manager to take corrective action before a Project crisis developed.

1 PROJECT SCHEDULING LECTURE NOTES. 2 PROJECT SCHEDULING Software Project Scheduling is an activity...

Documents

Transcript of 1 PROJECT SCHEDULING LECTURE NOTES. 2 PROJECT SCHEDULING Software Project Scheduling is an activity...