MODULE 4

Introduction to Software Project Management

Introduction
The main questions to be addressed will be:

What is software project management? Is it really different

from ‘ordinary’ project management?

How do you know when a project has been successful? For

example, do the expectations of the customer/client match those
of the developers?
Why is Software Project Management Important?
1. Money: A lot of money is at stake with ICT (Information and
Communication Technology) projects.
2. Projects are not always successful.
3. The reason for these project shortcomings is often the management
of projects.
What is a Project?
Project is a temporary effort to create a unique product or service. Projects usually
include constraints and risks regarding cost, schedule or performance outcome.
A project is Planned set of interrelated tasks to be executed over a fixed period and
within certain cost and other limitations.
Characteristics of projects
• Non-routine tasks are involved
• Planning is required
• Specific objectives are to be met or a specific product is to be created
• The project has a predetermined time span
• Work is carried out for someone other than yourself
• Work involves several specialisms
• People are formed into a temporary work group to carry out the task
• Work is carried out in several phases
• The resources that are available for use on the project are constrained
• The project is large or complex
Software Projects versus other types of Projects

• Invisibility – With physical artifacts, measuring progress is easy as it can be

seen/ felt. However with Software, progress is not immediately visible.
• Complexity – Software products are, generally, more complex than other
engineering artifact of same value.
• Conformity - Software system has to conform to the requirement of human
clients.
• Flexibility - It is easier to change/ modify software systems to meet changing
organizational/ product requirement as compared to other engineering artifacts;
it may not be possible to modify a physical artifact at all.
Activities covered by project management
Feasibility study
Is project technically feasible and worthwhile from a business point of view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along
The software development life-cycle (ISO 12207)
Requirements analysis
• Requirements elicitation: what does the
client need?
• Analysis: converting ‘customer-facing’
requirements into equivalents that
developers can understand
• Requirements will cover
• Functions
• Quality
• Resource constraints i.e. costs
• Architecture design
• Based on system requirements
• Defines components of system: hardware, software, organizational
• Software requirements will come out of this
• Code and test
• Of individual components
• Integration
• Putting the components together
• Qualification testing
• Testing the system (not just the software)
• Installation
• The process of making the system operational
• Includes setting up standing data, setting system parameters, installing on operational
hardware platforms, user training etc
• Acceptance support
• Including maintenance and enhancement
Plans, Methods and Methodologies
A plan for an activity must be based on some idea of a method of work.
• Analyze the requirements for the software.
• Devise and write test cases that will check that each requirement has been
satisfied.
• Create test scripts and expected results for each test case.
• Compare the actual results and the expected results and identify discrepancies.
While a method relates to a type of activity in general, a plan takes that method
and convert it to real activities, identifying each activity:
• Its start and end dates
• Who will carry it out
• What tools and materials – including information – will be needed
The output from one method might be the input to another. Group of methods or
techniques are often grouped into methodologies such as object oriented design.
Some ways of categorizing software projects
Changes to the characteristics of software projects
Compulsory v/s Voluntary users
Information Systems v/s Embedded Systems
Software Products v/s Services
Outsourced Projects
Object Driven Development
Project Charter
- is an important high level document that authorizes the starting of a project and use of the required
resources.
- It outlines the project objectives, deliverables and the resources required.
- Also documents the aspects that are out of scope, and identifies the main stakeholders, their roles
and responsibilities.
- Document is used for all types of projects.
- Is signed and issued by a member of the top management of the company who also takes up the
role of the sponsor of the project.
- Serves as a guiding document for all activities concerning the project.
- The project manager refers to the project charter while planning the project.
Typical it contains the following:
1. Overall objectives of the project and the broad items that are within the scope of the project and
those that are out of scope.
2. The time schedule in terms of the start date and the expected end date.
3. The important stakeholders and their responsibilities towards the project.
4. Overview of the resources that will be needed for the project & the overall budget.
Stakeholders
These are people who have a stake or interest in the project, they could be users/clients or
developers/implementers.
Categorized as:
1. Internal to the project team – they will be under the direct managerial control of the project leader.
2. External to the project team but within the same organization.
3. External to both the project team and the organization.
Setting Objectives
Objectives should define what the project team must achieve for project success.
Different stakeholders have different motivations, the project objectives identify the shared intentions
for the project.
Objectives focus on the desired outcomes of the project rather than tasks within it – they are the post
condition of the project.
It could be written as a set of statements following the opening words ‘the project will be a successful
if…’
A project authority needs to be explicitly identified within overall authority over the project.
A project steering committee (project management board) with overall responsibility for setting,
monitoring and modifying objectives.
Sub objectives and goals:
Objectives should be SMART
S – Specific, that is, concrete and well-defined.

M –Measurable, that is, satisfaction of the objective can be objectively judged.

A –Achievable, that is, it is within the power of the individual or group

concerned to meet the target.

R – Relevant, the objective must relevant to the true purpose of the project.

T – Time constrained: there is defined point in time by which the objective

should be achieved.
Problems with Software Projects
• Lack of standards
• Lack of up-to-date documentation
• Preceding activities not completed on time – including late delivery of equipment
• Lack of communication between users and technicians
• Lack of communication leading to duplication of work
• Lack of commitment – especially when a project is tied to one person who then
moves
• Narrow scope of technical expertise
• Changing statutory requirements
• Changing software environment
• Deadline pressure
• Lack of quality control
• Remote management
• Lack of training.
Project Success and Failure

The project plan should be designed to ensure projects success by preserving the
business case for the project.
There are two objectives in the project plan
1. Project
2. Buisness
The project objectives are the targets that the project team is expected to achieve
The following deliverings
3. The agreed functionality
4. The required level of quality
5. On time
6. Within budget
1.15 Management Control
Software Development and project Management life cycles
Project Management Life Cycle
1.Project initiation
2.W5HH principle
3.Project bidding
• Request for quotation
• Request for proposal
• Request for information
4.Project planning

5.Project Execution
1.17 Traditional versus Modern Project management practices

1. Planning Incremental delivery

2. Quality management
3. Change management
4. Requirement management
5. Release management
6. Risk management
7. Scope management