Chapter 3

Software Project Management

3.1 The management spectrum- 4P's:
For properly building a product, there's a very important concept that we all should know
in software project planning while developing a product. There are 4 critical components in
software project planning which are known as the 4P's namely:

These components play a very important role in your project that can help your team meet its
goals and objective. Now, Let's dive into each of them a little in detail to get a better
understanding:

 People:
The most important component of a product and its successful implementation is human

resources. In building a proper product, a well-managed team with clear-cut roles defined
for each person/team will lead to the success of the product. We need to have a good team
in order to save our time, cost, and effort. Some assigned roles in software project
planning are project manager, team leaders, stakeholders, analysts, and other IT
professionals. Managing people successfully is a tricky process which a good project
manager can do.
  Product:
As the name inferred, this is the deliverable or the result of the project. The project
manager should clearly define the product scope to ensure a successful result, control the
team members, as well technical hurdles that he or she may encounter during the building
of a product. The product can consist of both tangible or intangible such as shifting the
company to a new place or getting a new software in a company.

 Process:
In every planning, a clearly defined process is the key to the success of any product. It
regulates how the team will go about its development in the respective time period. The
Process has several steps involved like, documentation phase, implementation phase,
deployment phase, and interaction phase.

 Project:
The last and final P in software project planning is Project. It can also be considered as a
blueprint of process. In this phase, the project manager plays a critical role. They are
responsible to guide the team members to achieve the project’s target and objectives,
helping & assisting them with issues, checking on cost and budget, and making sure that
the project stays on track with the given deadlines.

What is Software Project Management?

Software Project Management is the discipline of planning, organizing, leading, and controlling
software projects to deliver a product that meets requirements within the constraints of time,
cost, and quality.

It applies both general project management principles and software-specific practices to ensure
successful development.

Key Points:
 Definition: It is the process of managing software development projects from initiation to
completion, balancing scope, time, cost, and quality.

 Objective: To deliver software that fulfills user needs while staying within budget and
schedule.

 Focus: Coordinating resources (people, technology, tools, processes) to achieve project

goals efficiently.
Job responsibilities of Project manager:
A Project Manager (PM) is responsible for planning, executing, and closing projects efficiently
while meeting objectives. Their responsibilities cover leadership, coordination, and
communication. Here are the main job responsibilities of a Project Manager:

1. Project Planning

 Define project scope, goals, deliverables, and success criteria.

 Develop detailed project plans, schedules, and milestones.

 Estimate resources (time, budget, workforce, tools).

2. Team Management
 Build and lead the project team.

 Assign tasks and clarify roles/responsibilities.

 Motivate team members and resolve conflicts.

3. Resource & Budget Management

 Allocate and manage resources effectively.

 Track project expenses and ensure they stay within budget.

 Optimize resource utilization.

4. Communication & Coordination

 Act as the bridge between stakeholders, team, and management.

 Provide regular project status updates and reports.

 Facilitate meetings and ensure smooth information flow.

5. Risk & Issue Management

 Identify potential risks early and create mitigation plans.

  Resolve issues that may impact timelines, budget, or quality.

 Adapt to changing project requirements.

6. Quality Assurance
 Ensure deliverables meet quality standards and stakeholder expectations.

 Conduct reviews and testing as required.

 Implement feedback mechanisms for continuous improvement.

7. Project Execution & Monitoring

 Track project progress against the plan.

 Monitor timelines, budgets, and resource usage.

 Use tools like Gantt charts, Agile boards, or dashboards for tracking.

8. Stakeholder Management

 Manage expectations of clients, sponsors, and senior management.

 Balance competing demands of scope, time, cost, and quality.

 Maintain strong relationships with all stakeholders.

9. Documentation & Reporting

 Maintain comprehensive project documentation.

 Prepare progress, performance, and post-project evaluation reports.

 Ensure compliance with organizational or industry standards.

10. Project Closure

 Oversee final deliverable handover to client or end-users.

 Conduct post-project evaluations (lessons learned).

 Release project resources and formally close the project.
Skills required for Project Manager

1. Leadership Skills
 Ability to inspire, guide, and motivate a team.

 Decision-making and conflict resolution.

 Delegating tasks effectively.

2. Communication Skills

 Clear verbal and written communication.

 Active listening and negotiation.

 Managing stakeholder expectations.

3. Organizational & Planning Skills

 Time management and scheduling.

 Prioritizing tasks and setting milestones.

 Coordinating multiple activities at once.

4. Risk & Problem-Solving Skills

 Identifying risks early and creating mitigation plans.

 Analytical thinking for solving issues.

 Adaptability in uncertain situations.

5. Technical & Domain Knowledge

 Understanding project management methodologies (Agile, Scrum, Waterfall, etc.).

 Familiarity with project management tools (MS Project, Jira, Trello, Asana).
 Knowledge of the industry/technology the project is in.
6. Financial & Budget Management

 Estimating project costs.

 Monitoring and controlling budget.

 Ensuring cost-effective use of resources.

7. Interpersonal & Emotional Intelligence

 Building strong relationships with team and stakeholders.

 Empathy and patience.

 Handling stress and maintaining team morale.

