Project Duration Estimation

of 16
Software Project Planning and Management (CAP 590)
Term Paper: - Project Duration Estimation
Synopsis By: - Harsh Behl Submitted To- Sahil Rampal
11100961
RD1102A27
Date: - 07 April 2014

of 16
Index Page no
1. Introduction 3
2. Technique’s Which Are 4
Used to Estimate Project Duration
3.Top Down Approach 4-5
4.Bottom Down Approach 5-7
5. Expert Judgments 7
6.Historical comparison 7
7.Functional Points 7-8
8.Object points 8-10
9.CPM (Critical path method) 10-12
10. Pert 12-15
11. Conclusion 15
12. Bibliography 16

of 16
Introduction
As we all know that estimating the activity duration is very important to
the success of any Software project. Like me and my team will estimate
the various requirements of cost, time, and resources throughout in our
project. As we look upon the activity duration estimation looks at the
time it takes to complete the entire project, activity duration estimation
is dependent on other time and resource estimates also.
We might start on these estimates at the Starting of our project, but we
make the most of the estimates during the planning period.
Estimates are never exact these are just guesses by the whole team. But
we can improve our accuracy by dividing the estimation task into three
distinct steps: determining a Work Breakdown Structure (WBS),
estimating the amount of work and duration of work packages, and
calculating the project schedule.
Technique’s Which Are Used to Estimate Project Duration
We can choose from many other methods, however, if neither CPM nor
PERT meets our needs. Other estimating methods include:
 Bottom-up
 Expert judgment
 Function point
 Historical comparison
 Top-down
 Objects point

of 16
Out of all these methods I will discuss CPM and Pert in detail rest I will
discuss briefly.
So I am discussing each of them one by one…
Top Down Approach
As we all know that the effort for a project is a function of many
parameters. And the main factor which determine the effort for the project
is basically the size of the project. That is if we have larger project the
greater is the effort requirement and greater is the project duration. So top
down approach basically takes effort as a function of project size and it is
important to note down that to apply this function we first have to
determine the size of the project for which effort has to be estimated and
project duration is to be estimated.
If the past productivity for similar projects is known than we can use them
to determine the effort and time duration from the size.
A more general function for determining effort from size that is
commonly used is of the form:
EFFORT = a * SIZEb
,
where a and b are constants, and project size is generally in KLOC (size
could also be in another size measure called function points which can be
determined from requirements). Values for these constants for an
organization are determined through regression analysis, which is applied
to data about the projects that have been performed in the past. For
example, Harsh and Vinod analyzed the data of more than 60 projects
done at LPU InfoTech Division, ranging from 4000 to 467,000 lines of
delivered source code, and found that if the SIZE estimate is in thousands
of delivered lines of code (KLOC), the total effort, E, in person-months
(PM) can be given by the equation E = 5.2(SIZE).91.
It should be noted that to use the top-down approach for estimation, even
if we have a suitable function, we need to have an estimate of the project
size. In other words, we have replaced the problem of effort estimation by
size estimation because size estimation is often easier than direct effort

of 16
estimation. This is mainly due to the fact that the system size can be
estimated from the sizes of its components by adding the size estimates of
all the components. Similar property does not hold for effort estimation,
as effort for developing a system is not the sum of effort for developing
the components as additional effort is needed for integration and other
such activities when building a system from developed components.
Clearly for top-down estimation to work well, it is important that good
estimates for the size of the software be obtained. There is no known
simple method for estimating the size and duration accurately. When
estimating software size, the best way may be to get as much detail as
possible about the software to be developed and to be aware of our biases
when estimating the size of the various components. By obtaining details
and using them for size estimation, the estimates are likely to be closer to
the actual size and duration for the final software.
Bottom up Approach
This approach works in this way that the people who are going to do
work in the project work will participate in estimation process. The team
is basically the project team members and project manager who will
develop estimating data the lowest level in the work breakdown
structure Bottom-up estimating is where the people who were going to
do the work participate in the estimating process. When the estimates of
work, duration and cost are set at that level they are aggregated upward
into estimates of higher level deliverables and the project as a whole.
Bottom-up estimating is the most accurate approach to estimating cost
and duration and also usually requires the most time. This kind of
estimating involves the entire project team and gives people the
opportunity to participate in the development of the estimates used to
measure their work. As a result, bottom-up estimating tends to develop a
much higher level of project team commitment than does top-down or
parametric estimating. In top-down, where the numbers come from an

