Software Project

Management

2
 What is management?
• The organization and coordination of the activities of a
business in order to achieve defined objectives.
Planning
Organizing
Staffing
Directing
Monitoring
Controlling
Innovating
representing
Conventional Project Management
• Non Routine tasks
• Planning is Required
• Specific Objectives are not met
• Project is large or complex
• Work carried out in several phases
 Why do software projects fail?
• People begin programming before they understand
the problem
– Everyone likes to feel that they’re making progress
– When the team starts to code as soon as the project
begins, they see immediate gains
– When problems become more complex (as they always
do!), the work gets bogged down
– In the best case, a team that begins programming too
soon will end up writing good software that solves the
wrong problem

5
 Why do software projects fail?
• The team has an unrealistic idea about how
much work is involved.
– From far away, most complex problems seem
simple to solve
– Teams can commit to impossible deadlines by
being overly optimistic and not thinking through
the work
– Few people realize the deadline is optimistic until
it’s blown

6
 Why do software projects fail?
• Defects are injected early but discovered late.
– Projects can address the wrong needs
– Requirements can specify incorrect behavior
– Design, architecture and code can be technically flawed
– Test plans can miss functionality
– The later these problems are found, the more likely they
are to cause the project to fail

7
 Why do software projects fail?
• Programmers have poor habits – and they don’t feel
accountable for their work.
– Programmers don’t have good control of their source code
– Code written by one person is often difficult for another
person to understand
– Programmers don’t test their code, which makes
diagnosing and fixing bugs more expensive
– The team does not have a good sense of the overall health
of the project.

8
 Why do software projects fail?
• Managers try to test quality into the software.
– Everyone assumes that the testers will catch all of the
defects that were injected throughout the project.
– When testers look for defects, managers tell them they are
wasting time.
– When testers find defects, programmers are antagonized
because they feel that they are being personally criticized.
– When testers miss defects, everyone blames them for not
being perfect.

9
 How can we make sure that our projects
succeed?
• Make sure all decisions are based on openly shared
information
– It’s important to create a culture of transparency, where
everyone who needs information knows where to find it
and is comfortable looking at it.
– All project documents, schedules, estimates, plans and
other work products should be shared with the entire
team, managers, stakeholders, users and anyone else in
the organization who wants them.
– Major decisions that are made about the project should be
well-supported and explained.

10
 How can we make sure that our projects
succeed?
• Don’t second-guess your team members’
expertise
– Managers need to trust team members.
– Just because a manager has responsibility for a
project’s success, it doesn’t mean that he’s more
qualified to make decisions than the team
members.

11
 How can we make sure that our projects
succeed?
• Introduce software quality from the very
beginning of the project
– Review everything, test everything.
– Use reviews to find defects – but don’t expect the
review to be perfect.
– Use reviews to gain a real commitment from the
team.
– It’s always faster in the long run to hold a review
than it is to skip it.

12
 How can we make sure that our projects
succeed?
• Don’t impose an artificial hierarchy on the project
team
– All software engineers were created equal.
– A manager should not assume that programming is more
difficult or technical than design, testing or requirements
engineering.
– Managers should definitely not assume that the
programmer is always right, or the tester is always raising
false alarms.

13
 How can we make sure that our projects
succeed?
• Remember that the fastest way through the project
is to use good engineering practices
– Managers and teams often want to cut important tasks –
especially estimation, reviews, requirements gathering and
testing.
– If it were faster to build the software without these
practices, we would never use them.
– Every one of these practices is about saving time and
increasing quality by planning well and finding defects
early. Cutting them out will cost time and reduce quality.

14
Solution by SPM Plan
 Activities by SPM
• The Feasibility Study
– To Check the Business Case
• Planning
– Outline of The Whole project
• Project Execution
– Design , Implementation phases
 Is
wo it
Go rth
ing

Feasibility Study

Plan

How do
we do it

Execute

Do it
 Project Goals(1)
• Goals are specific targets that are intended to be
reached at a given point in time. Goals must be
measurable.

• SMART Goals
S Specific
M Measurable
A Achievable
R Realistic
T Time-related
 Project Goals(2)
• Examples of Project Goals
• Project goals usually focus on the critical success factors
of cost, scope, time, quality and safety.
• For example:
– Deliver the product scope as described in the System
Requirements Specification at or below the budgeted cost
by exact date.
– Maintain a defect density of one defect per thousand lines
of code in system level testing.
– Deliver a compelling user experience that raises customer
approval ratings by 100% over the previous product release.
 Types of project plan
Plan Description
Quality plan Describes the quality procedures and standards that will be
used in a project.
Validation plan Describes the approach, resources and schedule used for
system validation.
Configuration Describes the configuration management procedures and
management plan structures to be used.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required.
Staff development Describes how the skills and experience of the project team
plan. members will be developed.
 Project planning process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop
 The project plan
• The project plan sets out:

– The resources available to the project;

– The work breakdown structure;
– A schedule for the project.
 Project plan structure
• Introduction.

• Project organisation.

• Risk analysis.

• Hardware and software resource requirements.

• Work breakdown structure.

• Project schedule.

• Monitoring and reporting mechanisms.

 Activity organization
• Activities in a project should be organised to produce tangible
outputs for management to judge progress.

• Milestones are the end-point of a process activity.

• Deliverables are project results delivered to customers.

• The waterfall process model allows for the straightforward

definition of progress milestones.
 Milestones in the Requirement
Elicitation process

ACTIVITI
ES

Feasibility Requirements Prototype Design Requir ements

stud y analysis de velopment stud y specification

Feasibility User Evalua tion Architectural System

report requirements repor t design requirements

MILESTONES
 Project scheduling
• Split project into tasks and estimate time and resources
required to complete each task.

• Organize tasks concurrently to make optimal

use of workforce.

• Minimize task dependencies to avoid delays

caused by one task waiting for another to complete.

• Dependent on project managers intuition and experience.

 Scheduling problems
• Estimating the difficulty of problems and hence the cost of
developing a solution is hard.

• Productivity is not proportional to the number of people

working on a task.

• Adding people to a late project makes it later because of

communication overheads.

• The unexpected always happens. Always allow contingency in

planning.
 The project scheduling process

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities char ts

Software Activity charts

requirements and bar char ts
 Bar charts and activity networks
• Graphical notations used to illustrate the project schedule.

• Show project breakdown into tasks. Tasks should not be too

small. They should take about a week or two weeks.

• Activity charts show task dependencies and the critical path.

• Bar charts show schedule against calendar time.

 Project activities are the basic
planning element
• A duration in calendar days or months.
• An effort estimate, which reflects the number of
person-days or person-months to complete the work.
• A deadline by which the activity should be
completed.
• A defined endpoint. This represents the tangible result
of completing the activity.
• This could be a document, the holding of a review
meeting, the successful execution of all tests, etc.
Task durations and dependencies

Activity Duration (days) Dependencies

T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
 Activity network
1 4/7 /03 15 da ys
15 da ys
M1 T3
8 days T9
T1 5 days 4/8/03 2 5/8/03
2 5/7 /03
4/7 /03 T6 M4 M6
M3
star t 2 0 days 7 days
15 days
T7 T11
T2
25/7 /03 11/8/03 5/9/03
10 da ys 10 days
M2 M7 M8
T4 T5 15 da ys

T10 10 days
1 8/7 /03
T12
M5

2 5 days
T8 Finish
19/9/03
 Activity timeline
4/7 11/7 18/7 2 5/7 1/8 8/8 1 5/8 22/8 2 9/8 5/9 12/9 1 9/9

Star t
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish
 Staff allocation
4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5