Paavai Institutions Department of CSE

UNIT II
SOFTWARE EFFECT ESTIMATION AND ACTIVITY PLANNING

UNIT-2 2. 1
 Paavai Institutions Department of CSE
.

TECHNICAL TERMS
1. Activity An element of work performed during the course of a project. An activity normally
has an expected duration, an expected cost, and expected resource requirements. Activities
are often subdivided into tasks.
2. Aggregation Using activity resource requirements to calculate total resource needs rather
than to constrain the project schedule. Normally, resource requirements are used to Perform
resource-constrained scheduling.
3. Arrow The graphic representation of an activity. arrow diagramming method.
4. Baseline Finish date (BF) The calendar date when work is scheduled to end on an activity.
This date is usually estimated, or it can be derived from the early, late or scheduled finish
dates.
5. Budgeted Cost of Work Performed (BCWP) The sum of the approved cost estimates
(including any overhead allocation) for activities (or portions of activities) completed
during a given period (usually project-to-date).
6. Cost Performance Index (CPI) The ratio of budgeted costs to actual costs
(BCWP/ACWP). The CPI is often used to predict the magnitude of a possible cost overrun
using the following formula: original cost estimate/CPI = projected cost at completion..
7. Duration The number of work periods (not including holidays or other nonworking
periods)required to complete an activity or set of activities. All activity durations are
specified with the same duration unit.
8. Earned value (EV) A method for measuring project performance. It compares the amount
of work that was planned with what was actually accomplished to determine if cost and
schedule performance is as planned.
9. Lead A modification of a logical relationship that allows an acceleration of the successor
task. For example, in a finish-to-start dependency with a 10-day lead, the success or activity
can start 10 days before the predecessor has finished.
10. Node One of the defining points of a network; a junction point joined to some or all of the
other dependency lines. Also, the graphic representation of an activity. See also arrow
diagramming method and precedence diagramming method
11. Project schedule The planned dates for performing activities and the planned dates for
meeting milestones.

UNIT-2 2. 2
 Paavai Institutions Department of CSE
.

CONTENTS
2.1 Software Effort Estimation
2.2 Agile Methods
2.3 Extreme Programming
2.4 Scrum
2.5 Problems with over and underestimates
2.6 Software effort estimation techniques
2.7 Bottom-up estimating
2.8 Top-down estimating
2.9 Estimating by analogy
2.10 Albrecht function point analysis
2.11 Activity Planning- Objectives of Activity planning-Project Schedules- Project
and Activities
2.12 Sequencing and Scheduling
2.13 Activity on Arrow Networks
2.14 Forward Pass
2.15 Backward Pass
2.16 Identifying Critical Path
2.17 Activity Float
2.18 Shortening Project Duration
2.19 Question Bank

UNIT-2 2. 3
 Paavai Institutions Department of CSE
.

2.1 Software Effect Estimation

Software effort estimation is the process of predicting the amount of time and resources
required to complete a software development project. Estimation techniques include using historical
data, expert judgment, and algorithmic methods. The goal of effort estimation is to provide project
managers with an accurate estimate of the work required, which can be used to plan and schedule the
project, allocate resources, and measure progress. It's important to note that software effort estimation
is an inexact science and the results should be considered as an approximation rather than a precise
prediction.

What is Estimation and why it is important?

The estimation is a process to find the most accurate sizing figure for the software project effort,
for example, how many months you will need to develop the software, how many resources you will
need to finish the project in the required time. And this translated to money at the end.

The estimation is important because it gives the project team some confidence about the required
effort and time to plan ahead for the project. Moreover, not all software project is time and material
contracts, some of them are fixed cost projects and this estimate will be used as a foundation to
negotiate the project cost. The Estimation Process As mentioned the estimation is a process and this
process contains the following steps to reach the estimate, this process is cycling until you reach the
final estimate for the project

Estimation Process

UNIT-2 2. 4
 Paavai Institutions Department of CSE
.

1- Scoping

You need first to scope the project even if you do not have the full detailed requirements but you can
assume some of them or add margins later. While in most cases you will have a defined scope to start
with. You can read this article to understand what is the scope and how it is different from the
requirements specifications.
You can always list your assumptions to justify the outcome of the estimation process and its results
2- Decomposition