of 16
outside source, people feel we have imposed the estimates on them. The
drawback of the bottom-up approach is that it consumes much more time
than the other estimating techniques.
In bottom-up estimating, we follow a three-step process, working from
the lowest level of detail in the work breakdown structure. We begin
bottom-up estimating by developing a detailed work package to
accompany the WBS. In this work package, we may describe risk
elements, dependencies that affect the activity and its cost and duration.
Once the work package is complete and the team member is comfortable
with it, we can proceed to develop the actual cost or duration estimate.
In bottom-up estimating, a project manager has to be careful not to force
an estimate on the project team member. If the estimate is forced, the
project manager cannot expect to earn much commitment from the team
member. That commitment is dependent on a free and open negotiation
where the team member feels the estimate is fair and reasonable. At this
point in the process, the project manager may use the three estimates
from the PERT process, as that allows an estimate that reflects the
uncertainty inherent in the task.
Last, we aggregate the estimates for each of the activities in the lowest
level of the WBS and roll the numbers up to develop estimates for the
major deliverables and the project as a whole.
We can use a number of mathematical techniques with bottom-up
estimating although the most popular and most accurate is to use three
point estimates where the team members provide the pessimistic,
optimistic and best guess numbers for the three-point calculations.
Expert Judgments
This is basically asking someone who is knowledgeable about the
application area or the development environment to give an estimate of
the effort needed to carry out a task. This method will be used when
estimating the effort and time needed to change the existing piece of the
software or developing the similar kind of software, the estimator would

of 16
have to carry the analysis in order to judge the proportion of code that
would be affected that derive an estimation from the person who is
familiar to be in the best position to do this.
But the true fact is that is simple guessing.
Historical comparison
This basically based on the cased based reasoning. The estimator seeks
out the projects that have been completed and that have similar
characteristics to the new project. The effort and time that has been
recorded for the matching source case can be used as base estimate for
the target. The estimator should try to identify any differences between
the target and source and make the adjustments to the base estimate for
new project duration and effort.
Functional Points
Alan Albrecht while working for IBM, recognized the problem in size
measurement in the 1970s, and developed a technique (which he called
Function Point Analysis), which appeared to be a solution to the size
measurement problem
The principle of Albrecht’s function point analysis (FPA) is that a
system is decomposed into functional units.
Inputs : information entering the system
Outputs : information leaving the system
Enquiries : requests for instant access to
information
Internal logical files : information held within the
system

of 16
External interface files: information held by other system
that is used by the system being
analyzed.
So on the basis of this we basically estimate the time duration for
different kind of functional points etc.
Object points
The approach was devised at the Leonard N. stern school of business,
New York University. It has similarities with FP approach, but takes
different account of features. The approach uses counts of screen,
reports and 3gl component that an application might possess it is these
that referred to as objects. Each object has to be classified as one of the
following…
1. Simple
2. Medium
3. Difficult
The number of objects at each level are multiplied by the approiate
complexity weighting as shown in the figure.

of 16
CPM (Critical path method)
In this we basically capture the activities and their inter-relationships
using a graph
Lines are used to represent the activities.
Nodes are used to represent the start and stop of activities.
With the help of cpm we can calculate the two things
The forward pass in which we calculate the earliest state of the activities
and calculate the project completion date.

of 16
The backward pass in which we calculate the latest start for activities
and identify the critical path from the graph.
Some common terms in this
Critical event : an event that has zero slack
Critical path : a path joining those critical events.
Example to construct a CPM

of 16
Pert
PERT is a planning and control tool used for defining and controlling
the tasks necessary to complete a project. PERT charts and Critical Path
Method (CPM) charts are often used interchangeably; the only
difference is how task times are computed. Both charts display the total
project with all scheduled tasks shown in sequence. The displayed tasks
show which ones are in parallel, those tasks that can be performed at the
same time. A graphic representation called a "Project Network" or
"CPM Diagram" is used to portray graphically the interrelationships of
the elements of a project and to show the order in which the activities
must be performed.
PERT planning involves the following steps:

of 16
1. Identify the specific activities and milestones. The activities are the
tasks of the project. The milestones are the events that mark the
beginning and the end of one or more activities.
2. Determine the proper sequence of activities. This step may be
combined with #1 above since the activity sequence is evident for
some tasks. Other tasks may require some analysis to determine
the exact order in which they should be performed.
3. Construct a network diagram. Using the activity sequence
information, a network diagram can be drawn showing the
sequence of the successive and parallel activities. Arrowed lines
represent the activities and circles or "bubbles" represent
milestones.
4. Estimate the time required for each activity. Weeks are a
commonly used unit of time for activity completion, but any
consistent unit of time can be used. A distinguishing feature of
PERT is it's ability to deal with uncertainty in activity completion
times. For each activity, the model usually includes three time
estimates:
o Optimistic time - the shortest time in which the activity can
be completed.
o Most likely time - the completion time having the highest
probability.
o Pessimistic time - the longest time that an activity may take.
From this, the expected time for each activity can be calculated
using the following weighted average:
Expected Time = (Optimistic + 4 x Most Likely + Pessimistic) / 6
This helps to bias time estimates away from the unrealistically
short timescales normally assumed.
5. Determine the critical path. The critical path is determined by
adding the times for the activities in each sequence and
determining the longest path in the project. The critical path
determines the total calendar time required for the project. The

of 16
amount of time that a non-critical path activity can be delayed
without delaying the project is referred to as slack time.
If the critical path is not immediately obvious, it may be helpful to
determine the following four times for each activity:
o ES - Earliest Start time
o EF - Earliest Finish time
o LS - Latest Start time
o LF - Latest Finish time
These times are calculated using the expected time for the relevant
activities. The earliest start and finish times of each activity are
determined by working forward through the network and
determining the earliest time at which an activity can start and
finish considering its predecessor activities. The latest start and
finish times are the latest times that an activity can start and finish
without delaying the project. LS and LF are found by working
backward through the network. The difference in the latest and
earliest finish of each activity is that activity's slack. The critical
path then is the path through the network in which none of the
activities have slack.
The variance in the project completion time can be calculated by
summing the variances in the completion times of the activities in
the critical path. Given this variance, one can calculate the
probability that the project will be completed by a certain date
assuming a normal probability distribution for the critical path. The
normal distribution assumption holds if the number of activities in
the path is large enough for the central limit theorem to be applied.
6. Update the PERT chart as the project progresses. As the project
unfolds, the estimated times can be replaced with actual times. In
cases where there are delays, additional resources may be needed
to stay on schedule and the PERT chart may be modified to reflect
the new situation. An example of a PERT chart is provided below:

of 16
Benefits to using a PERT chart or the Critical Path Method include:
 Improved planning and scheduling of activities.
 Improved forecasting of resource requirements.
 Identification of repetitive planning patterns which can be followed
in other projects, thus simplifying the planning process.
 Ability to see and thus reschedule activities to reflect interproject
dependencies and resource limitations following know priority
rules.
 It also provides the following: expected project completion time,
probability of completion before a specified date, the critical path
activities that impact completion time, the activities that have slack
time and that can lend resources to critical path activities, and
activity start and end dates.
Conclusion
This helps us to estimate the project duration estimation which later
helps to create a comprehensive estimate which will reflect the different
tasks and real-world scheduling. This approach will removes the
uncertainty and creates a project plan that helps us to know our options
and adapt to path changes. The duration estimation also help us to
estimate the budget of our project. As we all know that estimates can
never be exact but practicing this will make our guesses better.

of 16
Bibliography
https://4pm.com/bottom-up-estimating/
https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0CEkQ
FjAE&url=http%3A%2F%2Frpl-blog.blogspot.com%2F2010%2F03%2F411-top-down-estimation-
approach.html&ei=ajtCU6HCKoKOrQfpuYCQDw&usg=AFQjCNE1N13_-t8ZjUaaW-
01OkYFzanMaQ&sig2=svgx9iA9JqHABaLf2HeKvw&bvm=bv.64367178,d.bmk
https://slideshare.com

Project Duration Estimation

More Related Content

What's hot (20)

Similar to Project Duration Estimation (20)

Recently uploaded (20)

Project Duration Estimation