8. Negotiation & Persuasion

 Balancing needs of clients, team, and management.

 Securing necessary resources.

 Achieving win–win outcomes.

9. Critical Thinking & Analytical Skills

 Breaking down complex problems.

 Evaluating alternatives before choosing solutions.

 Making data-driven decisions.

10. Flexibility & Adaptability

 Adjusting plans when requirements change.

 Embracing new tools, technologies, or methods.

 Learning continuously.
Project Planning
Project Planning is the process of defining the objectives, scope, tasks, schedules, resources,
and risk management strategies of a project before actual execution starts. It acts as a
blueprint or roadmap for the project team and stakeholders.

Key Components
1. Estimation (Cost, Duration, Effort)

o Cost Estimation: Predicts the financial resources needed (labor, equipment,

materials, software, etc.).

o Duration Estimation: Predicts the total time required to complete the project.

o Effort Estimation: Calculates the amount of work (usually in person-hours or

person-days).
➝ Example: Developing a software module may take 3 developers × 2 weeks =
240 person-hours.

2. Staffing (Staff Organization, Staff Plans)

o Staff Organization: Defines team structure (who reports to whom, roles and
responsibilities).

o Staff Plans: Identifies required skills, number of people, and timelines for their
involvement.
➝ Example: A software project may require developers, testers, UI/UX designers,
and project managers at different stages.

3. Scheduling (Manpower & Other Resources)

o Allocating resources (people, tools, machines, time) to different project tasks.

o Helps in avoiding delays and bottlenecks.

o Tools: Gantt Charts, CPM (Critical Path Method), PERT charts.

➝ Example: Testing is scheduled after coding; deployment after testing.

4. Risk Management

o Identifying possible risks (technical, financial, operational).

 o Analyzing the impact of risks.

o Preparing mitigation or contingency plans.

➝ Example: Risk = Delay in hardware delivery → Mitigation = Use backup
supplier.

5. Miscellaneous Plans

o Quality Assurance Plan: Ensures the project deliverables meet predefined quality
standards.

o Configuration Management Plan: Maintains consistency of documents, code, and

design versions.

o Installation Plan: Details how the system will be installed, deployed, and
transitioned into the working environment.
➝ Example: Before delivering software, QA checks must pass, proper version
control (Git) is followed, and deployment steps are documented.

Project Size Estimation

Project size estimation is the process of quantifying the size of a software project before
development starts. It is a critical part of software project management because it affects:

 Cost estimation – How much the project will cost.

 Effort estimation – How many person-hours/days are required.

 Schedule estimation – How long the project will take.

 Resource allocation – How many developers or machines are needed.

Accurate size estimation helps in planning, tracking, and controlling software projects.

Why Size Estimation Matters?

1. Budgeting – Overestimating or underestimating size can affect financial planning.

2. Project Scheduling – Helps set realistic deadlines.

3. Risk Management – Identifies potential risks due to project complexity.

4. Quality Management – Provides insights into testing and maintenance efforts.

Lines of Code (LOC) – Full Detailed Information
1. Definition

Lines of Code (LOC) is a software metric used to measure the size of a software program by
counting the number of lines in its source code. It is one of the earliest and most
straightforward metrics for software size estimation.
 LOC counts actual code statements, often excluding comments and blank lines.

 It is usually used to estimate effort, cost, and schedule of a software project.

Variants of LOC measurement:

1. Physical LOC (PLOC) – Total number of lines in the source file, including comments and
blank lines.

2. Logical LOC (LLOC) – Counts only executable statements, ignoring comments and
blank lines.

2. Purpose of LOC

 Project Estimation: Helps estimate effort, time, and cost required.

 Productivity Measurement: Measures developer output (e.g., LOC per developer per
month).

 Maintenance: Helps estimate the effort required to maintain existing code.

 Complexity Analysis: Can indicate complexity (larger codebases may be more complex).

3. How to Count LOC

Manual Counting

 Simply count each line of code in a file.

 Can exclude blank lines and comments for more meaningful metrics.

Automated Tools

 Tools can parse code and give accurate counts, e.g., cloc, SLOCCount.
Example with Python code:

# Sample code

a = 10 # executable

b = 20 # executable
c=a+b # executable

 Physical LOC = 5 (all lines including comment & blank line)

 Logical LOC = 3 (only executable statements)

4. Calculation & Usage

LOC is used in formulas for estimating effort and cost:

1. Effort Estimation (Person-Months):

𝑳𝑶𝑪
𝑬𝒇𝒇𝒐𝒓𝒕𝒔 =
𝒑𝒓𝒐𝒅𝒖𝒄𝒕𝒊𝒗𝒊𝒕𝒚 (𝑳𝑶𝑪 𝒑𝒆𝒓 𝒑𝒆𝒓𝒔𝒐𝒏 𝒎𝒐𝒏𝒕𝒉)
Example:

 LOC = 50,000

 Productivity = 1,000 LOC/person-month

50000
𝐸𝑓𝑓𝑜𝑟𝑡𝑠 = = 50 𝑝𝑒𝑟𝑠𝑜𝑛 𝑚𝑜𝑛𝑡ℎ
1000
2. Cost Estimation:

𝐶𝑜𝑠𝑡 = 𝐸𝑓𝑓𝑜𝑟𝑡 𝑋 𝐶𝑜𝑠𝑡 𝑝𝑒𝑟 𝑝𝑒𝑟𝑠𝑜𝑛 − 𝑚𝑜𝑛𝑡ℎ

3. Schedule Estimation:

Some models, like COCOMO, use LOC to calculate development time and staffing
requirements.
5. Advantages of LOC

 Simple and Easy to Understand: Anyone can grasp LOC quickly.

 Track Progress: Easy to measure progress during coding.

 Available Early During Coding: Once coding starts, LOC can be measured continuously.
 Supports Effort and Cost Estimation: Used in models like COCOMO.

6. Limitations / Disadvantages of LOC

1. Language-Dependent:

o Different programming languages require different LOC for the same

functionality.

o Example: 50 LOC in C might equal 20 LOC in Python.

2. Not Suitable Early in Project:

o Cannot estimate before coding starts.

3. Quality Ignored:
o LOC measures quantity, not quality or complexity.

4. Encourages Bad Practices:

o Developers may write unnecessarily long code to increase LOC.

5. Doesn’t Reflect Functionality:

o 1,000 LOC may represent a few simple features or many complex features.

Function Points (FP) – Full Detailed Information

1. Definition

Function Points (FP) is a software metric used to measure the size of a software application
based on the functionality provided to the user, rather than the amount of code written.

 It was introduced by Allan Albrecht (IBM, 1979).

 FP is language-independent, meaning it doesn’t depend on whether the project is written
in Java, Python, or C.

 FP helps in early estimation, even before coding starts.

 2. Purpose of Function Points

1. Estimate Project Effort and Cost:

o FP allows managers to estimate person-hours and budget based on functionality.

2. Compare Projects Across Languages:

o Since FP is independent of coding language, it allows fair comparison.

3. Track Productivity:

o Productivity can be measured as FP per person-month.

4. Plan Resources and Schedule:

o Helps in staffing and scheduling before coding begins.

3. Components of Function Points

FP calculation is based on five major components that describe the system:

Component Description

User data or control inputs entering the system (forms,

External Inputs (EI)
commands).

External Outputs (EO) Data leaving the system (reports, messages).

User requests requiring immediate response (queries without

External Inquiries (EQ)
updates).

Internal Logical Files

Logical data stored within the system (databases, files).
(ILF)

External Interface Files

Data or files used by the system but maintained externally.
(EIF)

Each component is assigned a complexity weight: Low, Average, High, based on the number of
data elements and file types.
4. Steps to Calculate Function Points

Step 1: Identify Components

 Count all EI, EO, EQ, ILF, EIF in the system.

Step 2: Assign Complexity Weights

 Each component is classified as Low, Average, or High.

 Example weights:

Component Low Average High

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

Step 3: Calculate Unadjusted Function Points (UFP)

𝑼𝑭𝑷 = (𝑪𝒐𝒎𝒑𝒐𝒏𝒆𝒏𝒕 𝑪𝒐𝒖𝒏𝒕 𝑿 𝑾𝒆𝒊𝒈𝒉𝒕)

Step 4: Apply Value Adjustment Factor (VAF)

 Consider 14 General System Characteristics (GSCs) like performance, reusability,

complexity.

 Each GSC is rated 0–5.

 Compute VAF:

𝑈𝐹𝑃 = 0.65 + ( 0.01 𝑋 𝑇𝑜𝑡𝑎𝑙 𝐺𝑆𝐶)

Step 5: Calculate Final Function Points (FP)

𝐹𝑃 = 𝑈𝐹𝑃 𝑋 𝑉𝐴𝐹
5. Example Calculation

Suppose a system has:

 5 External Inputs (EI): 3 low, 2 average

 3 External Outputs (EO): 2 low, 1 high

 2 Internal Logical Files (ILF): 1 low, 1 high

 0 External Interface Files (EIF) and External Inquiries (EQ)

Step 1: UFP Calculation

 EI: 3∗3+2∗4=173*3 + 2*4 = 173∗3+2∗4=17

 EO: 2∗4+1∗7=152*4 + 1*7 = 152∗4+1∗7=15

 ILF: 1∗7+1∗15=221*7 + 1*15 = 221∗7+1∗15=22

 EQ = 0, EIF = 0

𝑈𝐹𝑃 = 17 + 15 + 22 = 54

Step 2: Assume Total GSC = 20

𝑉𝐴𝐹 = 0.65 + (0.01 ∗ 20) = 0.85

Step 3: Final FP

𝐹𝑃 = 54 ∗ 0.85 = 45.9 ≈ 46

6. Advantages of Function Points

1. Language-Independent: Works regardless of programming language.

2. Early Estimation: Can estimate effort before coding starts.

3. Focuses on Functionality: Measures delivered functionality rather than code volume.

4. Supports Productivity Metrics: Useful to track FP per person-month.

5. Comparative Tool: Allows comparison between projects or systems.

7. Disadvantages / Limitations

1. Subjectivity: Classification of components and GSC ratings can vary between evaluators.

2. Complexity in Large Projects: Manual FP counting can be time-consuming.

