SW Project Management

 
 SW Project Management
 SW project has two main activity dimensions :
– SW engg and
– Project mgt

 Engg dimension
– building the system
– focuses on design, test, coding etc

 PM dimension
– Planning and controlling the engg activities
– meet project goals for cost, schedule and quality
 Symptom of Software Crisis

 In US.
 About US$250 billion spent per year on application
development
 Of this, about 50% is wasted due to the projects getting
abandoned or reworked; this in turn because of not
following best practices and standards
 In UK.
 Government IT expenditure running at about £14bn per year
 30 % failure reported .
 Standish Group's - CHAOS Summary
2009
 32% of all projects succeeds
– delivered on time,
– on budget,
– with required features and functions

 44% challenged - late, over budget, and/or with less than the required
features and functions and

 24% failed
– cancelled prior to completion or
– delivered and never used.
 Standish Group's - CHAOS Summary
2003

 Project success rates - 34% (16% rate in 1994).

 Project failures 15%

 Challenged projects 51%.

 Another view
• Uncertainty about the actual figures.

• Software crisis exaggerated. Most software projects deliver.

• Overall project failure rate, remains high for an applied discipline.

• Projects executed successfully, still fails

 Why Software Projects fail.
Study Asia/ Europe and US
 Lack of top mgt commitment
 Lack of user commitment
 Lack of user involvement
 End user expectations violated
 Technology failure

[Project Management]
 Why Software Projects fail.
Some reasons :-
 requirements incomplete, ambiguous, inconsistent, not
measurable
 success criteria ill-defined or undefined ( not maintainable,
unreliable, badly human-engineered, etc.)
 poor planning
 casual estimates of resource requirements

[Project Management]
 Why Software Projects fail.
Some more reasons :-

 casual estimates of milestones

 poor design techniques
 haphazard testing strategies
 accidental organizational structures
 ill-defined accountability
 unavailability of the right tools
 poor visibility of project progress

[Project Management]
 Why Software Projects fail.
Still some more reasons :-
 incompetent manpower
 poor management discipline
 ineffective environment
 hazy process definition
 accuracy and definitiveness that apply to physical sciences
do not apply to software
 ……
[Project Management]
Lack of Skills and
proven approach to
Project Mgt
 Project
A project is a temporary endeavour undertaken to
accomplish a unique purpose.
Project attributes
 Unique purpose - specified product to be developed
 Temporary (non-routine)
 Planning is required
 Requires resources
 Has several phases
 Involves uncertainty
 May be large or complex
 Progressive elaboration
 Pre determined time span
Hazy boundary between non-routine job and a routine job
 Software Project Vs Others

 Invisibility

 Complexity

 Conformity

 Flexibility
 Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
 What is Project Management?

 Application of knowledge, skills, tools and techniques to project

activities to meet project requirements

 Meet triple constraint by balancing

– project scope,

– time, and

– cost goals
 The Triple Constraint of Project
Management

Successful project mgt

meeting all three goals

scope, time, and cost
&
satisfying the project’s
sponsor!
Activities Covered by SPM
Project Management Framework
 Knowledge Areas(KA)
KA - key competencies of PM.
 9 KA.
4 core KA (scope, time, cost, and quality)---lead to
specific project objectives

4 facilitating KA (human resources, communication,

risk, and procurement management)--- process
through which the project objectives are achieved

• One KA (project integration management) affects and

is affected by all of the other KA

All knowledge areas are important!

Project Management Tools and Techniques

PM tools and techniques :

Project charter, scope statement, and WBS (scope)

Gantt charts, network diagrams, critical path analysis,

and critical chain scheduling (time)

Cost estimates and earned value management (cost)

Sample Gantt Chart
Sample Network Diagram in
Microsoft Project
What is a process?

 Set of ordered tasks

 A series of steps involving
 activities,
 constraints, and
 resources
that produce an intended output
 SW Project Life Cycle