In this step, you will need to break your software into smaller components and functions and you can
categorize them to a different set of elements, this is similar to work breakdown structure but only for
the software components not all the working activities for the software.

You may also collect different data from the project team or the customer to ensure that you have listed
all functionalities.

3- Sizing

In this step, the actual estimation will be done for each component alone, and I will illustrate more
about how you will do that using the techniques mentioned above, this will be illustrated in 8 steps in
details below.

In this step, and for more validation, you can use different estimation techniques to analyze the different
estimation outputs and you may take an average of these estimates as well.

4- Expert and Peer Review

After initial estimate, you will need at some point to ask for expert opinion for some new functionalities
you may not aware off, or for considering a review from your peers that you have done the correct
estimation. Moreover, you may need to do some analogy based techniques for similar components or
functions developed before or maybe a similar project to ensure that you are on the correct path.

UNIT-2 2. 5
 Paavai Institutions Department of CSE
.

5- Estimation Finalization

This can be considered the final step as you aggregate all the estimations from all components and
functions and have a baseline estimate. You can go another round across the process until reaching the
correct estimate which will be approved by the Project team and the Management as well.

2.2 Agile Method

 Scrum. Scrum is one of the most widely used Agile methodologies. A prescriptive framework, Scrum
excels at managing iterative and incremental projects.
 Extreme Programming (XP) Another popular Agile methodology, Extreme Programming (XP) also
emphasizes speed and continuous delivery.
 Lean Software Development. Lean software development is more flexible than Scrum or XP, with
fewer strict guidelines, rules, or methods.
 Kanban. Like other Agile methodologies, Kanban focuses on helping teams work together more
effectively to enable continuous delivery of quality products.
 Crystal. The Crystal Agile methodology focuses more on the interactions of the people involved in a
project versus the tools and techniques of development.
 Feature-Driven Development (FDD) Feature-Driven Development, or FDD, provides a framework for
product development that starts with an overall model and gets progressively more granular.

 Dynamic Systems Development Method (DSDM) The Dynamic Systems Development Method
(DSDM) rounds out our list of well-known Agile methodologies.
 Frameworks for Scaling Agile. In addition to these Agile methodologies, organizations also rely on
frameworks for scaling Agile across the enterprise.

2.3 Extreme Programming

Extreme Programming (XP) is an agile software development framework that aims to produce higher
quality software, and higher quality of life for the development team. XP is the most specific of the agile
frameworks regarding appropriate engineering practices for software development.

When Applicable

The general characteristics where XP is appropriate were described by

UNIT-2 2. 6
 Paavai Institutions Department of CSE
.

 Dynamically changing software requirements

 Risks caused by fixed time projects using new technology

 Small, co-located extended development team

 The technology you are using allows for automated unit and functional tests

Due to XP’s specificity when it comes to it’s full set of software engineering practices, there are several
situations where you may not want to fully practice XP. The post When is XP Not Appropriate on the C2
Wiki is probably a good place to start to find examples where you may not want to use XP.
While you can’t use the entire XP framework in many situations, that shouldn’t stop you from using as
many of the practices as possible given your context.

2.4 Scrum
Scrum is an Agile framework for managing and completing complex projects. It is a process that helps
teams work together to deliver products and projects in an incremental and iterative way. Scrum is an
iterative and incremental framework that facilitates the ability to change requirements and adapt to
emerging technologies and changes in the environment.

Scrum framework is composed of:

 Scrum Team:

 A cross-functional team, including a Product Owner, a Scrum Master, and Development Team Members.
 Product Backlog:

 A prioritized list of requirements for the product or project.

 Sprint:

 A time-boxed period, typically two to four weeks, during which a potentially releasable
product increment is created.
 Sprint Planning:
 A daily stand-up meeting to coordinate work and identify any obstacles.
 Sprint Review:

 A meeting in which the team demonstrates the work completed during the Sprint.
 Sprint Retrospective: A meeting in which the team reflects on the past Sprint and identifies ways