3. Does Not Directly Reflect Code Complexity: It measures functionality, not internal
complexity.

4. Requires Training/Experience: Accurate estimation requires knowledge of FP counting

rules.

8. Usage in Software Project Management

1. Effort Estimation:

𝐸𝑓𝑓𝑜𝑟𝑡 (𝑃𝑒𝑟𝑠𝑜𝑛 − 𝑀𝑜𝑛𝑡ℎ𝑠) = 𝐹𝑃 × 𝐸𝑓𝑓𝑜𝑟𝑡 𝑝𝑒𝑟 𝐹𝑃

2. Cost Estimation:

𝐶𝑜𝑠𝑡 = 𝐸𝑓𝑓𝑜𝑟𝑡 × 𝐶𝑜𝑠𝑡 𝑝𝑒𝑟 𝑃𝑒𝑟𝑠𝑜𝑛 − 𝑀𝑜𝑛𝑡ℎ

3. Schedule Estimation: Helps plan development timeline.

4. Productivity Measurement: FP can measure team productivity independent of
programming language.
5. Comparison Across Projects: Useful in organizations managing multiple software
projects.

9. Function Points vs LOC

Feature LOC Function Points (FP)

Basis Lines of code Software functionality

Language Dependence Yes No

Early Estimation No Yes

Complexity Reflection No Partially (via GSCs)

Accuracy Depends on coding style More stable across languages

Difference between LOC and FP
Feature Lines of Code (LOC) Function Points (FP)

Measures software size by counting Measures software size based

Definition the number of lines in the source on the functionality delivered to
code. the user.

Software functionality (what the

Basis Code volume (implementation).
system does).

Language Yes, LOC varies by programming No, language-independent;

Dependence language. measures functionality.

Early No, LOC can be measured only Yes, FP can be estimated before
Estimation after coding starts. coding starts.

Partially; complexity considered

Complexity Limited; does not reflect
via component weights and
Reflection complexity directly.
Value Adjustment Factor (VAF).

Moderate; requires identifying

Ease of Easy; can be counted manually or
components and calculating
Measurement with automated tools.
weights.

User requirements and delivered

Focus Implementation details.
functionality.

Provides early estimation,

Simple, easy to track progress,
language-independent, supports
Pros supports effort/cost estimation once
productivity metrics, better for
coding starts.
comparing projects.

Subjective, requires experience,

Not suitable before coding,
calculation can be time-
language-dependent, does not
Cons consuming for large projects,
measure functionality or quality,
does not directly reflect code
may encourage unnecessary code.
complexity.

Tracking progress during coding, Early project estimation,

Best Use estimating effort based on historical comparing projects, estimating
productivity. cost, effort, and productivity.
3.3 What is Project Cost Estimation?
Project cost estimation in software engineering is the process of predicting the effort, time,
and resources required to complete a software project.

Key parameters in cost estimation:

 Effort: Number of person-months (PM) required.

 Development Time: Duration to complete the project.

 Cost: Usually estimated as Effort × Cost per person-month.

COCOMO (Constructive Cost Model) is one of the most widely used algorithmic models for
software cost estimation.

2. COCOMO (Constructive Cost Model) – Basic Overview

Developed by: Barry W. Boehm in 1981.
Purpose: Estimate effort, duration, and cost based on Lines of Code (LOC).
COCOMO uses the formula:

𝐸𝑓𝑓𝑜𝑟𝑡 (𝑃𝑒𝑟𝑠𝑜𝑛 − 𝑀𝑜𝑛𝑡ℎ𝑠) = 𝑎 × (𝐾𝐿𝑂𝐶)

𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 (𝑀𝑜𝑛𝑡ℎ𝑠) = 𝑐 × (𝐸𝑓𝑓𝑜𝑟𝑡𝑠)

Where:

 KLOC = Thousands of Lines of Code.

 a, b, c, d = constants depending on the type of project.

COCOMO Project Categories

1. Organic – Small, simple software projects, experienced teams.

o a = 2.4, b = 1.05, c = 2.5, d = 0.38

2. Semi-Detached – Medium complexity, mixed experience.

o a = 3.0, b = 1.12, c = 2.5, d = 0.35

3. Embedded – Complex projects with stringent requirements.

o a = 3.6, b = 1.20, c = 2.5, d = 0.32

Example Calculation:

Suppose a small organic project of 50 KLOC:

 .
𝐸𝑓𝑓𝑜𝑟𝑡 = 2.4 × (50) ≈ 137.6 𝑃𝑀
.
𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 = 2.5 × (137.6) ≈ 14.4 𝑚𝑜𝑛𝑡ℎ𝑠

Cost can then be estimated by multiplying effort by cost per person-month.

3. COCOMO II – Enhanced Version

Why COCOMO II?

COCOMO II was developed to handle modern software development with object-oriented,
web-based, and reusable components.

COCOMO II Models

1. Application Composition Model – For prototyping, GUI-based development.

o Uses Object Points instead of LOC.

2. Early Design Model – Early estimation before detailed design.

o Uses Function Points and scale factors.

3. Post-Architecture Model – After architecture is defined.

o Most detailed, includes effort multipliers for cost drivers (like reliability, team
experience, tools).

