MODULE 4

1.1 Introduction

Project management is the process of planning, organizing, and overseeing the execution of
a project to achieve specific goals within a defined timeframe and budget.

1.2 Why is Software Project Management Important?

1. Financial Impact: A significant amount of money is invested in ICT projects. For

instance, in the UK, the government spent £2.3 billion on ICT contracts in 2002-2003,
which was more than on road contracts (£1.4 billion). Mismanagement of these
projects can result in financial losses, affecting funding for essential sectors like
healthcare.

2. Project Failures: Many projects fail to meet expectations. A 2003 study by the
Standish Group found that only a third of ICT projects were successful, with 82%
being late and 43% exceeding their budget.

3. Management Issues: One of the main reasons for project failures is poor project
management. Factors like lack of skills and ineffective risk management approaches
contribute to these shortcomings.

1.3 What is a Project?

Dictionary definitions of ‘project’ include:

o ‘A specific plan or design’

o ‘A planned undertaking’
o ‘A large undertaking

Project management emphasizes that it involves planned activities, especially for non-
routine tasks. Planning is crucial, even for uncertain or exploratory projects, but should be
seen as provisional. Routine tasks, on the other hand, require less planning since they are
well-understood.
Key characteristics of projects include:

1. Non-routine tasks: Projects involve tasks that are not performed regularly.

2. Planning: A project requires planning to determine how tasks will be carried out.

3. Specific objectives: Projects aim to meet specific goals or create a product.

4. Predetermined time span: Projects have a defined start and end time.

5. External work: Projects are often carried out for someone other than the individual
team members.

6. Specialized work: Multiple areas of expertise are involved.

7. Temporary work groups: A project team is formed temporarily to complete the task.

8. Multiple phases: Projects progress through different stages.

9. Resource constraints: Projects have limited resources.

10. Large or complex: Projects tend to be more difficult as they increase in size or
complexity.

1.4 Software Projects versus Other Types of Projects

Unique challenges in software project management, as identified by Fred Brooks:

1. Invisibility: Unlike physical projects (e.g., building a bridge), where progress is visible,
software development's progress is not immediately apparent. Software project
management involves making this invisible progress visible.
 2. Complexity: Software products are more complex per unit of cost compared to other
engineered products. The level of complexity in software increases significantly as
more features are added.

3. Conformity: Engineers working with physical materials like cement and steel follow
consistent physical laws, while software developers must adhere to human-driven
requirements. These requirements can be inconsistent due to factors like poor
communication, organizational flaws, or lapses in decision-making.

4. Flexibility: Software's ease of modification is seen as an advantage, but it can also be

a challenge. Software must adapt to changes in the physical or organizational systems
it interacts with, often leading to frequent updates or adjustments.

1.5 Contract Management and Technical Project Management

1. In-house projects: The users and developers are part of the same organization, so
they work closely together to develop the software.

2. Outsourced projects: Organizations often hire external developers for ICT

development. In this case, the client organization appoints a project manager to
oversee the contract and ensure the project stays within budget and on schedule.
The project manager does not focus on the technical details, such as estimating the
effort for writing software components.

1.6 Activities Covered by Software Project Management

Typical processes involved in a software project:

1. Feasibility Study:

o This is the first step where it’s assessed if the software project is worth
pursuing. The goal is to understand if the project has a valid business case.

o Information is gathered about the needs and requirements of the proposed

software.

o The study also estimates the cost of development and operational expenses,
along with the benefits the system will provide.
 o For larger systems, the feasibility study itself could be a small project, with its
own plan.

2. Planning:

o If the feasibility study shows the project is viable, planning starts.

o For large projects, planning doesn’t happen all at once. An outline plan is
made for the entire project, with detailed planning for the first stage.

o As the project progresses, new information becomes available, which allows

for better planning of later stages.

3. Project Execution:

o Once planning is done, the project moves into execution, which involves
design and implementation.

o Design: Making decisions about what the product will look like (e.g., user
interface and internal architecture).

o Planning: Defining the activities needed to create the product.

o The distinction between design and planning can be unclear because design
decisions influence the detailed planning of tasks.

Software Development Activities (ISO 12207 Standard):

1. Requirements Analysis:
 o This is the process of gathering and understanding the needs of the users and
stakeholders. It includes:

 Functional requirements: What the system should do (e.g.,

dispatching an ambulance).

 Quality requirements: How well the system should perform (e.g.,

transaction time).

 Resource requirements: Budget and application development costs.