to improve.
Scrum emphasizes on working product and continuous improvement, it focus on delivering valuable
product increment at the end of each sprint, which helps to reduce the risk, increase transparency and
improve the predictability of the project.

UNIT-2 2. 7
 Paavai Institutions Department of CSE
.

2.5 Problem With Over And Underestimates

One of the challenges of using Agile methods, such as Scrum, is that they rely heavily on effort
estimation to plan and schedule work. However, software effort estimation is an inexact science, and it
can be difficult to accurately predict the amount of time and resources required to complete a project. This
can lead to over- and under-estimation of effort, which can have a significant impact on the project
schedule and budget.

Over-estimation of effort can result in a project being delayed or going over budget, while under-
estimation can lead to unrealistic expectations and an inability to deliver the expected functionality. Both
situations can cause significant problems for the project team and stakeholders.

To mitigate these issues, Agile teams can use a variety of techniques to improve their estimation
accuracy. One of the most common methods is called Planning Poker, which is a consensus-based
estimation technique that involves the entire team in the estimation process. Additionally, teams can use
historical data, expert judgment, and algorithmic methods to improve the accuracy of their estimates. It's
also important to note that Agile methods also provide the ability to change requirements and adapt to
emerging technologies and changes in the environment, which can help in reducing the risk of under/over
estimation.

It's worth noting that Agile methods emphasize on working product and continuous improvement,
which can help to reduce the risk of under/over estimation. The Agile team should be able to deliver
valuable product increment at the end of each sprint, which helps to improve the predictability of the
project.

2.6 Software Effort Estimation Techniques

 Expert judgment: This involves using the experience and knowledge of experts in the field to estimate the
effort required for a project. This can include input from project managers, developers, and other
stakeholders.
 Analogous estimation: This involves using the historical data from similar projects to estimate the effort
required for a new project. This can include data on the size, complexity, and duration of previous
projects.
 Three-point estimation: This involves generating a best-case, most likely, and worst-case estimate for the
effort required for a project. The final estimate is then based on the average of these three points.
 Planning Poker: This is a consensus-based estimation technique that involves the entire team in the
estimation process. Each team member estimates the effort required for a task or feature independently
and then discusses and reaches a consensus on the final estimate.
 Function Point Analysis (FPA): This is a technique used to estimate the size and complexity of a software
system. It involves counting the number of inputs, outputs, inquiries, and files used in a system to
UNIT-2 2. 8
 Paavai Institutions Department of CSE
.

estimate the effort required to develop it.

 Use Case Points: This is a technique that uses use cases to estimate the effort required for a project. It
involves counting the number of use cases and their complexity to estimate the effort required.
 COCOMO (Constructive Cost Model): This is a mathematical model that predicts the effort required for
a project based on a set of inputs such as project size, programming language, and development
environment.
 It's important to note that none of the techniques are perfect and the results should be considered as an
approximation rather than a precise prediction. The best approach is to use multiple techniques and
combine their results, then adjust them based on the team's experience and knowledge.

2.7 Bottom-Up Estimating

Bottom-up estimating is a technique in project management for estimating the costs or duration of
projects and parts of a project . The term bottom-up estimating gives a hint about the underlying
concept: costs, durations or resource requirements are estimated at a very granular level. This means
that the estimation is done for work packages (some might suggest activities though) which are the
lowest and most detailed level of a work breakdown structure (WBS).

 Bottom-estimating is done at the lowest level of the work breakdown structure.

 While the estimation is performed at the level of activities or work packages, the
estimate for the whole project is the sum of all granular estimates.
The bottom-up estimation technique is also referred to as deterministic or detailed estimating
(source: PMI Practice Standard for Project Estimating, 2nd edition, ch. 4.2.3). It is often used as the
so-called “definitive estimate” – a type of cost estimate that comes with an accuracy between -5%
and +10% according to the Project Management Institute (PMI).

2.8 Top down Estimating

Top-down estimating is a technique used in project management to estimate the effort required for a
project or task that has not been fully defined or understood. It is a way to "top up" the estimate for a
task or project that has not been fully defined or understood. This technique is often used in Agile
development, where requirements may change rapidly, or in projects where the scope is not well
defined.