COCOMO II Effort Estimation Formula

𝑬𝒇𝒇𝒐𝒓𝒕 (𝑷𝒆𝒓𝒔𝒐𝒏 − 𝑴𝒐𝒏𝒕𝒉𝒔) = 𝟐. 𝟗𝟒 × (𝑺𝒊𝒛𝒆)𝑬 × ∏𝑬𝑴𝒊

Where:
 Size = estimated size in KLOC or Function Points.

 E = scaling exponent based on 5 scale factors (like precedentedness, flexibility, risk).

 EM_i = 17 effort multipliers for cost drivers (software reliability, database size, tool use,
personnel experience).

Development Time (Schedule) Estimation

. . ( . )
𝑇𝑖𝑚𝑒 (𝑀𝑜𝑛𝑡ℎ𝑠) = 3.67 × (𝐸𝑓𝑓𝑜𝑟𝑡)

This formula adjusts time based on project complexity.

Key Advantages of COCOMO II

 Can estimate modern software projects with reused code, components, and objects.

 Considers team experience, tool use, and product complexity.

 Provides more accurate effort and schedule predictions than original COCOMO.
Difference between COCOMO and COCOMO II

Feature COCOMO (Original) COCOMO II

Developer /
Barry Boehm, 1981 Barry Boehm, 1995 (updated 2000)
Year

Estimate effort, schedule, and cost for

Estimate effort and
modern software projects including
Purpose schedule for traditional
object-oriented, web-based, and reuse-
software projects
based projects

LOC, Function Points (FP), or Object

Input Metric Lines of Code (LOC)
Points (OP)

Project 3 types: Organic, Semi- 3 models: Application Composition,

Categories Detached, Embedded Early Design, Post-Architecture

Effort = 2.94 * (Size)^E * ΠEMi (EMi =

Effort Formula Effort = a * (KLOC)^b
effort multipliers, E = scale factor)

Cost Drivers / 15 cost drivers (simple

17 effort multipliers + 5 scale factors
Factors multipliers)

Can handle modern complexities: reuse,

Complexity Limited to traditional
component-based, object-oriented,
Handling procedural software
distributed systems

Good for simple, small More accurate for large, modern,

Accuracy
to medium projects complex projects

Schedule Development Time = c * Time = 3.67 * (Effort)^(0.28 + 0.2*(E-

Estimation (Effort)^d 1.01))

Flexibility / High (supports early estimation,

Limited
Modern Use prototyping, post-architecture)

Consideration Supported (reuse adjustment factors

Not supported
of Reuse included)

Supported by calculators and software

Tool Support Basic manual calculation
tools, more automation possible
3.4 Define risk, types of risk, RMMM strategy
1. What is Risk?
Risk is any uncertain event or condition that, if it occurs, may have a positive or negative
effect on a project’s objectives, such as time, cost, scope, or quality.

 In software projects, risks are mostly negative, potentially causing delays, increased
costs, or poor quality.

 Risk management is proactive: identifying, analyzing, and planning responses to risks

before they impact the project.

Example:

 A team member may leave the project → delay in delivery.

 Technology chosen may become obsolete → increased maintenance costs.

Different Types of Risks in Software Project Development

Software development is a multi-stage approach of design, documentation,

programming, prototyping, testing, etc. which follows a Software development life cycle
process. Different tasks are performed based on the SDLC framework during software
development. Developing and Maintaining software projects involves risk in each step. Most
enterprises rely on software and ignoring the risks associated with any phase needs to be
identified and managed/solved otherwise it creates unforeseen challenges for business.
Before analyzing different risks involved in software development, Let's first understand
what is risk and why risk management is important for a business.
 The following are the types of risk in software development:

1. Schedule Risk : Schedule related risks refers to time related risks or project delivery
related planning risks. The wrong schedule affects the project development and delivery.
These risks are mainly indicates to running behind time as a result project development
doesn't progress timely and it directly impacts to delivery of project. Finally if schedule
risks are not managed properly it gives rise to project failure and at last it affect to
organization/company economy very badly. Some reasons for Schedule risks -

 Time is not estimated perfectly

 Improper resource allocation

 Tracking of resources like system, skill, staff etc

 Frequent project scope expansion

 Failure in function identification and its' completion

2. Budget Risk: Budget related risks refers to the monetary risks mainly it occurs due to
budget overruns. Always the financial aspect for the project should be managed as per
decided but if financial aspect of project mismanaged then there budget concerns will
 arise by giving rise to budget risks. So proper finance distribution and management are
required for the success of project otherwise it may lead to project failure. Some reasons
for Budget risks -

 Wrong/Improper budget estimation

 Unexpected Project Scope expansion

 Mismanagement in budget handling

 Cost overruns

 Improper tracking of Budget

3. Operational Risks : Operational risk refers to the procedural risks means these are the
risks which happen in day-to-day operational activities during project development due to
improper process implementation or some external operational risks. Some reasons for
Operational risks -

 Insufficient resources

 Conflict between tasks and employees

 Improper management of tasks

 No proper planning about project

 Less number of skilled people

 Lack of communication and cooperation

 Lack of clarity in roles and responsibilities

 Insufficient training

