Which project management

methodology? A guide for the perplexed.

BCS London (South) branch Wednesday 6th May 2015

1

Why project management methods?

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

2

Why project management methods?

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

3

Kinds of ITPM standards

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 CMMI, ISO 900x

Product quality ISO 9126

4

Focus on project manager: Project management ‘Bodies of Knowledge’

5

Project manager - Bodies of knowledge

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

6

Bodies of knowledge - continued

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.

7

Focus on project management processes

8

Procedure/ project manager - PRINCE2

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

9

Activities vs Products

Product

•e.g. Specification

Activity

•e.g. coding

Product

•e.g. Software component

Activity

•e.g. Test component

Product

• e.g.Tested component

10

PRINCE2 product-driven approach

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

Other key PRINCE2 feature – project stages

11

Process models

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

project process one-off>>>> <<<<repeated

12

The three ages of project process models

1. The age of order – waterfall

2. The age of uncertainly reduction

3. The age of efficiency

13

The age of order

14

Waterfall or once-through or one shot

requirements analysis

design

build

test

install

15

Waterfall

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

16

V-process model

feasibility study

requirements analysis

system design

code

unit test

system test

user acceptance

software design

review corrections

corrections

corrections

corrections

Another way of looking at the waterfall model

17

Waterfall – project progress

During progress through the waterfall processes

Effort/duration estimates tend to become more accurate Defects tend to accumulate

18

The age of uncertainty reduction

19

Boehm’s spiral model

◦ 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

20

Incremental delivery

design build install evaluate

design build install evaluate

design build install evaluate

increment 1

increment 2

increment 3

first incremental delivery

second incremental delivery

third incremental delivery

delivered system

21

Euromethod/ISPL heuristics

IF uncertainty HIGH

THEN use evolutionary approach

IF uncertainty and complexity both LOW THEN use one-shot/ waterfall

IF schedule is TIGHT THEN use evolutionary or incremental

If complexity is HIGH THEN use an incremental approach

22

DSDM Atern

‘Dynamic System Development Method’

Essentially a codification of incremental/ evolutionary principles

Has developed a DSDM Atern vocabulary

UK-based

Offers examinations/qualifications

23

The age of efficiency

24

Agility

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

25

Examples of XP practices

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

26

Scrum

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

27

Scrum planning meeting

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

28

Sprint execution

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 meetings – daily 15 minute ‘stand-up’ meeting of the development team

29

Software projects as production lines

30

The project as production line

one-off>>>> PROJECT <<<<repeated PROCESSES

TIME>>>>

Inc 1 design build test

Inc 2 design build test

Inc 3 design build test

Where time to delivery is crucial increments can be over-lapped

Need for careful coordination as stages not same length

31

Critical chain projects

specify design

code B

code C test

create tests

buffer

feeder

feeder

32

Critical chain

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

33

Lean and Kanban

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

34

Software product lines

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.

35

Software product lines

Focus on the identification of reusable software components and other assets.

Core Asset Develop-ment

Product development

Management

36

Delivery quality

37

Delivery quality standards/ methods

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

38

Process maturity levels

1. initial

2. repeatable

3. defined

4. managed

5. optimizing

basic management control

process definition

process management

process control

A company is at level 1 by default i.e. there is no level zero

ISO 15504 is an international standard which implements a CMM Approach

39

40

a managed process

design & define

code & unit test

integrate/ system test

requirements

design methods

tools, staff etc

system design

tested modules inspection

criteria

tools, staff etc.

test plans

tools, staff etc. system software

manage directives

design defects

syste

m e

rrors

ISO standards

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

41

ISO 9126 software qualities

functionality does it satisfy user needs?

reliability can the software maintain its level of performance?

usability how easy is it to use?

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

Some discussion points

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

43