UNIT-2 2. 9
 Paavai Institutions Department of CSE
.

The process of top-up estimating typically involves breaking down the task or project into smaller, more
manageable chunks and estimating the effort required for each chunk. The estimates are then combined to
give a total estimate for the task or project.

For example, if a project is to build a new website, the project manager may use top-up estimating to
estimate the effort required for each feature of the website, such as the login system, the shopping cart,
and the search functionality. The estimates for each feature are then combined to give a total estimate for
the project effort required for a task or project even when the requirements are not fully understood.
However, it's important to note that top-up estimating can be an inexact process and the results should be
considered as an approximation rather than a precise prediction.

It's also important to keep in mind that the team should regularly re-evaluate the estimates and adjust
them as the project progresses and more information becomes available. Additionally, it's important to
have a transparent communication with the stakeholders about the assumptions and the level of
uncertainty of the estimate.

2.9 Estimation by Analogy

Estimation by analogy is a software effort estimation technique that involves using the historical data
from similar projects to estimate the effort required for a new project. The idea behind this technique is
that projects that are similar in size, complexity, and other characteristics will have similar effort
requirements.
The process of estimation by analogy typically involves identifying similar projects that have been
completed in the past and collecting data on the size, complexity, and duration of those projects. This data
can then be used to estimate the effort required for the new project.
For example, if a project is to build a new e-commerce website, the project manager might look at similar
e-commerce websites that have been built in the past and use data on the size and complexity of those
websites to estimate the effort required for the new project.
Estimation by analogy can be a useful technique for project managers because it allows them to use
historical data to estimate the effort required for a project. However, it's important to note that this
technique has some limitations. The similarity of the projects should be carefully evaluated and the data
collected should be relevant and accurate. Additionally, it's important to consider the changes in
technology and the project's environment that might affect the effort required.

It's also important to note that estimation by analogy should be used in conjunction with other estimation
techniques, such as expert judgment, to improve the accuracy of the estimate.

UNIT-2 2. 10
 Paavai Institutions Department of CSE
.

2.10 Albrecht Function Point Analysis

Software system. It was developed by Dr. Alan Albrecht in the late 1970s and is based on the idea that the
size and complexity of a software system can be measured by counting the number of inputs, outputs,
inquiries, and files used in the system.The process of Albrecht FPA involves counting the number of each
type of function point (FP) in the system, including:

 Inputs: The number of inputs, such as data entered into the system by a user.

 Outputs: The number of outputs, such as reports or documents generated by the system.

 Inquiries: The number of inquiries, such as database searches or calculations performed by the system.

 Files: The number of files, such as data stored in a database or files on a file server.

Once the number of function points has been counted, a complexity weighting factor is applied to each
type of function point to account for the complexity of the function. The total number of function points is
then multiplied by the complexity weighting factor to estimate the effort required to develop the system.

Albrecht FPA is widely used in software development as a measure of software size and complexity. It is
an objective and repeatable method that can help project manager’s estimate the effort required to
develop a system, as well as monitor and track the progress of a project.

