Software Project

Project – Planned activity (English dictionary)

A project is a temporary and one-time endeavor

undertaken to create a unique product or service,
which brings about beneficial change or added
value. Projects have start and end dates.

1
Project Characteristics
 Non – routine tasks are involved
 Planning is key
 Existence of specific objectives to create a

specific product
 Predetermined time span
 Work involves a number of specialisations
 Work executed in phases
 Available resources are constrained
 Project is usually large or complex

2
Software Project Management (SPM)
 Project Management (PM) - the planning, monitoring, and
control of the people, process, and events that occur as
software evolves from a preliminary concept to full
operational deployment. (Pressman, 2009)

 General PM definition applies to SW project management

but sw projects are:
◦ Invisible
◦ More complex
◦ Highly flexible - associated with a high degree of change

 SPM - The Process of making visible what is invisible

3
 PM Principles
The Triple Constraints

 Time

 Cost

 Scope

Manage these or they will

manage you!

4
The Triple Constraints
The PM Triple constraints are interdependent
and create quite a balancing act for Project
Managers.
The time constraint is the amount of time

available to complete a project. All projects

have a defined period.
The cost constraint is the budgeted amount

available for the project.

The scope constraint is what must be done to

produce the project's end result – the system

you need to meet your requirements.
5
The Triple Constraints
 These three constraints are often competing constraints:
• increased scope typically means increased time and increased
cost,
• a tight time constraint could mean increased costs and reduced
scope,
• a tight budget could mean increased time and reduced scope, or
managing the project over a longer period of time to take
advantage of various funding opportunities without a loss of
continuity.
 Project management is about providing the tools and
techniques that enable the project team (not just the
project manager) to organize their work to meet these
constraints.

6
Revised 6 Constraints of Projects
What can What is
go wrong? expected?

Scope
Risk What is time
frame?

Who & what is

required? Schedule
6 Project
constraints
Resources What is the
budget?

Cost
How close does
Quality
outcome match
expectations?

7
Project 6 Constraints
• If the necessary resources are not available, time to
deliver will increase. This may also increase
project cost, because alternate resources if available,
may be more expensive than planned.
• If  quality of deliverable goes down,
more resources may be required. This increases
the cost (additional resources) and effort to fix the
faulty deliverable. This will also increase the time to
deliver.
• If scope creep happens on the project, it will result in
increased time, cost, resources and potentially
reduced quality. And thus increased risk on delivery.
8
Reasons of Project Failure
Derived from the Standish Group Report (1995)

 Weak business case – is this just an impulse or is

there a real need for the project? If so, prove it

 Lack of Senior Management support (resources)

Senior management commitment is vital as these
are the decision-makers .You have to have their
buy-in or else you set yourself up for failure.
Every project has to have a CHAMPION (Senior
management sponsor)

9
Reasons of Project Failure
 Inadequate project planning will always present
problems. You have to know what you are
doing, why you are doing it, who’s doing what,
when it needs to be done and how much it will
cost

 Lack of user involvement - users will be the staff

who are going to daily interact with the system
once its implemented. You need their expertise
and their buy-in to make the project a success.
Leave them out and be ready to meet resistance
to any change you try to implement.

10
Reasons of Project Failure
 New /unfamiliar technology is always a risk. It
raises risks and fears. You always need to
manage risks. So, do your homework in your
planning phase to make sure the chosen solution
will work for you! You may want to perform a
proof of concept and test it before deciding to
move forward into full blown design and
development.

 Unclear objectives- requirements must be defined

(no one can read your mind), clear (what do you
really mean), and concise (I want this to do this).

11
Reasons of Project Failure
 Unrealistic expectations

 Unrealistic time frames

 Changing requirements & specifications

12
 SW Project Management
Key Questions
o
How must people, process, and problem be
managed during a software project?
o
How can software metrics be used to manage a
software project and the software process?
o
How does a software team generate reliable
estimates of effort, cost, and time?

13
 SW Project Management
Key Questions
o
What techniques can be used to assess the risks
that can have an impact on project success?
o
How does a software project manager select a
set of software engineering tasks?
o
How is a project schedule created?
o
Why are maintenance and re-engineering so
important for both software engineering managers
and practitioners?

