Which project management methodology? A guide for the perplexed.

Which project
management
methodology?
A guide for the perplexed.
BCS London (South) branch
Wednesday 6th May 2015
1

Because someone says so

To provide guidance to novices

To identify ‘best practice’

To impose a common approach
◦ Improves communication – common language
◦ Can add/change staff without massive retraining
◦ Simplifies project interfaces
Why project management
methods?
2

Ensures consistency of work – quality
does not depend purely on who does the
work

Quality benchmarks
◦ Encourage/enforce quality within your own
team
◦ Encourage/enforce it with contractors
Why project management
methods?
3
Orientation
Types
Examples
Personal (project
manager)
Bodies of Knowledge
PMI, APM
Projects
Standard procedures
PRINCE2
Processes
Project organisation
Waterfall, V-process
model, DSDM etc
Quality assessment
Organisations
Process quality
Product quality
CMMI, ISO 900x
ISO 9126
Kinds of ITPM standards
4
Focus on project manager:
Project management ‘Bodies of Knowledge’
5

PMI-BOK
Project Management Institute Body of Knowledge
A US-based PM professional body with individual
membership with a UK chapter
BOK can be seen as a syllabus
PMI runs examinations leading to PM professional
qualifications

APM-BOK
Association for Project Management
Similar to above but UK-based
Project manager - Bodies of
knowledge
6

BS 6079
Guide to Project Management
British Standard published by British Standards
Institution
No examinations/qualifications for this one

Note: all these are related to general PM
not just IT PM.
Bodies of knowledge - continued
7
Focus on project management
processes
8

PRINCE2
Emphasis on practical procedures and
information system needed to manage a
project
UK-based generic PM approach – but origins
in IT
Although focused on procedures which an
organisation would have to set up, it runs
examinations/qualifications for individual
practitioners
Procedure/ project manager PRINCE2
9
Product
Activity
Product
Activity
Product
•e.g.
Specification
•e.g. coding
•e.g.
Software
component
•e.g. Test
component
• e.g.Tested
component
Activities vs Products
10
Identify deliverable and intermediate
products – create Product Breakdown
Structure
2. Identify dependencies between products
e.g. Code needs a specification – create
a Product flow diagram
3. Dependencies are effectively activities –
draw up Activity Network
1.
Other key PRINCE2 feature – project stages
PRINCE2 product-driven approach
11
How activities and products in a project
are arranged for execution
 Processes – standard ways of doing
things; are repeatable e.g. Design and
write code using UML
 Project – defined, one-off undertakings
which use processes e.g. Implement UK
Universal Credits system

process
<<<<repeated
one-off>>>>
project
Process models
12
1.
The age of order – waterfall
2.
The age of uncertainly reduction
3.
The age of efficiency
The three ages of project process
models
13
The age of order
14
requirements
analysis
design
build
test
install
Waterfall or once-through or one
shot
15
 Perceived
advantages
◦ An orderly approach
◦ Each stage supplies intermediate products used
by next
◦ Quality control at the end of each stage
◦ User knows what is to be delivered – agreed at
requirements stage
Waterfall
16
feasibility
study
requirements
analysis
corrections
corrections
system design
software design
Another way of
looking at the waterfall
model
corrections
corrections
review
user acceptance
system test
unit test
code
V-process model
17
During progress through the waterfall
processes
Effort/duration estimates tend to
become more accurate
Defects tend to accumulate
Waterfall – project progress
18
The age of uncertainty
reduction
19
◦ Designed for high-risk innovation projects
◦ At the beginning of the project
 Identify areas of uncertainty
 Design learning activities e.g. Prototypes to reduce
uncertainty - these become extra initial stages
 Could have more than one iteration of a prototype
◦ At end of each waterfall stage
 Assess amount of uncertainty remaining in project
 If too high, abandon the project
Boehm’s spiral model
20
delivered
system
design build install evaluate
increment
1
first incremental delivery
design build install evaluate
second incremental delivery
design build install evaluate
increment
2
increment
3
third incremental delivery
Incremental delivery
21
IF uncertainty HIGH
THEN use evolutionary approach
If complexity is HIGH
THEN use an incremental approach
IF uncertainty and complexity both LOW
THEN use one-shot/ waterfall
IF schedule is TIGHT
THEN use evolutionary or incremental
Euromethod/ISPL heuristics
22

‘Dynamic System Development Method’

Essentially a codification of incremental/
evolutionary principles