It's worth noting that Albrecht FPA has been updated since its original release and now there are different
versions of it, such as COSMIC-FFP (IFPUG's version) and Mark II FPA (Australian version).

2.11 Activity Planning

Objectives
• define the scope of ‗software project management‘
UNIT-2 2. 11
 Paavai Institutions Department of CSE
.

• distinguish between software and other types of development project;

• understand some problems and concerns of software project managers;

• define the usual stages of a software project;

• explain the main elements of the role of management;

• appreciate the need for careful planning, monitoring and control;

• Identify the stakeholders of a project and their objectives and ways of defining the success in meeting
those objectives.

Project Schedule
Scheduling is an inexact process in that it tries to predict the future. While it is not possible to
know with certainty how long a project will take, there are techniques that can increase your likelihood
of being close. If you are close in your planning and estimating, you can manage the project to achieve
the schedule by accelerating some efforts or modifying approaches to meet required deadlines.

One key ingredient in the scheduling process is experience in the project area; another is
experience with scheduling in general. In every industry area there will be a body of knowledge that
associates the accomplishment of known work efforts with a time duration. In some industries, there
are books recording industry standards for use by cost and schedule estimators. Interviewing those who
have had experience with similar projects is the best way to determine how long things will really take.

When preparing a schedule estimate, consider that transition between activities often takes time.
Organizations or resources outside your direct control may not share your sense of schedule urgency,
and their work may take longer to complete. Beware of all external dependency relationships.
Uncertain resources of talent, equipment, or data will likely result in extending the project schedule.

Experience teaches that things usually take longer than we think they will, and that giving away
schedule margin in the planning phase is a sure way to ensure a highly stressed project effort. People
tend to be optimistic in estimating schedules and, on average, estimate only 80% of the time actually
required.

Failure to meet schedule goals is most often due to unrealistic deadlines, passive project
execution, unforeseen problems, or things overlooked in the plan.

UNIT-2 2. 12
 Paavai Institutions Department of CSE
.

Project and Activities

In project management, a project is a temporary endeavor with a specific goal or objective, and a
defined start and end date. The goal of a project is to deliver a unique product or service, and it is
typically defined by a project charter or statement of work. A project can be broken down into smaller,
more manageable activities that are required to achieve the project goals.
Activities in project management refer to the specific tasks or steps that need to be completed in order
to achieve the project goals. These activities are typically identified and defined in the project plan and

are used to schedule, execute, and control the project. Activities can be broken down into smaller sub-
activities or work packages, and can be grouped into logical work units, such as phases or stages.

Activities in a project can be related to different areas, such as:

 Project planning: activities related to the definition of the project scope, goals, deliverables, and
schedule
 Project execution: activities related to the actual work of completing the project, such as design,
development, and testing
 Project monitoring and controlling: activities related to tracking progress, identifying and resolving
issues, and making adjustments to the project plan as needed
 Project closing: activities related to completing the project and closing it out, such as finalizing
documentation and conducting a project review.

Activities in project management are typically sequenced in a specific order, and dependencies between
activities are identified and managed. This helps ensure that all tasks are completed in the correct order
and that the project is completed on time and within budget.

UNIT-2 2. 13
 Paavai Institutions Department of CSE
.

2.12 Sequencing and Scheduling Activities

The Gantt Chart

Taking its name from early project management innovator Henry L. Gantt, the basic Gantt chart is an easy
way to document schedules. It is a horizontal-bar schedule showing activity start, duration, and completion.
It shows the connection between events and the calendar, and provides a graphical analog of the activity
duration.
The Gantt schedule can illustrate the relationship between work activities having duration,
events without duration that indicate a significant completion, and milestones that represent major
achievements or decision points. Various annotations can be used to communicate the progress of the
project effort compared to the baseline plan, as well to depict in a graphical way areas where there are
modified expectations from the baseline plan.

Once a Gantt schedule has been established for a project, progress should be periodically plotted
against the baseline schedule. If different functional areas are involved in a project, each area may need
its own detailed schedules to support the project master schedule. In such cases it is important that
working schedules be linked to a common master schedule in a way that they can be easily updated.
Each activity or event on the schedule should have a responsible individual assigned, so there is clear
ownership and so schedule status can be updated without a lot of fuss.

UNIT-2 2. 14
 Paavai Institutions Department of CSE
.

2.13 Activity on Arrow Networks

The Program (or Project) Evaluation and Review Technique, commonly abbreviated
PERT, is a model for project management designed to analyze and represent the tasks involved in
completing a given project. It is commonly used in conjunction with the critical path method or CPM.

Implementation

The first step to scheduling the project is to determine the tasks that the project requires and the
order in which they must be completed. The order may be easy to record for some tasks (e.g. When
building a house, the land must be graded before the foundation can be laid) while difficult for others

(There are two areas that need to be graded, but there are only enough bulldozers to do one).
Additionally, the time estimates usually reflect the normal, non-rushed time. Many times, the time
required to execute the task can be reduced for an additional cost or a reduction in the quality.

In the following example there are seven tasks, labeled A through G. Some tasks can be done
concurrently (A and B) while others cannot be done until their predecessor task is complete (C cannot
begin until A is complete). Additionally, each task has three time estimates: the optimistic time estimate
UNIT-2 2. 15
 Paavai Institutions Department of CSE
.

(O), the most likely or normal time estimate (M), and the pessimistic time estimate (P). The expected
time (TE) is computed using the formula (O + 4M + P) ÷ 6.

Time estimates Activity Predecessor Expected time Opt. (O) Normal (M) Pess. (P)

A — 2 4 6 4.00

B — 3 5 9 5.33

C A 4 5 7 5.17

D A 4 6 10 6.33

E B, C 4 5 7 5.17

F D 3 4 8 4.50

G E 3 5 8 5.17

Once this step is complete, one can draw a Gantt chart or a network diagram.

A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red,(2) the slack is
the black lines connected to non-critical activities, (3) since Saturday and Sunday are not work days and are
thus excluded from the schedule, some bars on the Gantt chart are longer if they cut through a weekend.

A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack is not
specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and f), (3) since
weekends are indicated by a thin vertical line, and take up no additional space on the work calendar, bars
on the Gantt chart are not longer or shorter when they do or don't carry over a weekend.

