Software Project Management - Unit I
# Unit I: Introduction to Software Project Management
---
1.1 Project Definition
# What is a Project?
A **project** is a **temporary endeavor** undertaken to create a **unique product, service, or
result**. It has a defined beginning and end, and is carried out to meet specific goals and objectives
within constraints of time, cost, and scope.
# Key Characteristics of a Project:
- **Temporary** – Has a definite start and end date
- **Unique** – Every project produces something that hasn't been done before in exactly the same
way
- **Progressive Elaboration** – Developed in steps; details become clearer as the project moves
forward
- **Goal-Oriented** – Driven by specific objectives
- **Resource Constrained** – Uses limited people, money, time, and equipment
# What is Software Project Management (SPM)?
SPM is the **art and science of planning and leading software projects**. It is a sub-discipline of
project management where software projects are planned, implemented, monitored, and controlled.
# Why is SPM Important?
- Software projects frequently **fail** due to poor planning
- Helps control **cost overruns** and **schedule delays**
- Ensures **quality** and **customer satisfaction**
- Manages **risks** effectively
# Common Causes of Software Project Failure:
- Unrealistic deadlines
- Poorly defined requirements
- Lack of proper planning
- Inadequate testing
- Poor communication
---
1.2 Project Versus Flow Type Work
This is a very important distinction. Work in organizations can be categorized as either **Project
Work** or **Flow (Operational/Routine) Work**.
| Feature | **Project Work** | **Flow Type Work (Operations)** |
|---|---|---|
| **Nature** | Temporary | Ongoing / Repetitive |
| **Output** | Unique product/service | Standardized, repetitive output |
| **Duration** | Defined start & end | Continuous, no fixed end |
| **Goal** | Achieve specific objective | Sustain the business |
| **Team** | Temporary team formed | Permanent workforce |
| **Examples** | Building a new website, Developing new software | Customer support, Payroll
processing |
| **Change** | Embraces change for goals | Resists change to maintain stability |
| **Risk** | Higher risk due to novelty | Lower risk due to repetition |
| **Resource use** | Variable | Stable and predictable |
# Key Insight:
> Once a project is completed successfully, it **may become a flow/operational activity**. For
example, developing a payroll system is a *project*, but running the payroll every month is *flow
work*.
---
1.3 Project Lifecycle
The **Project Lifecycle** defines the **phases** a project goes through from start to finish. It
provides a structured framework for managing the project.
# Generic Project Lifecycle Phases:
```
Initiation → Planning → Execution → Monitoring & Controlling → Closure
```
# 1. Initiation Phase
- Project is formally **authorized**
- Project Charter is created
- Stakeholders are identified
- Feasibility study is done
- Key question: *"Should we do this project?"*
# 2. Planning Phase
- Detailed **project plan** is developed
- Scope, schedule, cost, resources are defined
- Risk management plan is created
- WBS (Work Breakdown Structure) is developed
- Key question: *"How will we do this project?"*
# 3. Execution Phase
- Actual **work is performed**
- Team is managed and directed
- Deliverables are produced
- Communications are managed
- Key question: *"Are we doing the work?"*
# 4. Monitoring & Controlling Phase
- **Tracks and reviews** project progress
- Performance is measured against the plan
- Corrective actions are taken if needed
- This phase runs **parallel to execution**
- Key question: *"Are we on track?"*
# 5. Closure Phase
- Project is formally **closed**
- Final deliverables are handed over
- Documentation is completed
- Lessons learned are recorded
- Key question: *"Did we achieve our goals?"*
# Software Project Lifecycle (Specific):
In software engineering, this maps to development models like:
- **Waterfall Model** – Sequential phases
- **Iterative/Incremental Model** – Repeated cycles
- **Agile Model** – Short sprints (covered in Unit V)
# Characteristics Across the Lifecycle:
- **Cost and staffing** – Low at start, peaks during execution, drops at closure
- **Risk** – High at the beginning, decreases as project progresses
- **Stakeholder influence** – Highest at start, lowest at end
- **Cost of changes** – Increases as the project progresses
---
1.4 Processes and Knowledge Areas in Project Management (PM)
# Process Groups in PM (PMBOK-based):
There are **5 Process Groups** (these are similar to lifecycle phases but focus on *processes*, not
*phases*):
| Process Group | Description |
|---|---|
| **Initiating** | Define and authorize the project |
| **Planning** | Establish scope, objectives, and course of action |
| **Executing** | Coordinate people and resources to carry out the plan |
| **Monitoring & Controlling** | Track, review, and regulate progress |
| **Closing** | Finalize all activities and formally close the project |
---
# 10 Knowledge Areas in PM (as per PMBOK):
These are **areas of expertise** required throughout the project:
| # | Knowledge Area | Key Focus |
|---|---|---|
| 1 | **Integration Management** | Coordinating all aspects of the project |
| 2 | **Scope Management** | Defining what is and isn't part of the project |
| 3 | **Schedule Management** | Managing the timeline |
| 4 | **Cost Management** | Budgeting and controlling costs |
| 5 | **Quality Management** | Ensuring deliverables meet requirements |
| 6 | **Resource Management** | Managing people and physical resources |
| 7 | **Communications Management** | Ensuring proper information flow |
| 8 | **Risk Management** | Identifying and responding to risks |
| 9 | **Procurement Management** | Managing contracts and vendor relationships |
| 10 | **Stakeholder Management** | Engaging and managing stakeholder expectations |
# Interaction of Process Groups and Knowledge Areas:
Each knowledge area involves processes from multiple process groups. For example, **Risk
Management** has processes in Planning (identify risks), Executing (implement risk responses),
and Monitoring & Controlling (monitor risks).
---
1.5 Build or Buy Decision
This is a **critical decision** in software project management — whether to **build** software
in-house or **buy/license** an existing solution.
# Factors to Consider:
Build (In-House Development):
**Advantages:**
- Full **customization** to exact needs
- **Competitive advantage** — unique product
- No dependency on vendor
- Complete **control** over features and updates
**Disadvantages:**
- **Higher cost** and longer time
- Requires skilled internal team
- **Risk** of project failure
Buy (Off-the-Shelf / COTS — Commercial Off-The-Shelf):
**Advantages:**
- **Faster deployment** — already built
- **Lower cost** (shared development costs)
- Vendor provides **support and updates**
- Proven and tested product
**Disadvantages:**
- May **not fit** exact requirements
- **Vendor lock-in** — dependent on third party
- Limited **customization**
- Licensing fees
# Decision Criteria:
| Factor | Build | Buy |
|---|---|---|
| Unique requirements | ■ | ■ |
| Time constraints | ■ | ■ |
| Budget | High | Lower |
| Core business function | ■ | ■ |
| Standard functionality | ■ | ■ |
# Hybrid Approach: **Buy and Customize**
Many organizations adopt a middle ground — buy a base product and customize it to meet specific
needs.
# Other Options:
- **Outsource** – Hire a third party to build it
- **Open Source** – Use free available software and customize
- **SaaS (Software as a Service)** – Subscribe to cloud-based software
---
1.6 Work Breakdown Structure (WBS) and its Types
# What is WBS?
A **Work Breakdown Structure (WBS)** is a **hierarchical decomposition** of the total scope of
work to be carried out by the project team. It breaks the project into **smaller, manageable
components** called **Work Packages**.
> WBS is a *deliverable-oriented* grouping of project work.
# Key Principles:
- **100% Rule** – WBS must capture ALL work (nothing more, nothing less)
- Each level is a decomposition of the level above
- Lowest level is called a **Work Package**
- Each work package can be assigned, estimated, and tracked
# WBS Example for a Software Project:
```
Software Project
■■■ 1. Requirements
■ ■■■ 1.1 Gather Requirements
■ ■■■ 1.2 Document Requirements
■ ■■■ 1.3 Review & Approval
■■■ 2. Design
■ ■■■ 2.1 System Architecture
■ ■■■ 2.2 UI/UX Design
■■■ 3. Development
■ ■■■ 3.1 Frontend Development
■ ■■■ 3.2 Backend Development
■■■ 4. Testing
■ ■■■ 4.1 Unit Testing
■ ■■■ 4.2 System Testing
■■■ 5. Deployment
■■■ 5.1 Server Setup
■■■ 5.2 Go-Live
```
# Benefits of WBS:
- Provides **clear scope** definition
- Helps in **cost estimation** and **scheduling**
- Assigns **accountability** to team members
- Helps identify all **deliverables**
- Reduces risk of **scope creep**
# Types of WBS:
1. Deliverable-Based WBS (Most Common)
- Organized around **project deliverables**
- Focuses on *what* will be produced
- Recommended by PMBOK
- Example: Website Project → Homepage, Login Module, Database, Deployment
2. Phase-Based WBS
- Organized around **project phases** or lifecycle
- Focuses on *when* work will be done
- Example: Requirements → Design → Development → Testing → Deployment
3. Organization-Based WBS (OBS — Organizational Breakdown
Structure)
- Organized around **departments or teams**
- Shows who does what
- Useful for resource management
4. Hybrid WBS
- Combines **deliverable + phase** structure
- Top levels are phases, lower levels are deliverables
# WBS Dictionary:
A **WBS Dictionary** accompanies the WBS and provides detailed descriptions for each
component — including scope, cost estimates, assigned resources, and acceptance criteria.
---
1.7 Introduction to PMBOK
# What is PMBOK?
**PMBOK** stands for **Project Management Body of Knowledge**. It is a **standard guide**
published by the **Project Management Institute (PMI)** that provides best practices, terminology,
and guidelines for project management.
> Think of PMBOK as the *"Bible of Project Management"*.
# Purpose of PMBOK:
- Provides a **common language** for project managers worldwide
- Defines **standard processes** for managing projects
- Serves as a reference for the **PMP (Project Management Professional)** certification exam
- Applicable across **all industries**, including software
# PMBOK Structure:
The PMBOK Guide (6th Edition — commonly referenced) is organized around:
- **5 Process Groups** (Initiating, Planning, Executing, Monitoring & Controlling, Closing)
- **10 Knowledge Areas** (as listed in 1.4)
- **49 Processes** in total
# Key Concepts in PMBOK:
Project Charter:
- Formal document that **authorizes the project**
- Created during Initiation phase
- Contains: project objectives, scope, milestones, budget, stakeholders
Project Management Plan:
- Master document describing **how the project will be executed, monitored, and controlled**
- Contains subsidiary plans (scope plan, schedule plan, cost plan, etc.)
Baselines in PMBOK:
| Baseline | Description |
|---|---|
| **Scope Baseline** | Approved scope statement + WBS |
| **Schedule Baseline** | Approved project schedule |
| **Cost Baseline** | Approved budget |
> Any changes to baselines must go through formal **Change Control**.
# PMBOK vs Agile:
PMBOK is traditionally associated with **predictive (waterfall)** approaches, but the latest editions
(6th, 7th) also incorporate **agile and hybrid** approaches.
# PMBOK 7th Edition (Latest):
Shifts from **process-based** to **principle-based** thinking:
- 12 Project Management Principles (e.g., Stewardship, Collaboration, Value, Systems Thinking)
- 8 Project Performance Domains (e.g., Stakeholders, Team, Development Approach, Planning)
---
1.8 Program and Portfolio Management
These represent **higher levels** of management above individual projects.
# The Three Levels:
```
Portfolio Management (Strategic Level)
Program Management (Tactical Level)
Project Management (Operational Level)
```
---
# Project:
- A **temporary** endeavor with a specific goal
- Example: Develop a mobile banking app
# Program:
A **program** is a group of **related projects** managed in a coordinated way to obtain benefits not
available from managing them individually.
**Key Features:**
- Projects within a program are **interdependent**
- Focus on **benefits realization** rather than deliverables
- Managed by a **Program Manager**
**Example:** A "Digital Transformation Program" might include:
- Project 1: Build customer portal
- Project 2: Migrate data to cloud
- Project 3: Train employees on new systems
# Portfolio:
A **portfolio** is a collection of **projects, programs, and operations** managed together to achieve
**strategic business objectives**.
**Key Features:**
- May include **unrelated** projects/programs
- Focus on **strategic alignment** and **ROI**
- Managed by a **Portfolio Manager**
**Example:** A bank's IT portfolio might include:
- Digital Banking Program
- Risk Management Project
- Core Banking Upgrade Program
- ATM Modernization Project
---
# Comparison Table:
| Feature | Project | Program | Portfolio |
|---|---|---|---|
| **Focus** | Specific deliverable | Benefits from related projects | Strategic objectives |
| **Duration** | Fixed | Longer than projects | Ongoing |
| **Scope** | Narrow and defined | Broader | Widest |
| **Manager** | Project Manager | Program Manager | Portfolio Manager |
| **Success Measured By** | On-time, on-budget delivery | Benefits realized | Strategic value and
ROI |
| **Change** | Minimized | Expected | Continuously evaluated |
# Program Management Benefits:
- **Coordinated planning** across projects
- **Shared resources** and reduced duplication
- Better **risk management** across related projects
- Alignment to a **common goal**
# Portfolio Management Benefits:
- Ensures all projects **align with strategy**
- Helps in **prioritization** of projects
- Optimizes **investment decisions**
- Balances **risk across the portfolio**
---
■ Chapter 1 — Quick Revision Summary
| Topic | Key Point |
|---|---|
| Project | Temporary, unique, goal-oriented endeavor |
| Project vs Flow Work | Projects are temporary & unique; flow work is ongoing & repetitive |
| Project Lifecycle | Initiation → Planning → Execution → Monitoring → Closure |
| Process Groups | 5 groups: Initiating, Planning, Executing, M&C, Closing |
| Knowledge Areas | 10 areas covering all PM domains |
| Build or Buy | Decision based on cost, time, customization, and uniqueness |
| WBS | Hierarchical decomposition of work; types: deliverable, phase, org, hybrid |
| PMBOK | PMI's standard guide; 5 process groups + 10 knowledge areas + 49 processes |
| Program | Group of related projects managed for combined benefit |
| Portfolio | Collection of all projects/programs aligned to strategic goals |
---
Ready for **Chapter 2: Project Planning and Project Management Tools** whenever you are! ■