01- Lecture 1

Software Project Management
Amarah Abdullah
Lecturer
School of Commerce and Accountancy
University of Management and Technology
Lahore
Books
• Book 1: 1. Bob Hughes and Mike

Cotterell , Software Project Management,
2005
• Book 2: Kathy Schwalbe, Information

Technology Project Management
• REVISED Sixth Edition
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
•Often forms part of a larger project

•Objectives and product characteristics may be
defined and achieved progressively
•Result may be the creation of one or several
units of a project
•Interrelation between activities may be 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?)
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?
• 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
19
• 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
20
• 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
21
• 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.
22
• 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.
23
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.
24
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.
25
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.
26
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.
27
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.
28

01- Lecture 1

Uploaded by

Copyright:

Available Formats

01- Lecture 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01- Lecture 1

Uploaded by

Copyright:

Available Formats

Software Project Management

• Book 1: 1. Bob Hughes and Mike

• Book 2: Kathy Schwalbe, Information

(Lockyer and Gordon,

•Often forms part of a larger project

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.