4. Technical Risks : Technical risks refers to the functional risk or performance risk which
means this technical risk mainly associated with functionality of product or performance
part of the software product. Some reasons for Technical risks -

 Frequent changes in requirement

 Less use of future technologies

 Less number of skilled employee

 High complexity in implementation

 Improper integration of modules

5. Programmatic Risks : Programmatic risks refers to the external risk or other
unavoidable risks. These are the external risks which are unavoidable in nature. These
risks come from outside and it is out of control of programs. Some reasons for
Programmatic risks -
 Rapid development of market

 Running out of fund / Limited fund for project development

 Changes in Government rules/policy

 Loss of contracts due to any reason

Risk Mitigation, Monitoring, and Management (RMMM) plan

RMMM Plan:
A risk management technique is usually seen in the software Project plan. This can be
divided into Risk Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all
works are done as part of risk analysis. As part of the overall project plan project manager
generally uses this RMMM plan.

In some software teams, risk is documented with the help of a Risk Information Sheet (RIS).
This RIS is controlled by using a database system for easier management of information i.e
creation, priority ordering, searching, and other analysis. After documentation of RMMM
and start of a project, risk mitigation and monitoring steps will start.

Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.

1. Finding out the risk.

2. Removing causes that are the reason for risk creation.

3. Controlling the corresponding documents from time to time.

4. Conducting timely reviews to speed up the work.

Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.

3. To collect data for future risk analysis.

4. To allocate what problems are caused by which risks throughout the project.

Risk Management and planning :

It assumes that the mitigation activity failed and the risk is a reality. This task is done by
Project manager when risk becomes reality and causes severe problems. If the project
manager effectively uses project mitigation to remove risks successfully then it is easier to
manage the risks. This shows that the response that will be taken for each risk by a manager.
The main objective of the risk management plan is the risk register. This risk register
describes and focuses on the predicted threats to a software project.

Example:

Let us understand RMMM with the help of an example of high staff turnover.

Risk Mitigation:

To mitigate this risk, project management must develop a strategy for reducing turnover. The
possible steps to be taken are:

 Meet the current staff to determine causes for turnover (e.g., poor working conditions,
low pay, competitive job market).

 Mitigate those causes that are under our control before the project starts.

 Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.

 Organize project teams so that information about each development activity is widely
dispersed.

 Define documentation standards and establish mechanisms to ensure that documents are
developed in a timely manner.

 Assign a backup staff member for every critical technologist.

Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager monitors
factors that may provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover, the following factors can be monitored:

 General attitude of team members based on project pressures.

 Interpersonal relationships among team members.

 Potential problems with compensation and benefits.

 The availability of jobs within the company and outside it.

Risk Management:

Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. Continuing the example, the project is well underway, and
a number of people announce that they will be leaving. If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team. In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed, enabling newcomers
who must be added to the team to "get up to the speed".

Drawbacks of RMMM:
 It incurs additional project costs.

 It takes additional time.

 For larger projects, implementing an RMMM may itself turn out to be another tedious
project.

 RMMM does not guarantee a risk-free project, infact, risks may also come up after the
project is delivered.
3.5 Project scheduling: Basic principle, scheduling techniques - CPM,
PERT
3.5 Project Scheduling
Project scheduling is the process of planning the sequence of project activities and allocating
resources and time to ensure timely completion of a project.

It is an important part of project management and helps in:

 Defining what needs to be done and when

 Determining critical tasks and dependencies

 Optimizing resource utilization

 Monitoring project progress

1. Basic Principles of Project Scheduling

1. Activity Identification
o Break the project into smaller, manageable tasks or activities.

2. Sequence of Activities

o Identify dependencies between tasks:

 Finish-to-Start (FS): Task B starts after Task A finishes

 Start-to-Start (SS), Finish-to-Finish (FF), Start-to-Finish (SF)

3. Time Estimation

o Estimate duration for each task using historical data or expert judgment.

4. Resource Allocation
o Assign resources (people, equipment, materials) to each task.

5. Schedule Development

o Arrange tasks on a timeline, considering dependencies and resource constraints.

6. Monitoring & Control

o Track progress and adjust the schedule if needed.

2. Project Scheduling Techniques
Two classical techniques widely used
A. CPM (Critical Path Method)
1. Definition

The Critical Path Method (CPM) is a project scheduling technique used to:

 Determine the minimum time required to complete a project.

 Identify the critical activities that directly affect the project’s completion time.

CPM is deterministic, meaning that activity durations are considered fixed and known in
advance.

It was developed in the 1950s by DuPont for managing large-scale projects like chemical
plants and construction.

2. Key Concepts of CPM

1. Activity

o A task that consumes time and resources.

o Represented in a network diagram as an arrow (Activity-on-Arrow) or node

(Activity-on-Node).

2. Event / Milestone

o Marks the start or completion of an activity.

3. Duration

o The time required to complete an activity, usually measured in days or weeks.

4. Critical Path

o The longest path through the project network.

o Determines the minimum project duration.

o Any delay in a critical activity delays the whole project.

5. Slack / Float

o The amount of time an activity can be delayed without delaying the project.

o Types:
  Total Float: Maximum delay without affecting project completion

 Free Float: Maximum delay without affecting the start of successor