UNIT-2 2. 16
 Paavai Institutions Department of CSE
.

Network Planning Models

Network planning models are used to find critical path from given duration. These methods are

2.14 Forward Pass

UNIT-2 2. 17
 Paavai Institutions Department of CSE
.

Figure 9-20.—Example of forward-pass calculations. Early finish (EF)— Earliest time an

activity may be finished; Late start (LS)— Latest time an activity may be started and still remain on
schedule; and Late finish (LF)— Latest time an activity may be finished and still remain on schedule.
The main objective of forward-pass computations is to determine the duration of the network. The
forward pass establishes the early start and finish of each activity and determines the longest path
through the network (critical path). The common procedure for calculating the project duration is to
add activity durations successively, as shown in figure 9-20, along chains of activities until a merge is
found. At the merge, the largest sum entering the activity is taken at the start of succeeding activities.
The addition continues to the next point of merger, and the step is repeated. The formula for forward-
pass calculations is as follows: ES = EF of preceding activity EF = ES + activity duration The
backward-pass latest possible start and computations provide the finish times that may take place
without altering the network relationships. These values are obtained by starting the calculations at the
last activity in the network and working backward, subtracting the succeeding duration of an activity
from the early finish of the activity being calculated. When a ―burst‖ of activities emanating from the
same activity is encountered, each path is calculated. The smallest or multiple value is recorded as the
late finish. The backward pass is the opposite of the forward pass. During the forward pass, the
early start is added to the activity duration to become the early finish of that activity. During the
backward pass, the activity duration is subtracted from the late finish to provide the late start time of
that activity. This late start time then becomes the late finish of the next activity within the backward
flow of the diagram. LS = LF – activity duration Figure 9-21 shows a network with forward- and
backward-pass calculations entered

2.15 Backward Pass

As another example of critical path scheduling, consider the seven activities associated with the
fabrication of a steel component shown in Table 10-4. Figure 10-7 shows the network diagram
associated with these seven activities. Note that an additional dummy activity X has been added to
insure that the correct precedence relationships are maintained for activity E. A simple rule to observe
is that if an activity has more than one immediate predecessor and another activity has at least one but
not all of these predecessor activity as a predecessor, a dummy activity will be required to maintain
precedence relationships. Thus, in the figure, activity E has activities B and C as predecessors, while
activity D has only activity C as a predecessor. Hence, a dummy activity is required. Node numbers
UNIT-2 2. 18
 Paavai Institutions Department of CSE
.

have also been added to this figure using the procedure outlined in Table 10-1. Note that the node
numbers on nodes 1 and 2 could have been exchanged in this numbering process since after numbering
node 0, either node 1 or node 2 could be numbered next

2.16 Identifying Critical Path

In project management, the critical path is the sequence of activities that determines the
minimum duration of a project. It represents the longest path of dependent activities that must be
completed in order to finish the project on time. Any delay in completing an activity on the critical
path will result in a delay to the overall project completion.