2. Architecture Design:

o The system needs to be broken down into components that fulfill the
requirements. These components can be software, hardware, or work
processes.

o Software developers cannot work in isolation; they need to consider how the
new system will interact with existing systems (legacy systems).

o The design process ensures that the system architecture supports both
software and hardware components.

3. Detailed Design:

o The software is broken down into smaller units that can be coded and tested
individually.

o Detailed designs for each unit are made at this stage.

4. Code and Test:

o This involves writing the actual code for each software unit and conducting
initial testing to debug and ensure proper functionality.

5. Integration:

o After individual components are tested, they are combined and tested
together to check if they meet the overall system requirements.
 o Integration may also involve combining software with hardware platforms
and testing how users interact with the system.

6. Qualification Testing:

o The entire system, including all software components, is rigorously tested to

ensure it fulfills all the original requirements.

7. Installation:

o This step involves making the software operational. It includes setting up

data, installing the software onto hardware, and providing user training to
ensure everything works smoothly.

8. Acceptance Support:

o After the system is installed, support is provided to address any issues, correct
errors, and implement agreed-upon improvements or extensions.

9. Software Maintenance:

o Software maintenance is considered a series of smaller projects that involve

fixing bugs, improving the system, and updating it as needed.
1.7 Plans, Methods and Methodologies

1. Method:

o A method refers to a general approach or process used for performing a

specific activity. For example, testing software involves a series of steps, like
analyzing requirements, writing test cases, creating test scripts, and
comparing actual results with expected results.

o It’s a broad idea of how the activity is performed, without details on when or
how the activity will actually happen in the project.

2. Plan:
 o A plan takes the method and turns it into a specific, actionable set of
activities. It provides concrete details for how the method will be applied,
such as:

 Start and end dates for each activity.

 Who will carry out the activity (responsible person/team).

 Tools and materials needed to complete the task (including

information, hardware, software, etc.).

o A plan is more practical and focused on executing the method, ensuring the
work progresses effectively.

Additionally, methods can be grouped into broader methodologies that integrate multiple
techniques. For example, object-oriented design is a methodology that encompasses various
methods to design and develop software.

1.8 Some Ways of Categorizing Software Projects

1. Compulsory vs. Voluntary Users:

o Compulsory users must use the system to perform essential tasks (e.g.,
recording a sale in a workplace system).

o Voluntary users may use the system by choice, like in computer games. It’s
harder to get clear requirements since users are not obligated to use the
system.

2. Information Systems vs. Embedded Systems:

o Information systems are designed to support office processes (e.g., a stock

control system).

o Embedded systems are designed to control machines or devices (e.g., air

conditioning systems). Some projects may involve both, like a stock control
system that also manages automated warehouses.

3. Outsourced Projects:
 o Sometimes parts of a project are outsourced to other companies for reasons
like lacking expertise or reducing costs. Outsourced projects are typically
smaller and have shorter timelines.

o Challenges of outsourced projects include managing the communication and

integration between the outsourced work and the main project.

o Indian software companies have gained a strong reputation for executing

outsourced software projects.

4. Objective-driven Development:

o Some projects are focused on meeting objectives rather than producing a

predefined product. For example, an organization may have a problem and
seek a solution through a specialist’s recommendation.

o Objective-driven projects often have two stages:

1. The first stage is a study or analysis to identify the problem and

suggest a solution (e.g., a new software system).

2. The second stage is the actual creation of the software based on the
identified requirements.

o This approach is common when user needs are unclear at the start, and an
external group is hired to propose a design, which is then approved before
proceeding with the full implementation.

1.9 Project Charter

1. Definition:
The Project Charter is a high-level document that authorizes the project’s existence and
provides the project manager with the authority to use resources.

2. Purpose:

o Establishes a formal agreement between stakeholders on what the project will

deliver.
 o Acts as a reference throughout the project lifecycle to ensure alignment with its
original goals.

3. Content of the Project Charter:

o Project Objectives: What the project aims to achieve.

o Scope: The boundaries of the project, i.e., what is included and excluded.

o Stakeholders: Identifies sponsors, customers, and other groups involved in or

affected by the project.

o Constraints: Outlines limitations such as budget, time, or resources.

o Risks: Highlights major anticipated risks.

o Milestones: Key dates or deliverables.

o Approval and Signatures: Authorization by stakeholders or senior management.

4. Significance in the Project Lifecycle:

o Aligns expectations of all parties involved.