Has developed a DSDM Atern vocabulary

UK-based

Offers examinations/qualifications
DSDM Atern
23
The age of efficiency
24

Key concern of these approaches – the reduction
of the length of communication paths e.g.
between specification and software delivery

Examples: XP (eXtreme programming) Crystal
technologies, features-driven development,
DSDM Atern, Scrum

The viewpoint is very much that of software
development

Agile Alliance (http://www.agilealliance.org/)
acts as an umbrella organisation
Agility
25

All these focus on the immediacy of
communication
◦
◦
◦
◦
◦

Talk directly with users
Provide very frequent working increments
Create test plans as you identify requirements
Daily integration of components
Programming in pairs
These need
◦ Collocation
◦ User participation
Examples of XP practices
26

More widely applicable than XP – origins in
product development than design

Product owner is key stakeholder – authority on
design requirements

Development done in a number of one to two
week sprints
Scrum
27
 Group meeting to identify
requirements - recorded in a
product backlog
 Also identifies tasks needed to
implement product backlog in a
sprint backlog
 Identifies tasks/products for first
sprint, i.e. Increment
 Estimates effort for each task and
allocates tasks to developers
Scrum planning meeting
28
Sprint meetings – daily
15 minute ‘stand-up’
meeting of the
development team



Each developer reports:
◦ Progress since last meeting
◦ Planned activities for next meeting
◦ Any inhibitions of further progress
Sprint terminates with a sprint review
meeting – presentation of products to product
owner
Followed by planning meeting for the next sprint
Sprint execution
29
Software projects as production
lines
30
PROCESSES <<<<repeated
one-off>>>> PROJECT
Where time to delivery is crucial increments can be
over-lapped
TIME>>>>
Inc 1
Inc 2
Inc 3
design
build
test
design
build
test
design
build
test
Need for careful coordination as stages not same length
The project as production line
31
code B
feeder
specify
design
create
tests
code C
test
buffer
feeder
Critical chain projects
32





TWO estimates produced for each
activity: most likely (50% chance of being
achieved), and a safety margin
Most likely estimates are targets for all
activities
Critical chain activities: 50% of sum of
safety margins in chain are used in the
project buffer at end
Feeder buffers where sub-chains feed in
All activities started as late as possible
Critical chain
33



Central idea of lean manufacturing is ‘just in
time’ – only make components when actually
needed. This saves having large expensive
inventories
Japanese companies have reputation for
effective Quality Circles in industry focussing
on process improvements – groups of
workers identify/implement improvements
Attempts made to apply ideas to software
development with mixed results
Lean and Kanban
34
Suitable for where there is a group of software
intensive systems sharing common features and
assets and/or supplying a specific market e.g.
Where there are product lines.
Software product lines
35

Focus on the identification of reusable
software components and other assets.
Core
Asset
Development
Product
development
Management
Software product lines
36
Delivery quality
37
How do you know that your suppliers are of good
quality?
How do you persuade your customers you are good?

ISO 900x a generic standard for quality management
systems

CMMI Capability Maturity Model

ISO 9126 Software Quality Standard
Delivery quality standards/
methods
38
A company is at level 1 by
5. optimizing
default i.e. there is no level
zero
process
4. managed
control
3. defined
2. repeatable
1. initial
process
management
process definition
basic management
control
ISO 15504 is an international standard which implements
a CMM Approach
Process maturity levels
39
a
managed
process
requirements
directives
design &
define
manage
system design
tools, staff etc
inspection
criteria
code & unit
test
tested modules
system errors
design methods
design defects
tools, staff etc.
test plans
tools, staff etc.
integrate/
system test
system
software
40
ISO 9126 Software product quality
Attributes of software product quality
◦ External qualities i.e apparent to the user of
the deliverable
◦ Internal qualities i.e. apparent to the
developers of the deliverables and the
intermediate products
ISO 14598 Procedures to carry out the
assessment of the product qualities
defined in ISO 9126
ISO standards
41
ISO 9126 software qualities
functionality
does it satisfy user needs?
reliability
can the software maintain its level
of performance?
how easy is it to use?
usability
efficiency
relates to the physical resources
used during execution
maintainability
relates to the effort needed to
make changes to the software
portability
how easy can it be moved to a
new environment?
42

Need for organisational commitment/
motivation

Danger of lip service only e.g. ‘PINO’

Danger of means-end inversion

Need for the tailoring of methods

Judgement about level of detail
Some discussion points
43