To identify the critical path, project managers use a technique called Critical Path Method (CPM) or
Precedence Diagramming Method (PDM) which is a network analysis method that diagrams the logical
relationships between activities and events in a project. This method is used to create a network diagram
of the project schedule, which shows the dependencies between activities, and helps identify the critical
path.

The process of identifying the critical path involves the following steps:
 Break down the project into a series of activities and work packages
 Determine the dependencies between the activities and work packages
 Identify the duration of each activity or work package
 Draw a network diagram that shows the dependencies between activities
 Identify the critical path by finding the longest path through the network diagram that includes all the
critical activities
 Identify the critical activities by looking at the network diagram and seeing which activities have no
slack or float time.

Once the critical path is identified, project managers can use it to monitor the progress of the project
and make adjustments as needed. By monitoring the critical path, they can identify potential delays
early on and take action to keep the project on track. Additionally, it can also help to identify the areas
where the project could be accelerated and where resources could be better allocated to meet project
goals.

UNIT-2 2. 19
 Paavai Institutions Department of CSE
.

2.17 Activity Float

Activity float in project management refers to the amount of time that an activity can be delayed
without delaying the overall project completion date. It is also referred to as "slack" or "schedule float."
The concept of float is important in project management because it allows project managers to identify
activities that have some flexibility in their schedules, which can be used to manage project risks and
make adjustments as needed.

There are two types of float:

 Total float: the amount of time an activity can be delayed without delaying the project completion date.

 Free float: the amount of time an activity can be delayed without delaying the start of its immediate
successor activity.

Total float is the amount of time an activity can be delayed without delaying the completion of
the project. It is calculated by subtracting the early start date of an activity from its late start date.

Free float is the amount of time an activity can be delayed without delaying the start of its
immediate successor activity. It is calculated by subtracting the early start date of an activity from the
early start date of its immediate successor activity.

Project managers can use activity float to manage project risks by identifying activities with the most
float and making adjustments to those activities. For example, if an activity has a lot of float, it might
be possible to add additional work to that activity without delaying the project. On the other hand, if
an activity has little or no float, it might be necessary to take action to accelerate the activity in order
to avoid delays.

It's worth noting that the critical path is the one that has zero float, therefore, any delay in a critical
activity will delay the overall project completion date. Identifying the critical path and monitoring its
activities is important to keep the project on track

2.18 Shortening Project Duration

The critical path is the place to look when you want to shorten a schedule. By definition,
the critical path is the sequence of tasks that is nothing but back-to-back work, with no
slack, which you can subtract to reduce the duration. Figure 1 shows that shortening the

UNIT-2 2. 20
 Paavai Institutions Department of CSE
.

Build Ship Infrastructure task won't do anything to shorten the overall project duration.
Because the Build Improbability Drive task is longer, it determines when the Assemble
Components task starts, regardless of how little time it takes to build the ship.

Figure 1: The tasks on the critical path are the only ones that can shorten the duration of a
project.

2.19 Question Bank:

PART-A
1. What is project evaluation?
2. What is the 3 criteria project evaluation depends?
3. What is Technical assessment?
4. What are the two primary steps of cost-benefit analysis?
5. Name any two external dependencies.
6. What is agile model?
7. Mention advantages and disadvantages of agile model.
8. What are types of agile framework?
9. Apllications of agile model.
10. Why we us agile model?
11. What are three kinds of interfaces?
12. Write the goals of project management?
13. What are Development Costs?
14. What is Net Present value?
15. What is an activity?

UNIT-2 2. 21
 Paavai Institutions Department of CSE
.

PART-B
1. Explain why discount cash flow techniques provide better criteria for projects election than
net profit or return on investment?
2. Identify major risk of your own organization in the pay roll payout.
3. Draw decision diagram for accounting project department with extend and replace.
4. Consider the projects cash flow estimates for four project at your own, Rank the four projects
in order of financial desirability and make a note of your reasons for ranking them in that
way?
5. Draw and explain a risk analysis profile?
6. Explain risk analysis using decision free.
7. Explain agile framework
8. What is agile framework? Why use agile framework? list out the application of agile
Framework

UNIT-2 2. 22