o Ensures stakeholder buy-in at the start of the project.

o Acts as a control document to avoid scope creep or misaligned objectives.

1.10 Stakeholders

1. Stakeholder Definition: Stakeholders are individuals or groups with a vested interest in a

project. Their involvement is crucial for the project's success.

2. Stakeholder Categories:

o Internal Stakeholders: Part of the project team, under the project leader's direct
control.

o External but Internal to the Organization: Individuals within the organization but
outside the project team, e.g., users assisting with system testing. Their involvement
often requires negotiation.

o Completely External Stakeholders: Include customers, users, or contractors outside

the organization. Their relationship is typically governed by contracts.
 3. Skills Required for Project Leaders:

o Strong communication and negotiation skills to align stakeholder interests.

o Awareness of overlooked stakeholders, like departments providing essential but

assumed services.

4. Theory W: Boehm and Ross's "win-win" theory suggests creating scenarios where all
stakeholders benefit, increasing their commitment to the project.

5. Communication Plan: A recommended practice for coordinating stakeholders, outlining how

information will flow among all parties from the start of the project.

1.11 Setting Objectives

Project Objectives:

 Ownership and Financing: The stakeholders who own the project are those who
finance it and set its objectives. The objectives define what success looks like for the
project, which should focus on the desired outcomes rather than specific tasks.

 Objective Examples: Instead of vague statements like "build an e-commerce

website," a clearer objective could be "customers can order our products online."

 Multiple Routes to Success: Objectives are flexible and can be achieved in different
ways. The more possible routes to success, the better.

Stakeholder Roles:

 Project Authority: A steering committee, or project management board, typically

oversees the project, setting, monitoring, and adjusting objectives.

 Project Manager: The project manager runs the day-to-day operations but regularly
reports to the steering committee.

Sub-objectives and Goals:

 Achieving Objectives: To meet a larger objective, sub-objectives or goals must be

achieved first. These are smaller, manageable tasks that help the project reach its
bigger goal.
  Example of Sub-objective: If the overall goal is to reduce staff costs with a software
application, a sub-objective for developers could be to keep development costs
within budget.

SMART Objectives:

 SMART is an acronym for a method of setting well-defined objectives:

o Specific: Clear and concrete objectives, not vague goals like "improve
customer relations."

o Measurable: There should be a way to measure success. For example,

"reduce customer complaints" is measurable, unlike "improve customer
relations."

o Achievable: The objective must be achievable by the responsible individual or

group.

o Relevant: The objective must align with the overall purpose of the project.

o Time-Constrained: There should be a defined timeline for achieving the

objective.

Measures of Effectiveness:

 Effectiveness Measures: These are practical ways to check if objectives have been
met. For example, “mean time between failures” (MTBF) could be used to measure a
system's reliability after it’s operational.

 Predictive Measures: During development, predictive measures can help assess

effectiveness. For instance, finding many errors during code inspections might
predict future reliability issues.

1.12 The Business Case

1. Purpose: The business case ensures that the project’s efforts and costs are worthwhile
relative to the benefits it delivers.

2. Cost–Benefit Analysis:
 o A detailed evaluation conducted during the project’s feasibility study.

o Quantifies costs (e.g., development expenses) and benefits (e.g., increased revenue
or efficiency).

o Highlights the importance of timely project completion to maximize benefits.

3. Business Model:

o Explains how the project will generate its claimed benefits.

o Example: A web-based application enabling global customer orders increases sales,

revenue, and profit.

4. Maintaining the Business Case:

o Cost Control: Development costs must not exceed the projected value of the
benefits.

o Feature Assurance: Key system features should not be reduced to the point where
benefits are compromised.

o Timely Delivery: Delays should be avoided to prevent significant loss of potential

benefits.

1.13 Project Success and Failure

Project Success and Failure

1. Defining Success and Failure:

o Success is generally measured by achieving project objectives and ensuring the

business case holds true.

o A project might be a success for some stakeholders and a failure for others due to
differing interests.

2. Project vs. Business Objectives:

o Project Objectives: Delivering agreed functionality, quality, on time, and within

budget.

o Business Objectives: Ensuring benefits exceed costs, often influenced by external

factors (e.g., customer adoption).
 3. Possible Outcomes:

o A project can achieve its objectives but fail in business terms if the application
doesn't generate expected benefits (e.g., poor sales or lack of customer use).

o Conversely, a project over budget and delayed might still succeed in business if it
delivers long-term benefits.