14
Types of Software Projects
i. Information system versus embedded
system :- IS interfaces with the organisation
while embedded system interfaces with the
machine
ii. Service versus product oriented : service
oriented is designed to meet certain
objectives, while a product is designed as
per customer specification.
NB most product oriented start off as service
oriented, build a product to deliver the service

15
 Project Management Stakeholders
All the people with interest in the project –
positive and negative

May be:-
Internal to the team – under the control of the
project manager
External to the team but within the same
organisation - project manager has to negotiate
commitment of the people involved
External to both the team and organisation – e.g.
customers or contractors to carry out tasks in the
project, relationship with such is based on a legally
binding contract.
Check “Theory W” for handling stakeholders by Boem and Ross
16
 Software Project Management
Principles
The Four P’s of Projects
•
People — the most important element of a
successful project
•
Product — the software to be built
•
Process — the set of framework activities and
software engineering tasks to get the job done
•
Project — all work required to make the product a
reality

17
 The People
The importance of the people is indicated by the
People Capability Maturity Model (People-CMM)
Every organization needs to continually improve
its ability to attract, develop, motivate, organize,
and retain the workforce needed to accomplish its
strategic business objectives.
The people - CMM defines these key practices for
s/w teams:-
• staffing,
• communication and coordination,
• work environment,
• performance management,
• training,
• compensation, 18
 Software Project Teams
Considerations in Software Project Team Selection:-

•
the difficulty of the problem to be solved
•
the size of the resultant program(s) in lines of code or
function points
•
the time that the team will stay together (team lifetime)
•
the degree to which the problem can be modularized
•
the required quality and reliability of the system to be
built
•
the rigidity of the delivery date
•
the degree of sociability (communication) required for
the project
19
 Team Leader
The MOI Model
Motivation - The ability to encourage (by “push
or pull”) technical people to produce to their best
ability.
Organization - The ability to mould existing
processes (or invent new ones) that will enable
the initial concept to be translated into a final
product.
Ideas or innovation - The ability to encourage
people to create and feel creative even when they
must work within bounds established for a
particular software product or application. 20
 The Software Product

System objectives and scope should be established, alternative
solutions should be considered, and technical and management
constraints should be identified at project onset.

Objectives form a basis for :-
Accurate cost estimates
Effective assessment of risk,
Realistic breakdown of project tasks,
Formulation of a manageable project schedule

Scope identifies the primary data, functions, and behaviours that
characterize the product, and binds these characteristics in a
quantitative manner.

Alternatives enable managers and developers to select a “best”
approach, given the constraints imposed by delivery deadlines,
budgetary restrictions, personnel availability, technical interfaces
and other factors.
21
 The Process

Provides the framework from which a comprehensive
plan for software development can be established.

A number of different task sets—tasks, milestones,
work products, and quality assurance points—enable
the framework activities to be adapted to the
characteristics of the software project and the
requirements of the project team.

Umbrella activities—e.g. software quality assurance,
software configuration management, and
measurement—overlay the process model.

Umbrella activities are independent of any one
framework activity and occur throughout the process.
22
 The Project

The aim in a project is to:

Avoid a set of common warning signs,

Understand the critical success factors that lead
to good project management, and

Develop a common sense approach for planning,
monitoring, and controlling the project.

23
 PM for Success

Start on the right foot. Seek to understand the
problem that is to be solved and set realistic
objectives and expectations. Build the right team
and give it the autonomy, authority, and
technology needed to do the job.

Maintain momentum. Provide incentives to keep
turnover of personnel to an absolute minimum.
Emphasize quality in every task performed, and
avoid senior management interference with team
performance
24
 PM for Success

Track progress. Progress must be tracked as work
products

(e.g., models, source code, sets of test cases) are
produced and approved (using technical reviews) as
part of a quality assurance activity.

Make smart decisions. Aim at keeping everything
simple. Whenever possible, decide to use commercial
off-the-shelf software or existing software components
or patterns, decide to avoid custom interfaces when
standard approaches are available, decide to identify
and then avoid obvious risks, and decide to allocate
more time than you think is needed to complex or risky
tasks 25
 PM for Success

Conduct a post -mortem analysis. Establish a
consistent mechanism for extracting lessons
learned for each project. Evaluate the planned
and actual schedules, collect and analyse
software project metrics, get feedback from team
members and customers, and record findings in
written form.

26