1 “projects run on requirements, resources and risks” - augmenting the ‘iron triangle’ to...

28
1 “Projects run on requirements, resources and risks” - Augmenting the ‘iron triangle’ to keep an eye on critical success factors during a project Steve Armstrong (Open University)

Post on 20-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

1

“Projects run on requirements, resources and risks”

- Augmenting the ‘iron triangle’ to keep an eye on critical success factors during a project

Steve Armstrong

(Open University)

2

Subjects

Models and modellingCritical success factorsStakeholders

3

Starting point

Taking a systems view in order to explore the relationships between the factors and actors that have an influence on the course of action as the project plan is realized

But, watch out for the ‘shifting sands’ of project working reframing a requirement can make it forcibly

relevant to a new set of stakeholders a significant event can cause stakeholders to

switch roles and this is likely to change their requirements

4

Models

A model is a way of expressing a particular view of an identifiable system of some kind

So, models are a way of understanding the problems involved an aid to communication among those

involved, especially when a deliverable is being investigated

a component of the methods used in a given activity, such as the financial modelling done to test the feasibility of a proposal

5

Interactions between stakeholders

Conflict as a source of problems when a stakeholder perceives that his or her

interests are being opposed or negatively affected by another

So many expectations “What do you expect to achieve …” profound influence on project evaluation

6

The sources of conflict have implications for the management of risk

Incompatible goalsDifferent values and beliefsTask interdependenceScarce resourcesAmbiguous rulesCommunication problems

7

Some influences on satisfaction

project outcomes

satisfaction

cultural and socialvalues

personal values

expectations

8

Two distinct perspectives on project success

Success criteria related to the What? question, which include

both qualitative and quantitative measuresCritical success factors (CSFs)

related to the How? question, which are to be found in the project and its environment

9

Some examples of success criteria

The facility is produced to specification within budget and on time

The project achieves its business purpose and meets its defined objectives and quality thresholds so as to be profitable for the owner

The project team is happy during the project and with its outcome

Users are happy during the project and with its outcome

The project is profitable for the contractors The project satisfies the needs of stakeholders

10

The ‘top five’ CSFs

Support from senior managementClear, realistic objectivesStrong/detailed plan kept up to dateGood communication/feedbackUser/client involvement

‘top five’ (out of 27) after a review of 63 publications

11

The ‘bottom five’ CSFs

Correct choice/past experience of project management methods/tools

Environmental influences(learning from) past experiencesProject size/level of complexity/number of

people involved/duration(appreciating) different viewpoints

‘bottom five’ (out of 27) after a review of 63 publications

12

Criticisms of the CSF approach

the inter-relationships between CSFs are at least as important as the individual ones

the CSF approach ignores the potential for a factor to have varying levels of importance (and relevance) at different times during the project

13

The Formal Systems Model (FSM)

is a framing device to deliver the benefits of using CSFs

whilst, at the same time, taking into account their inter-relationships and dynamics our interpretation has changed

the sense of uniqueness with regard to projects indicates that each CSF will affect projects in different ways for example, a business case might contain a prioritised

list of critical success factors to reflect the context in which the proposed project will take place

14

The Formal Systems Model (FSM)

15

Classifying CSFs using project attributes within the FSM

Goals and objectives Clear realistic objectives (2) Strong Business case/ sound basis for project (9)

Performance monitoring Effective monitoring/control (16) Planned close down/review/acceptance of

possible failure (20)

16

Classifying CSFs using project attributes within the FSM (contd.)

Decision makers Support from senior management (1) Strong/detailed plan kept up to date (3) Competent project manager (8) Good leadership (11) Realistic schedule (13) Correct choice/past experience of project

management methods/tools (23)

17

Classifying CSFs using project attributes within the FSM (contd.)

Transformations Skilled/suitable qualified/ sufficient staff/team (6)

Communication Good communication/feedback (4)

Environment Organisational adaptation/culture/structure (18) Political stability (22) Environmental influences (24) (learning from) past experiences (25)

18