activities

3. Steps in CPM

Step 1: List all activities

 Identify all tasks required to complete the project.

Step 2: Determine dependencies

 Identify which activities depend on others.

Step 3: Draw the network diagram

 Activity-on-Arrow (AOA) or Activity-on-Node (AON) diagram showing sequence and

dependencies.

Step 4: Assign durations

 Assign fixed durations to all activities.

Step 5: Forward pass (Earliest Start and Finish)

 Calculate the Earliest Start (ES) and Earliest Finish (EF) times:

𝐸𝐹 = 𝐸𝑆 + 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛

 Forward pass starts from the first activity to the last.

Step 6: Backward pass (Latest Start and Finish)

 Calculate Latest Finish (LF) and Latest Start (LS) times:

𝐿𝑆 = 𝐿𝐹 − 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛

 Backward pass starts from the last activity to the first.

Step 7: Calculate float / slack

𝑇𝑜𝑡𝑎𝑙 𝐹𝑙𝑜𝑎𝑡 = 𝐿𝑆 − 𝐸𝑆 𝑜𝑟 𝐿𝐹 − 𝐸𝐹

Step 8: Identify critical path

 Activities with zero total float form the critical path.

4. CPM Calculations – Formulas

1. Earliest Finish (EF):

𝐸𝐹 = 𝐸𝑆 + 𝐴𝑐𝑡𝑖𝑣𝑖𝑡𝑦 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛

2. Latest Start (LS):

LS=LF−Activity Duration
3. Total Float (TF):

TF=LS−ES=LF−EF
4. Critical Path:

 The path where TF = 0 for all activities.

5. Example of CPM

Suppose a project has activities with the following dependencies and durations:

Activity Duration (Days) Predecessors

A 3 -

B 4 A

C 2 A

D 5 B, C

E 3 D

Step 1: Forward Pass (ES, EF)

 A: ES=0, EF=0+3=3

 B: ES=3, EF=3+4=7
 C: ES=3, EF=3+2=5

 D: ES=max(EF of B & C)=max(7,5)=7, EF=7+5=12

 E: ES=12, EF=12+3=15

Step 2: Backward Pass (LS, LF)

 E: LF=15, LS=15-3=12
 D: LF=LS of E=12, LS=12-5=7

 B: LF=LS of D=7, LS=7-4=3

 C: LF=LS of D=7, LS=7-2=5

 A: LF=min(LS of B & C)=min(3,5)=3, LS=3-3=0

Step 3: Calculate Float

 Float = LS - ES = LF - EF

Activity ES EF LS LF Float Critical?

A 0 3 0 3 0 Yes

B 3 7 3 7 0 Yes

C 3 5 5 7 2 No

D 7 12 7 12 0 Yes

E 12 15 12 15 0 Yes

Critical Path: A → B → D → E

 Minimum project duration = 15 days

6. Advantages of CPM

 Identifies critical activities that need close monitoring.

 Helps in minimum project completion time calculation.

 Useful for resource allocation and planning.

 Facilitates what-if analysis for schedule compression.

7. Limitations of CPM

 Assumes deterministic (fixed) durations, not suitable for uncertain projects.

 Requires detailed activity breakdown, which may not be available initially.

 Does not consider resource constraints inherently (needs resource leveling separately).
B. PERT (Program Evaluation and Review Technique)
1. Definition

PERT is a project scheduling and management technique that helps in planning, coordinating,
and controlling tasks in a project where activity durations are uncertain.

 Developed by the U.S. Navy in the 1950s for the Polaris missile project.

 PERT is probabilistic, meaning it considers uncertain or variable activity times instead of

fixed durations.

Purpose:

 Estimate project duration considering uncertainty.

 Identify the critical path and probability of completion within a given time.

2. Key Concepts of PERT

1. Activity – A task that consumes time and resources.

2. Event / Milestone – Marks the start or completion of an activity.

3. Network Diagram – Represents the sequence and dependencies of activities.

4. Time Estimates – PERT uses three time estimates for each activity:

o Optimistic Time (O): Minimum possible duration (if everything goes perfectly)

o Most Likely Time (M): Normal expected duration under typical conditions
o Pessimistic Time (P): Maximum possible duration (if problems occur)

5. Expected Time (TE) – Weighted average time of an activity:

TE=O+4M+P6TE = \frac{O + 4M + P}{6}TE=6O+4M+P

6. Variance of Activity (σ²) – Measures uncertainty in activity duration:

σ2=(P−O6)2\sigma^2 = \left(\frac{P - O}{6}\right)^2σ2=(6P−O)2

7. Critical Path – Longest path in the network based on expected times, determines
minimum expected project duration.
3. Steps in PERT

Step 1: Identify Activities and Milestones

 Break the project into tasks and define start/end points.

Step 2: Determine Dependencies

 Identify which tasks depend on others.

Step 3: Estimate Activity Times

 For each activity, determine O, M, P times.

Step 4: Draw Network Diagram

 Represent activities and dependencies in Activity-on-Node (AON) diagram.

Step 5: Compute Expected Time and Variance

 For each activity, calculate:

o Expected Time 𝑇𝐸 =

o Variance 𝜎 = ( )

