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 in
the “Project Management” chapter earlier on. Such causes can be summarized
as follows:
WHY SOFTWARE IS DELIVERED LATE?
Most late delivery can be traced to one or more of the following root causes:
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. BASIC SCHEDULING CONCEPT
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. BASIC SCHEDULING CONCEPT
The following steps are recommended for Underestimated Deadlines:-
Perform a detailed Estimate using historical data from past projects. Determine the estimated effort and duration for the project.
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 must
occur in order to accomplish a large goal. Some of these tasks lie outside
the main stream and may be completed without worry abut impact On
Project Completion Date.
Other tasks lie on the “Critical Path”. These tasks are called
“Critical Tasks” fall behind schedule the completion date on the entire
project 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. This
type of Schedule identifies all major Process Framework activities and the Product
functions to which they are applied.
As the project gets underway, each entry on the Macroscopic Schedule is refined
into a Detailed Schedule, where specific Software tasks are identified and Scheduled.
Scheduling for Software Engineering Projects can be viewed from two rather
different Perspectives : 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 must
become involved because no company afford the luxury of a 10 man year effort with one person
working on it for 10 years).
There is a common myth that is still believed by many Managers who are responsible for
Software –
‘’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 by
adding 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.
Impossible
Region E0 Ed
TMIN=0.75 Td
t d
t 0 (2td)
DEVELOPMENT TIME
MAN/YEAR
E0 = m ( td4/ta4 )
EFFORT
COST $
E0 = m ( td4 / ta4 )
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 / /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
t = is the Project Duration in Calendar Months.

13. Rearranging this Software Equation we can assume that an expression for
Development effort.
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 LOC.
- Estimated Line of Code 33,000.
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 Person - years, the highly nonlinear nature of the model yields
E = L /(P * t ) = ~3.8 years This 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 % Rule % of all Effort is allocated to Project front-end Analysis and Design phases % for coding (construction phase) % 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 % 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 % 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 RULE
The 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 Software
Project types, most Software organizations encountered the following Projects
Types:-
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. DEFINING A TASK SET FOR THE SOFTWARE PROJECT
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 :
DEFINING A TASK SET FOR THE SOFTWARE PROJECT
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. DEFINING A TASK SET FOR THE SOFTWARE PROJECT
AN EXAMPLE TASK SET
Some Major Task set that can be considered in a Concept Development Project are :
1.1 CONCEPT SCOPING
1.2 PRELIMINARY CONCEPT PLANNING
1.3 TECHNOLOGY RISK ASSESSMENT
1.4 PROOF OF CONCEPT
1.5 CONCEPT IMPLEMENTATION
1.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 set
of subtasks with related Work Products and Milestones

21. An Example of Task Decomposition
DEFINING A TASK SET FOR THE SOFTWARE PROJECT
An Example of Task Decomposition
Consider decomposition of Major Task 1 (CONCEPT SCOPING)
TASK CONCEPT SCOPING
IDENTIFY NEED BENEFITS AND POTENTIAL CUSTOMER
1. 2 DEFINE DESIRED OUTPUT/CONTROL AND INPUT EVENTS
1..3 REVIEW WRITTEN DESCRIPTION OF NEED
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 of
important Scheduling requirements.
Because parallel tasks occur asynchronously the Project Planner must
determine ‘Inter- task Dependencies’ to ensure continuous progress toward
completion.
In addition, the Project Manager should be aware of Critical Tasks which are
those Tasks that lie on the Critical Path.
Critical Tasks must be completed on time if the Project as a whole is to be
completed 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 Scheduling
tools and techniques can be applied with little modification for Software
Projects.
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 Project
Planning 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), are
defined for the Product as a whole or for individual function.
Both PERT and CPM provide Quantitative Tools that allow the Software
Planner to:
a) Determine the Critical Path
b) Establish “Most Likely” Time Estimates for individual tasks
c) 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:-
Identify each Project Task to be completed
Determine Time Estimates and calculate Expected Duration for each Activity
For each Task, identify the immediate Predecessor Tasks
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 the
Start 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 between
two Events without requiring any resource (Duration is zero).

38. SLACK TIME:- CRITICAL PATH
The Slack Time available for any Task is equal to the difference between the
Earliest 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 Estimated
DURATION (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 that
exist 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 Breakdown
Structures (WPDS) Table, with some additional Project information such
As:-
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
EVENT
PROCEEDING
SUCCEDING
EXPECTED
ECT
LCT ID
DESCRIPTION
DURATION A 2 1 3 B 4 5 C
5,6,7,8 7 D 8 14 E 6 13 F 10 G
4,5,6,7 9 H
NONE 19

42. A PROJECT PLANNING TECHNIQUE
CRITICAL PATH = (A + B + C + D + DUMMY TASK + H)
( ) = 19 Person - day
A PROJECT PLANNING TECHNIQUE

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 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’’
EARNED VALUE ANALYSIS

48. EARNED VALUE ANALYSIS (EVA)
STEPS IN DETERMINING EVA
The Budgeted Cost of Work Schedule (BCWS) for each task determined in Person-hours during estimation.
The BCWS value for all work tasks are summed to derive the ‘’Project Budget At Completion’’ (BAC)
BAC = ∑ (BCWS )

49. EARNED VALUE ANALYSIS (EVA)
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. EARNED VALUE ANALYSIS (EVA)
STEPS IN DETERMINING (EVA)
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. STEPS IN DETERMINING (EVA)
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. EARNED VALUE ANALYSIS (EVA)
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. EARNED VALUE ANALYSIS (EVA)
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. EARNED VALUE ANALYSIS (EVA)
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.