Classifying CSFs using project attributes within the FSM (contd.)

Boundaries Project size/level of complexity/number of people

involved/duration (26)Resources

Sufficient/well allocated resources (10) Proven/familiar technology (12) Adequate budget (17) Good performance by

suppliers/contractors/consultants (19) Training provision (21)

19

Classifying CSFs using project attributes within the FSM (contd.)

Continuity Risks addressed/assessed/managed (14)

General User/client/ involvement (5) Effective change management (7) Project sponsor/champion (15) (appreciating) different viewpoints (27)

20

The project context

The sense of uniqueness with regard to projects indicates that each of the above factors will affect projects in different ways.

A business case should contain a prioritised list of critical success factors to reflect the context in which the proposed project will take place.

For each critical success factor, it may be possible to identify a qualitative or quantitative measure that can be monitored during the project.

Any variation beyond a given threshold for a particular critical success factors can be interpreted as placing the project at risk.

21

Using influence diagrams

Modelling the main structural features of an issue and the important relationships that exist among them

Each one is a snapshot of a situation in order to identify the factors and actors that have a direct influence on a central issue of interest e.g. it is possible to identify obstacles to the

implementation of a new policy or strategy Influence diagrams are very rich in the information

that they can capture e.g. they can be used to gain an understanding of

stakeholders’ attitudes

22

Some of the factors and actors concerned with a project’s success

politicalstability

environmentalinfluence user/client

involvement

business case

project rationale

project scaleand complexity

technologyfamiliarity

objectives

implementationprocess

resourceallocation

projectmanager

budget

trainingprovision

staff/team

suppliers,contractors andconsultants

organizationaladaptation,culture andstructure senior management

project sponsor/champion

monitoringplan

schedule

learning frompast experience

communication andfeedback

appreciation ofdifferent viewpoints

riskmanagement

changemanagement

monitoring andcontrol

product

reviewing

leadership

revisioncontrol

project plan

project

risk anduncertainty

learning

requirements

resources

mehtods/tools

23

Using multiple cause diagrams

A multiple cause diagram can be used to identify and tackle the causes of a complex problem in a systemic way often derived from influence diagrams

They are used to explore why a given event happened or why a certain class of events tends to occur

The phrases used in a multiple cause diagram relate to a state such as a ‘flat battery’,

or an event such as ‘battery goes flat’

24

The normal starting point

What is the state or event to be explained?The answer becomes the focal point of the

diagram e.g. a lack of support form senior management

is detectedThen, you can work outwards and backwards

through the chains of causal connections to identify the relevant sequences and/or loops

25

Alternatively

You might begin by assuming that a particular project had failed

Then, consider changes in state for the CSFs lack of user involvement lack of resources unrealistic expectations incomplete requirements lack of planning insufficient training

26

Investigating user dissatisfaction

user dissatisfactionwith application

poorqualityof reports

patchesmisapplied

poorusability

inexperiencedstaff

lack of fundsstaffingdifficulties

inefficientconfigurationmanagement

lots ofbugs found

inadequate supportfrom senior management errors in

budget

poorsecurity

poorscreenlayout

slow responsetime

reductionin scope

corefeaturesmissing

poorsupport

excessivedown time

unrealisticdeadlines

27

Multiple cause diagrams are not intended to predict behaviour

But, they may be used to construct a list of factors to bear in mind when investigating comparable circumstances in the future part of a ‘regular health check’ i.e. a component in the analysis of risk

In practice, some further annotation may be required when there is insufficient evidence to denote a causal connection e.g. an arrow might be associated with other phrases

like: ‘contributes to’, ‘is followed by’ or ‘enables’

28

Summary

An understanding of the issues relating to a project’s requirements, resources and risks is the basis for a successful implementation of a plan to meet the time, cost and quality criteria

Modelling is a way of thinking about things and ideas in the ‘real world’ “Modelling and testing are fundamental aspects of

quality management.” (APM BoK 2006, p.62) Modelling may have a role in the lessons learnt from a

project Would keeping a repository of such information

promote a more reflective practitioner?