Step 6: Identify Critical Path

 Sum expected times along each path to determine longest path = critical path.

Step 7: Compute Project Duration Probability (Optional)

 If 𝑇𝐸 = total expected time of critical path, and 𝜎 = sum of variances along critical
path, probability of completing project in time T can be calculated using Z-score:
𝑇 − 𝑇𝐸
𝑍=
𝜎
Then use normal distribution table to find probability y.

4. Advantages of PERT

 Handles uncertain activity durations.

 Provides expected project completion time.

 Identifies critical path and critical activities.

 Helps in risk analysis and probability assessment.

5. Limitations of PERT

 Requires accurate estimation of O, M, P times.

 Assumes activity durations are independent (may not always be true).

 Probabilistic approach can be complex for very large projects.

6. Example of PERT

Activity Predecessor O (days) M (days) P (days)

A - 2 3 4

B A 3 4 5

C A 1 2 3

D B, C 4 5 6

Step 1: Calculate Expected Time (TE)

TE=O+4M+P6TE = \frac{O + 4M + P}{6}TE=6O+4M+P

 A: TE = (2 + 4×3 + 4)/6 = 3
 B: TE = (3 + 4×4 + 5)/6 = 4

 C: TE = (1 + 4×2 + 3)/6 = 2

 D: TE = (4 + 4×5 + 6)/6 = 5

Step 2: Forward Pass / Identify Critical Path

 Path 1: A → B → D = 3 + 4 + 5 = 12

 Path 2: A → C → D = 3 + 2 + 5 = 10

Critical Path: A → B → D

 Expected project duration = 12 days

Step 3: Variance (Optional)

𝜎 =( )

 A: σ² = ((4-2)/6)² = (2/6)² = 0.111

 B: σ² = ((5-3)/6)² = 0.111

 D: σ² = ((6-4)/6)² = 0.111

 Variance along critical path = 0.111 + 0.111 + 0.111 = 0.333

 Standard deviation = √0.333 ≈ 0.577 days

This can be used to calculate probability of finishing within a certain time.
Difference between CPM and PERT
PERT (Program Evaluation Review
Feature CPM (Critical Path Method)
Technique)

Deterministic (fixed activity Probabilistic (uncertain activity

Nature
durations) durations)

Time-cost trade-off, focus on Planning and controlling projects

Purpose
critical activities with uncertain activity times

Three time estimates per activity:

Single fixed duration per
Time Estimates Optimistic (O), Most Likely (M),
activity
Pessimistic (P)

Longest path based on fixed Longest path based on expected

Critical Path
durations durations (TE)

Well-defined, repetitive
Research, development, R&D,
Project Type projects (construction,
uncertain projects
manufacturing)

More complex, uses probability and

Complexity Simpler calculations
statistics

Minimizing total project time Managing uncertainty, estimating

Focus
and identifying slack probability of project completion

Calculates total float and free Calculates expected time slack and
Slack / Float
float probability of delay

Projects where activity Projects where activity durations are

Usage
durations are known uncertain or variable

Mathematical Probabilistic network analysis using

Deterministic network analysis
Basis weighted averages

Easy to use, identifies critical Handles uncertainty, provides

Advantages
activities expected duration and risk analysis
 3.6 Project tracking: Timeline charts, Gantt charts
Project Tracking is the process of monitoring project progress against the planned schedule,
resources, and cost.

Purpose of Project Tracking:

 Ensure the project is progressing as planned

 Identify delays or issues early

 Adjust resources and schedules to keep the project on track

 Provide visibility to stakeholders about project status

Key Activities in Project Tracking:

1. Monitoring actual start and finish dates of tasks

2. Comparing planned vs actual progress

3. Updating project schedules and milestones

4. Identifying deviations and taking corrective actions

1. Timeline Charts
Definition:

 A timeline chart is a graphical representation of project milestones along a time axis.

 Shows start and end dates or key points in sequence.

Features:

 Activities are represented as points along a horizontal timeline

 Helps visualize project phases, milestones, and deadlines

 Provides a quick overview of progress and schedule adherence

Example of Timeline Chart ([Link]):

Explanation:

 Each milestone is shown along a horizontal time axis.

 Useful for a quick overview of important project events.

2. Gantt Charts

Definition:

 A Gantt chart is a type of bar chart that represents project activities against time.

 Named after Henry L. Gantt.

Features of Gantt Charts:

 Horizontal axis: Time (days, weeks, months)

 Vertical axis: Project tasks or activities

 Bars: Represent duration of tasks

 Progress tracking: Can show planned vs actual progress within the bars

 Dependencies: Modern Gantt charts can display task dependencies with arrows
 Advantages of Gantt Charts:

 Easy visual representation of project schedule

 Shows start and end dates, task duration, and progress

 Helps track critical tasks and milestones

 Useful for communicating status to stakeholders

Example of Gantt Chart ([Link]):

Explanation:

 section groups related tasks.

 :id, start-date, duration defines each task.

 Duration is in days (d).

 Can be shaded to show progress and optionally show dependencies.

References:
1. Geeks For Geeks
2. GateSmashers(Youtube)
3. Diagrams Geeks for Geeks and [Link]