• Requirement Analysis
– Starts with requirements elicitation
– Will relate to the system as a whole
• Specs. Specs of the customer translated into technical
requirements
• Design
– Architectural Design.
• At system level, decide which all processes will be carried
out by the user & which can be computerised.
• Design of system architecture forms an input to the
development of SW requirements.
• A second architectural design maps SW requirements to
SW components
– Detailed Design. Each SW component made up of No of SW
units/ modules that can be coded.
 SW Project Life Cycle contd/-

• Code

• Verification & Validation

– In C or Java or an application builder
– Unit Testing
– Verification test – product right?
– Validation testing – right product?

• Integration Testing
– Individual components collected together and tested, at the SW level
or at system level itself.
 SW Project Life Cycle contd/-

• Installation- process of making the new system operational

– Setting up standing data
– Set up system parameters
– Install SW onto HW platform
– User Training

• Maintenance & Support

– Resolve problems if any
– Correct errors
– Extension/ Improvements

NB: SW maintenance as a series of SW projects ( as in many ICT

projects)
 Example
• HUTCH ESSAR has been taken over by Vodafone. Payroll of Hutch
employees now generated by Infix Inc.
• Infix Inc continues Payroll generation at a monthly charge of Rs 25 lakhs.
• Vodafone Mgt feels it would be cheaper to do this themselves. Get a OTS
payroll package and do it themselves.

• Q1. What would be the main stages of the project to convert to independent
payroll processing by Vodafone?

• Q2. How will the project differ when the software is written from scratch?
 Example

• Project Evaluation
• Planning
• Requirement Elicitation & Analysis
• Specs
• Package Evaluation & Selection
• Verification & validation
• Implementation
• Maintenance & Support
 Project Authority
 Project Stg Committee or Project Control Board: Overall responsible
for setting, monitoring and modification of project objectives.

 PM runs the project day to day Vs PSC oversees.

 Objectives & Goals

Q3. Discuss the Objectives & Goals of the Vodafone Project

Objective:
To carry out payroll processing at reduced costs while
maintaining current scope & Q o S

Goals:
Transfer entire Payroll processing by 31 May
Test bed by 31 Jan
Concurrent running: Feb to May
 Objectives & Goals
Objectives set to guide and motivate individuals/ groups of
staff

An effective objective for an individual : within his control

Objectives are broken down to goals - examples?

Well defined objectives:

 Specific: concrete and well defined

 Measurable: successful or not?
 Achievable
 Relevant to the purpose of the project
 Time constrained
 Objectives Vs Products
Projects distinguished by aim –
 produce a product or
 meet an objective
Product...specified by client , hence he justifies the product
Objective driven
 Several ways of achieving
 Eg new IS to improve service to users
 Level of service that is target would be subject of an agreement
rather than internal characteristics
Many SW have two stages
 First Objectives driven => recommended course of action
 Next stage actually creates SW product
 Project Authority
 Project Steering Committee or Project Control Board:
Overall responsible for setting, monitoring and modification of
project objectives.

 PM runs the project day to day Vs PSC oversees.

 Stakeholders
Who have a stake or interest in the project.. May be direct or indirect

 be identified as early as possible

 set up communication channels right from start.
 Differing motivation and objectives.
– End-users : ease of use
– Managers : staff savings
 Stakeholders
Stakeholders might be
– internal to project team,
– external to project team
– internal to the organization
– external

 SHs - different objectives : a successful project manager will have to recognize

and reconcile them.

A project manager should be a good communicator and negotiator.

 Stakeholders
Stakeholders include:
The project sponsor
The project manager
The project team
Support staff
Customers
Users
Suppliers
Opponents to the project
Advantages of Using Formal Project Mgt
 Better control of financial, physical, and human resources

 Improved customer relations

 Shorter development times

 Lower costs

 Higher quality and increased reliability

 Higher profit margins

 Improved productivity

 Better internal coordination

 Higher worker morale (less stress)

 What Helps Projects Succeed?

 Executive support Firm basic requirements

