Outline of talk
In this introduction the main questions to
be addressed will be:
–What is software project management? Is
it really different from ‘ordinary’ project
management?
–How do you know when a project has
been successful? For example, do the
expectations of the customer/client match
those of the developers?
What is a project?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works
scheme”
Longmans dictionary
Key points above are planning and size of
task
Jobs versus projects
‘Jobs’ – repetition of very well-defined and well
understood tasks with very little uncertainty
‘Exploration’ – e.g. finding a cure for cancer: the
outcome is very uncertain
‘Projects’ – in the middle!
Characteristics of projects
A task is more ‘project-like’ if it is:
• 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
Are software projects really
different from other projects?
Not really! …but…
• Invisibility
• Complexity
• Conformity
• Flexibility
make software more problematic to build than other engineered
artefacts.
Activities covered by project
management
Feasibility study
Is project technically feasible and worthwhile from a business point of
view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along
The software development life-
cycle (ISO 12207)
ISO 12207 life-cycle
Requirements analysis
–Requirements elicitation: what does the client need?
–Analysis: converting ‘customer-facing’ requirements into
equivalents that developers can understand
–Requirements will cover
• Functions
• Quality Resource
• constraints i.e. costs
ISO 12207 life-cycle
• Architecture design
o Based on system requirements
o Defines components of system: hardware, software,
organizational
o Software requirements will come out of this
• Code and test
o Of individual components
• Integration
o Putting the components together
ISO12207 continued
• Qualification testing
o Testing the system (not just the software)
• Installation
o The process of making the system operational
o Includes setting up standing data, setting system parameters,
installing on operational hardware platforms, user training etc
• Acceptance support
o Including maintenance and enhancement
Some ways of categorizing
projects
Distinguishing different types of project is
important as different types of task need different
project approaches e.g.
• Information systems versus embedded systems
• Objective-based versus product-based
What is management?
This involves the following activities:
• Planning – deciding what is to be done
• Organizing – making arrangements
• Staffing – selecting the right people for the job
• Directing – giving instructions
continued…
What is management?
(continued)
• Monitoring – checking on progress
• Controlling – taking action to remedy hold- ups
• Innovating – coming up with solutions when problems
emerge
• Representing – liaising with clients, users, developers
and other stakeholders
Setting objectives
• Answering the question ‘What do we have to do to have a success?’
• Need for a project authority
o Sets the project scope
o Allocates/approves costs
• Could be one person - or a group
o Project Board
o Project Management Board
o Steering committee
Objectives
Informally, the objective of a project can be defined by completing the
statement:
The project will be regarded as a success if………………………………..
Rather like post-conditions for the project
Focus on what will be put in place, rather than how activities will be
carried out
Objectives should be SMART
• S – specific, that is, concrete and well-defined
• M – measurable, that is, satisfaction of the objective can be
objectively judged
• A – achievable, that is, it is within the power of the individual
or group concerned to meet the target
• R – relevant, the objective must relevant to the true purpose
of the project
• T – time constrained: there is defined point in time by which
the objective should be achieved
Goals/sub-objectives
These are steps along the way to achieving the objective. Informally,
these can be defined by completing the sentence…
Objective X will be achieved IF the following goals are all achieved
A……………
B……………
C…………… etc
Goals/sub-objectives continued
Often a goal can be allocated to an individual. Individual may have the
capability of achieving goal, but not the objective on their own e.g.
Objective – user satisfaction with software product
Analyst goal – accurate requirements
Developer goal – software that is reliable
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:
• Repeat business – they buy further products from us
• Number of complaints – if low etc etc
Stakeholders
These are people who have a stake or interest in the project
In general, they could be users/clients or
developers/implementers
They could be:
o Within the project team
o Outside the project team, but within the same organization
o Outside both the project team and the organization
The business case
Benefits of delivered project must outweigh costs
• Costs include:
o Development
o Operation
• Benefits
o Quantifiable
o Non-quantifiable
Management Control
Management Control
• Data – the raw details
e.g. ‘6,000 documents processed at location X’
• Information – the data is processed to produce
something that is meaningful and useful
e.g. ‘productivity is 100 documents a day’
• Comparison with objectives/goals
e.g. we will not meet target of processing all
documents by 31 st March
Management Control
(Continued)
• Modelling – working out the probable outcomes of
various decisions
e.g. if we employ two more staff at location X how
quickly can we get the documents processed?
• Implementation – carrying out the remedial actions
that have been decided upon
Key points in lecture
• Projects are non-routine - thus uncertain
• The particular problems of projects e.g. lack of
visibility
• Clear objectives are essential which can be objectively
assessed
• Stuff happens. Not usually possible to keep precisely
plan – need for control
• Communicate, communicate, communicate!