4. Reducing Business Risks:

o Broader project management can incorporate activities such as:

 Market surveys.

 Competitor analysis.

 Focus groups and prototyping.

o These reduce business risks by addressing customer and market needs.

5. Sequencing of Projects:

o Projects should be seen as part of a sequence where earlier efforts build expertise
and reusable assets for later projects.

o Initial higher costs may be justified by long-term benefits, such as faster and cheaper
deployment in future projects.

6. Outsourcing vs. In-house Development:

o Outsourcing may reduce immediate costs but forfeits long-term benefits of technical
expertise and reusable code development.

7. Customer Relationship Management:

o Strong customer relationships across projects improve trust and repeat business.

o Retaining clients is more cost-effective than acquiring new ones, especially for
follow-up projects based on previous work.

1.14 What is Management?

Key Management Activities:

 Planning: Deciding what tasks need to be done.

  Organizing: Making arrangements and structuring the project.

 Staffing: Selecting the right people for the job.

 Directing: Giving clear instructions to the team.

 Monitoring: Tracking the progress of the project.

 Controlling: Taking corrective actions to address deviations from the plan.

 Innovating: Coming up with new solutions to challenges.

 Representing: Liaising with clients, users, developers, suppliers, and other

stakeholders.

Focus of Project Manager:

 The project manager’s primary focus is on planning, monitoring, and control. These
activities are carried out in three stages:

Stages of the Project:

1. Project Initiation:

o Initial project planning occurs after the feasibility study.

o Estimations are made for project parameters like cost, duration, and effort,
which help in planning subsequent activities.

2. Project Execution:

o The project is monitored and controlled during execution.

o Adjustments are made to the plan as more data becomes available and to
ensure progress aligns with the plan.

3. Project Closing:

o All tasks are completed and contracts closed.

Project Planning Activities:

The project manager carries out specific activities during the planning phase:

 Estimation:

o Estimating cost, duration, and effort is critical for scheduling and staffing.

 Scheduling:

o Based on effort and duration estimates, schedules for resources and

manpower are developed.

 Staffing:

o Organizing and planning the staffing requirements.

 Risk Management:

o Identifying, analyzing, and planning for risks.

 Miscellaneous Plans:

o Plans for quality assurance, configuration management, and other necessary

areas.

1.15 Management Control

Key Concepts in Project Management:

1. Setting Objectives and Data Collection:

 o The primary role of management is to establish clear objectives for a system
and track its performance.

o Data collection at lower levels (e.g., a branch processing documents) provides

raw information that needs to be processed into useful metrics for higher
management, such as processing percentages, averages, or estimated
completion dates.

2. Monitoring and Decision Making:

o Project managers track the progress of tasks against overall project goals. For
instance, if a branch is behind on completing a task by the target date, the
manager must make decisions to bring the branch back on track.

o Decisions might include reallocating staff, but these decisions require careful
consideration. For example, moving staff from one branch to another may
resolve one issue but potentially delay another branch.

3. Dynamic Project Plan:

o A project plan is not static; it evolves as the project progresses. The manager
must regularly review progress and adjust the plan to account for new
challenges or changes.

o Adjustments could involve rethinking resource allocation or addressing

unforeseen delays in other departments that impact project deadlines.

4. Execution vs. Planning:

o While planning is essential, the bulk of the time is spent executing the plan. A
well-thought-out plan forms the foundation of a successful project, but its
success largely depends on effective execution and adjustments along the
way.

o Plans should be adaptable, not rigid, and must be modified as new

information and challenges arise.
Software Development Life Cycle (SDLC)

The SDLC is a series of stages that developers follow to create software, and these stages guide the
development process from start to finish. The typical phases of SDLC include:

1. Requirements Analysis: Gathering and analyzing the requirements of the software.

2. Design: Creating the architectural and detailed design of the software.

3. Development: Writing the code based on the design.

4. Testing: Ensuring the software works as expected by conducting various tests.

5. Delivery: Deploying the software to the client or end users.

These stages are mainly focused on the technical aspects of software creation, ensuring the software
is functional and meets the specified requirements.

Project Management Life Cycle

In contrast, the Project Management Life Cycle focuses on managing the entire project, including the
software development phases, from a managerial perspective. The phases in this life cycle are:

1. Initiation: Defining the project and its objectives, including setting up the initial project
framework.
 2. Planning: Detailing how the project will be carried out, including timelines, resources, and