Formal methodology
 User involvement

Reliable estimates
 Experienced PM

Proper planning
 Clear business objectives

Competent staff
 Minimized scope

 Standard software infrastructure

 Project and Program Managers
 Project managers work with project sponsors, a project team, and
other people involved in a project to meet project goals

 Program: group of related projects managed in a coordinated way to

obtain benefits and control not available from managing them
individually

 Program managers oversee programs and often act as bosses for

project managers
 Project Success
There are several ways to define project success

The project met scope, time, and cost goals

The project satisfied the customer/sponsor

The results of the project having met its main objective, such as:
 making or saving a certain amount of money,
 providing a good return on investment, or
 simply making the sponsors happy
 Boehm’s
Boehm’s
Top
Top Ten
Ten
Industrial
Industrial
Software
Software Metrics
Metrics
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Finding and fixing a software

problem after delivery of the

1
product is 100 times more
expensive than defect removal
during requirements and early
design phases.
 Effort
Effort to
to Repair
Repair Software
Software
(when
(when defects
defects are
are detected
detected at
at different
different stages)
stages)

20 20
18
relative effort to repair 16
14
12
10
8
6 5
4
2 2
0.5 1
0 0.15
Design

Acc. Test
Unit test
Reqmts

Maintenance
Coding
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Nominal software
development schedules can be

2 compressed up to 25% (by

adding people, money, etc.)
but no more.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Maintenance costs twice what

3 the development costs.

 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Development and maintenance

4 costs are primarily a function of

the size.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Variations in humans account for

5 the greatest variations in

productivity.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

The ratio of software to

hardware costs has gone from

6 15:85 in 1985 and continues to

grow in favour of software as
the dominant cost.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Only about 15% of the

7 development effort is in coding.

 Distribution
Distribution of
of Effort
Effort
Across
Across Phases
Phases

10
25 5
Testing 45
15 40
Coding
20 30
Design 15
45
30
20
Analysis
Traditional Structured CASE environment
environment techniques

Analysis Design Coding Testing

 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Applications products cost three

times as much per instruction as

8 individual programs; system

software products cost nine times
as much.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

Walkthroughs catch 60% of the

9 errors.
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10
Many software processes obey a
Pareto distribution.

20% 80%
modules cost
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10
Many software processes obey a
Pareto distribution.

20% 80%
modules errors
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10
Many software processes obey a
Pareto distribution.

20% 80%
modules cost
to fix
 Boehm’s
Boehm’s TopTop Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10
Many software processes obey a
Pareto distribution.

20% 80%
modules exec time
 Boehm’s
Boehm’s Top
Top Ten
Ten
Industrial
Industrial Software
Software Metrics
Metrics

10
Many software processes obey a
Pareto distribution.

20% 80%
tools use
 Laws of Project Management.
 No major project is ever installed on time, within budget
and with the same staff that started it.
Yours will not be the first.

 Projects progress quickly until they become 90 % complete.

Then onwards they remain 90 % complete.

[Project Management]
 Laws of Project Management..
 Fuzzy project objectives are advantageous.

They let you avoid the embarrassment of estimating the

corresponding costs.

 When things are going well, something will go wrong. When

things just can’t get worse, they will.

When things appear to be going better, you certainly must have

overlooked something.
[Project Management]
 Laws of Project Management...
 If project is allowed to change freely,

Then the rate of change will exceed the rate of progress.

 No system is ever completely debugged.

Attempts to debug a system inevitably introduce new bugs that
are even harder to find and fix.

[Project Management]
 Laws of Project Management….
 A carelessly planned project will take three times longer
than expected.

A carefully planned one will take twice as long.

 Project teams detest documenting and progress reporting.

It vividly manifests their lack of progress.

[Project Management]
Thank You