Software Project Management

Lecturer: Ushna Khalil

Department: Computer Science & IT
 Distribution
 Mid term
 Final Term
 Announced Quiz/Surprised Quiz
 Assignments/ Class Activity
 Semester Project
 Books

• Book 1: 1. Bob Hughes and Mike

Cotterell , Software Project Management,
2005

• Book 2: Kathy Schwalbe, Information

Technology Project Management
• REVISED Sixth Edition
 Course Web Link

Slate
 This Lecture
• Introduction
– What is a project?
– The project management process
 A Project
A unique process, consisting of a set of
coordinated and controlled activities with start
and finish dates, undertaken to achieve an
objective conforming to specific requirements
including constraints of time, cost and
resources

(Lockyer and Gordon, 1996)

 A Project
• Unique process
• Coordinated and controlled activities
• Start and finish dates
• To achieve an objective
• Specific requirements
• Constraints of time, cost and resources
 Project Characteristics
• Non-routine
• Planned
• Aiming at a specific target
• Work carried out for a customer
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex
 Project Factors
• Size of the project
– Budget/costs, Size of team, Size of product
• Complexity
• Industry in which it is carried out
– Civil engineering
– Manufacturing
– IS/IT
 Classifying Projects (Lock, 1996)
• Civil Engineering
– Realisation phase is outdoors, large capital(investment) =
many contractors = communication headaches
• Manufacturing Projects
– Development of specialised hardware, physical design
• Management Projects
– Projects that do not result in a produced piece of hardware
(including software projects?)
• Research Projects
– Include a higher element of risk (including software
projects?)
 Measures of effectiveness
How do we know that the goal or objective has been achieved?
By a practical test, that can be objectively assessed.

e.g. for user satisfaction with software product:

• 1-Repeat business – they buy further products from us

• 2-Number of complaints – if low etc etc

 All Projects Should Have:
• Project plan
• Time frame
• Product specification
• Statement of required quality
• Budget
• Cost plan
• Identification of areas of ambiguity
• Risk evaluation and responses
 Introduction
• What is a project?
• The project management
process
• Project management information
systems
 Process Overview
• A project is broken down into stages
• Each stage in turn will be broken down into
smaller and more manageable tasks
• It is important to include planning as part of
the project management process
 Four Phase Model
• Lockyer (1996) describes a four phase model
of the project process
– Conception - assess the feasibility of the project
– Development - prepare the project plan
– Realisation - carry out the plan
– Termination - close the project
 Conception

Can it be done?

Yes or No?

Conception
Development
Realisation
Termination
 Conception ≈ Feasibility
• It is possible that we will
reject the project!
 Development
• As the organisation is now committed to the
project it must:
– Appoint a project manager
– Assemble project team
– Draw up a detailed plan of work

Conception
Development
Realisation
Termination
 Realisation
• A reporting system is required to keep
everyone informed:
– Team, top management, customers etc.
• A log is also kept of problems and how they
were resolved

Conception
evelopment
Realisation
Termination
 Termination
• Uses the project log to evaluate the
project and the process and indicate:
– The success/failure of methods used
– How team members performed
– How reliable suppliers were

Conception
evelopment
Realisation
Termination
 Termination
• Capital equipment that was used for the
project is now likely to be redundant
• Termination also involves getting rid of such
equipment as profitably as possible

Conception
evelopment
Realisation
Termination
 Why do Software projects Fail?
• In order to manage a successful software project, we must understand what
can go wrong (so that problems can be avoided) and how to do it right.
• Following signs depict that a software project is in jeopardy:
– Software people don't understand their customer's needs.
– The product scope is poorly defined.
– Changes are managed poorly.
– The chosen technology changes.
– Deadlines are unrealistic.
– Users are resistant.
– Sponsorship is lost [or was never properly obtained).
– The project team lacks people with appropriate skills.
– Managers [and practitioners) avoid best practices and lessons learned.
 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 delayed.
– In the best case, a team that begins programming too soon
will end up writing good software that solves the wrong
problem

23
 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 too optimistic and not thinking through the
work

24
 Why do software projects fail?
• Defects are injected early but discovered late.
– 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

25
 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.

26
 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 annoyed
because they feel that they are being personally criticized.
– When testers miss defects, everyone blames them for not
being perfect.

27
 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.

28
 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.

29
 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.

30
 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.

31
 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.

32