risk management.

3. Execution: Implementing the plan, which includes carrying out the actual software
development work.

4. Closing: Finalizing the project, ensuring all objectives are met, and closing it officially.

The project management life cycle runs in parallel to the SDLC and overlaps with it. The initiation
phase of project management is typically completed before the software development process
starts, so developers can begin their work with clear objectives and resources in place. The execution
phase of project management aligns with the development, testing, and delivery stages of SDLC,
where the focus is on tracking progress, managing resources, and addressing issues.

1.16 Project Management Life Cycle

1. Project Initiation:

o The project begins with concept development, where the scope, constraints,
and resources are understood.

o A feasibility study is conducted to determine financial and technical viability.

 o A business case is developed, and the project charter is written.

o The project manager is selected to start the planning phase.

o W5HH Principle (by Boehm): Boehm’s W5HH principle emphasizes answering

critical questions during the initiation phase to ensure the project’s success.
These questions are:

1. Why is the software being built? (Purpose)

2. What will be done? (Scope)
3. When will it be done? (Timeline)
4. Who is responsible for the function? (Team)
5. Where are they organizationally located? (Structure)
6. How will the job be done technically and managerially?
(Methodology)
7. How much of each resource is needed? (Resources)
o Different types of bidding techniques:
1. RFQ (Request for Quotation): This document is issued when the
organization has a clear understanding of the project’s scope and
invites vendors to submit quotations.
2. RFP (Request for Proposal): An RFP is issued when the organization
knows the general requirements but needs help determining the best
solution.
3. RFI (Request for Information): An RFI is issued when an organization
seeks information about vendors' capabilities.

2. Project Planning:

o The project manager creates several documents:

 Project Plan: Defines tasks and schedules, assigning resources.

 Resource Plan: Lists the manpower and equipment needed.

 Financial Plan: Documents the costs involved.

  Quality Plan: Specifies required quality standards and assurance
processes.

 Risk Plan: Identifies potential risks, prioritizes them, and includes

mitigation strategies.

3. Project Execution:

o The tasks from the project plan are carried out.

o Monitoring and control processes ensure the tasks are executed according to
the plan, and corrective actions are taken if deviations occur.

o The project plan may be updated to reflect changes or new risks.

o Quality checks are performed to ensure deliverables meet specifications.

o Once the execution phase is complete, the project closure phase begins.

4. Project Closure:

o All required deliverables are handed over to the customer with appropriate
documentation.

o Project resources are released, agreements with vendors are terminated, and
payments are settled.

o A post-implementation review is conducted to evaluate the project's success

and gather lessons learned for future projects.

1.17 Traditional versus Modern Project Management Practices

1. Planning:

 Traditional: Detailed, long-term planning before project execution. All project

activities are planned upfront, and deviations are discouraged.

 Modern: Adaptive, short-term planning with incremental delivery. Planning is

adjusted as the project progresses, focusing on evolving functionalities and
accommodating customer feedback.
2. Customer Feedback:

 Traditional: Customer feedback is limited after the requirements are finalized.

Changes after project initiation are rare and often discouraged.

 Modern: Customer feedback is actively solicited throughout the development

process. Requirements evolve based on continuous input from customers, and
changes are incorporated throughout the project.

3. Development Approach:

 Traditional: Development is done from scratch, with minimal reuse of existing

components or libraries.

 Modern: Emphasis on code reuse and tailoring existing products. Development often
involves modifying pre-built libraries or software, reducing time and cost.

4. Change Management:

 Traditional: Changes are difficult to incorporate once the project scope is defined.
Managing scope changes is often seen as a disruption.

 Modern: Change management (configuration management) is integral to the

process. The development approach supports frequent changes and iterations,
making version control and tracking essential.

5. Quality Management:

 Traditional: Quality is managed at the end of the project after the product is
developed, with a focus on meeting the initial specifications.

 Modern: Quality is an ongoing responsibility. The project manager tracks the quality
of intermediate deliverables and ensures that each iteration meets quality standards.

6. Project Duration:

 Traditional: Longer project durations with set milestones and deliverables.

 Modern: Compressed project durations with rapid application development (RAD)

models. Incremental delivery enables faster product release with evolving features.
7. Role of the Project Manager:

 Traditional: The project manager focuses on detailed planning, resource allocation,

and schedule adherence.

 Modern: The project manager is more flexible, focusing on adaptive planning, quality
management, customer relations, and facilitating iterative feedback cycles.