Вы находитесь на странице: 1из 44
Organisational Transformation to the use of DSDM Atern for Project Management and Delivery Andrew Craddock

Organisational Transformation to the use of

DSDM Atern

for Project Management and Delivery

Andrew Craddock

Partner nlighten

www.nlightentraining.com

Question Why should DSDM Atern be the method of choice for Corporate Strength Agile ©

Question

Why should

DSDM Atern

be the

method of choice

for

Corporate Strength Agile

© 2011 nlighten Ltd

2

Agenda Traditional vs Agile Scrum Synonymous with Agile Corporate Issues with Scrum-based Agile How DSDM

Agenda

Traditional vs AgileAgenda Scrum Synonymous with Agile Corporate Issues with Scrum-based Agile How DSDM Atern addresses these issues

Scrum Synonymous with Agile Synonymous with Agile

Corporate Issues with Scrum-based AgileAgenda Traditional vs Agile Scrum Synonymous with Agile How DSDM Atern addresses these issues without compromising

How DSDM Atern addresses these issues without compromising Agilityvs Agile Scrum Synonymous with Agile Corporate Issues with Scrum-based Agile Considering an Agile Transformation

Considering an Agile Transformationwith Agile Corporate Issues with Scrum-based Agile How DSDM Atern addresses these issues without compromising Agility

The Traditional Approach Managing the Development of Large Software Systems Winston Royce 1970 Build the

The Traditional Approach

The Traditional Approach Managing the Development of Large Software Systems Winston Royce 1970 Build the Understand

Managing the Development of Large Software Systems

Winston Royce 1970

Build the

of Large Software Systems Winston Royce 1970 Build the Understand and define requirements Solution Test the
of Large Software Systems Winston Royce 1970 Build the Understand and define requirements Solution Test the
of Large Software Systems Winston Royce 1970 Build the Understand and define requirements Solution Test the

Understand and define requirements

Royce 1970 Build the Understand and define requirements Solution Test the Solution Define and design the

Solution

Test the

Solution

Define and

design the

Get the Solution into live use

solution

Solution Test the Solution Define and design the Get the Solution into live use solution ©

© 2011 nlighten Ltd

4

The Traditional Waterfall Characteristics Big Up-front Analysis and Design Early and extensive effort to drive

The Traditional Waterfall

Characteristics

Big Up-front Analysis and DesignThe Traditional Waterfall Characteristics Early and extensive effort to drive out and lock down detail Strong

Early and extensive effort to drive out and lock down detail

Strong process and controlEarly and extensive effort to drive out and lock down detail Documented output of each step

Documented output of each step approved before moving on

Each step the foundation of plans and intentions for the next All change formally assessed and controlled Heavy-weight documentation the anchor for parallel working

© 2011 nlighten Ltd

and audit

Associated Flaws

Foundation often proved wrong:working © 2011 nlighten Ltd and audit Associated Flaws Huge effort to create then a tortuous

Huge effort to create then a tortuous and ineffective approval Based on too many assumptions Fails to stand the test of time

Inherent resistance to changeon too many assumptions Fails to stand the test of time Massively difficult to validate intention

Massively difficult to validate intention for the next step Labour intensive and restrictive to the point people work around

5

Typical Outcomes Late & Over Budget* $Average: + 89% Poor Quality Testing Squeezed Not Meeting
Typical Outcomes Late & Over Budget* $Average: + 89% Poor Quality Testing Squeezed Not Meeting

Typical Outcomes

Late & Over Budget*

$Average: + 89%

Poor Quality

Testing Squeezed

Not Meeting the need

Scope Management with Waterfall Practices. No. 1 cause of failure for 82% of projects

© 2011 nlighten Ltd

Waterfall Characteristics & Outcomes

Chaos Report 2006 (1996)* Compromised 46% (53%) Succeeded 35% (16%) Failed 19% (31%)
Chaos Report 2006 (1996)*
Compromised
46% (53%)
Succeeded
35% (16%)
Failed
19% (31%)

* Standish Group Chaos Report 1996 & 2006 Taylor, BCS Bulletin 2001

6

A Surprise ? © 2011 nlighten Ltd Well, it shouldn t have been 7

A Surprise ?

A Surprise ? © 2011 nlighten Ltd Well, it shouldn t have been 7

© 2011 nlighten Ltd

Well, it shouldn t have been

7

In case you were wondering This was Royce s actual recommendation ! Workable But only

In case you were wondering

In case you were wondering This was Royce s actual recommendation ! Workable But only in

This was Royce s actual recommendation ! Workable But only in a slower paced world.

© 2011 nlighten Ltd

8

Agile: An Empirical Alternative Less emphasis on: The futile quest for the perfect specification Plans

Agile: An Empirical Alternative

Less emphasis on:Agile: An Empirical Alternative The futile quest for the perfect specification Plans comprehensive enough to be

The futile quest for the perfect specification Plans comprehensive enough to be executed by the unthinking Trying to lock everything down in the vain hope that things will be easier to control

More emphasis on:down in the vain hope that things will be easier to control Collective understanding of the

Collective understanding of the need (rather than the requirement) Harnessing the expertise and creativity of empowered teams to solve problems and build the right solution for the day of delivery All roles and all disciplines involved throughout eliminating silos

9

© 2011 nlighten Ltd

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

People and Interactions over Processes and Tools

Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

That is; while there is value to the items on the right we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2011 nlighten Ltd

10

With an acceptance that: Documentation Understanding Formality Discipline Bureaucracy Quality © 2011 nlighten

With an acceptance that:

Documentation Understanding

Formality Discipline

Bureaucracy Quality

© 2011 nlighten Ltd

11

Agile Origins 1970 1988 1993 1999 Royce s Barry Boehm DSDM Kent Beck 2011 Waterfall

Agile Origins

1970

1988

1993

1999

Royce s

Barry Boehm

DSDM

Kent Beck

2011

Waterfall

proposes

Consortium

publishes Extreme

Agile is

Adopted

iterative

introduces

Programming

10 years

by US DOD

Spiral Model

DSDM

Explained

old

by US DOD Spiral Model DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten
by US DOD Spiral Model DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten
by US DOD Spiral Model DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten
by US DOD Spiral Model DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten
by US DOD Spiral Model DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten

1970

1980 1990 2000
1980
1990
2000

Today

DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten Ltd 1980 1991 1995 2001
DSDM Explained old 1970 1980 1990 2000 Today © 2011 nlighten Ltd 1980 1991 1995 2001

© 2011 nlighten Ltd

1980

1991

1995

2001

Waterfall

James Martin

Sutherland

Agile

is the

proposes RAD

& Schwaber

Alliance

Global

Rapid

present

Founded

Standard

Application

Scrum

Development

at OOPSLA

12

Scrum The most popular of the Agile Approaches Well Scrumbut is probably more popular still

Scrum

The most popular of the Agile ApproachesScrum Well Scrumbut is probably more popular still With key eXtreme Programming practices embedded, Scrum is

Well Scrumbut is probably more popular still

With key eXtreme Programming practices embedded, Scrum is becoming synonymous with Agile for manyApproaches Well Scrumbut is probably more popular still A release cycle wrapping a delivery cycle wrapping

A release cycle wrapping a delivery cycle wrapping a collaborative iterative development processWith key eXtreme Programming practices embedded, Scrum is becoming synonymous with Agile for many © 2011

© 2011 nlighten Ltd

13

Scrum Overview Daily Scrum Burndown Chart Product Backlog Potentially Shippable Product Increment Sprint Backlog ©

Scrum Overview

Daily Scrum

Burndown Chart Product Backlog Potentially Shippable Product Increment Sprint Backlog
Burndown Chart
Product Backlog
Potentially Shippable
Product Increment
Sprint Backlog

© 2011 nlighten Ltd

14

The appeal of Scrum Roles Scrum Team Scrum Master Product Owner Ceremonies Sprint Planning Daily

The appeal of Scrum

The appeal of Scrum Roles Scrum Team Scrum Master Product Owner Ceremonies Sprint Planning Daily Scrum

Roles

Scrum Team Scrum Master Product Owner

of Scrum Roles Scrum Team Scrum Master Product Owner Ceremonies Sprint Planning Daily Scrum Meeting Sprint

Ceremonies

Sprint Planning Daily Scrum Meeting Sprint Review and Retrospective

Daily Scrum Meeting Sprint Review and Retrospective imple Process Artefacts Product Backlog Sprint Backlog
imple Process
imple Process

Artefacts

Product Backlog Sprint Backlog Burndown Chart

Product Backlog Sprint Backlog Burndown Chart Values Commitment Focus Openness Respect Courage ©

Values

Commitment Focus Openness Respect Courage

© 2011 nlighten Ltd

15

Simple ? So why do so may organisations struggle to make it work? Conflicting philosophies

Simple ?

So why do so may organisations struggle to make it work?

Conflicting philosophies? So why do so may organisations struggle to make it work? Agile different to the

Agile different to the status quo Requires a change in culture

Also, out of the box, Scrum has: out of the box, Scrum has:

Limited Project context No Business Change context No Governance context Poor Scalability

© 2011 nlighten Ltd

Limited Project context No Business Change context No Governance context Poor Scalability © 2011 nlighten Ltd

16

The Philosophy of Scrum Empowered, multi-disciplined, self-directed teams focussed on and committed to incremental

The Philosophy of Scrum

The Philosophy of Scrum Empowered, multi-disciplined, self-directed teams focussed on and committed to incremental

Empowered, multi-disciplined, self-directed teams focussed on and committed to incremental delivery of valuable software

In an environment where individuals exploit openness, mutual respect and trust and have the courage to do what is right rather than what is expected

courage to do what is right rather than what is expected Cultural Cultural Challenges Challenges ?
courage to do what is right rather than what is expected Cultural Cultural Challenges Challenges ?
Cultural Cultural Challenges Challenges ? ?
Cultural
Cultural
Challenges
Challenges
? ?

© 2011 nlighten Ltd

What do we get if we duck those challenges?

17

Typical corporate philosophy ? teams committed to delivery of s o f t w a

Typical corporate philosophy?

teams

committed to

delivery of

software

In an environment where individuals exploit

© 2011 nlighten Ltd

and have the courage to

do

what is expected

18

Project Context Where does the backlog come from? What is the big picture? How is

Project Context

Project Context Where does the backlog come from? What is the big picture? How is it

Where does the backlog come from?Project Context What is the big picture? How is it shared and/or agreed? And before we

What is the big picture? How is it shared and/or agreed?

And before we start What is the big picture? How is it shared and/or agreed? How long do we think

How long do we think the work will take? What do we think the work will cost? What is our predicted return on investment?

And how about dependencies/constraints across projectswill cost? What is our predicted return on investment? How are those identified? How are they

How are those identified? How are they managed?

© 2011 nlighten Ltd

19

Business Change Context Business Systems Solutions are about The software How the software is used

Business Change Context

Business Change Context Business Systems Solutions are about The software How the software is used for

Business Systems Solutions are aboutBusiness Change Context The software How the software is used for business advantage Scrum is great

The software How the software is used for business advantage

Scrum is great for orchestrating development of softwaresoftware How the software is used for business advantage Who identifies the business change required? Who

Who identifies the business change required? Who builds that part of the solution? Who manages the implementation?

© 2011 nlighten Ltd

20

Doing the right things Governance Context Prioritisation of projects in the portfolio Managing the allocation

Doing the right thingsGovernance Context Prioritisation of projects in the portfolio Managing the allocation of resources to projects

Governance Context

Prioritisation of projects in the portfolio Managing the allocation of resources to projects

Doing it rightManaging the allocation of resources to projects Business and System Architectures? Legislative Compliance

Business and System Architectures? Legislative Compliance (auditable)

System Architectures? Legislative Compliance (auditable) Being in control Controlled change to test and production

Being in controlSystem Architectures? Legislative Compliance (auditable) Controlled change to test and production environments

Controlled change to test and production environments Requirements Traceability (auditable)

© 2011 nlighten Ltd

21

Somebody else s problem ? Somebody else s problem? No! Projects need to deal with

Somebody else s problem ?

Somebody else s problem? s problem?

No! Projects need to deal with all of these things

But that stuff doesn t fit with [our view of] Agile t fit with [our view of] Agile

Tough! That s your problem!

© 2011 nlighten Ltd

things But that stuff doesn t fit with [our view of] Agile Tough! That s your

22

Can we: Just ignore this stuff? Solving the problem No not really We have to

Can we:

Just ignore this stuff?Can we: Solving the problem No not really We have to be able to hook in

Solving the problem

No not really We have to be able to hook in to the corporate context

Just wrap Agile with our current processes and guidelines?We have to be able to hook in to the corporate context No not really The

No not really The philosophies will be different probably fundamentally so

© 2011 nlighten Ltd

23

Solving the problem Real options Can we: Make up our own wrapper? Possibly But this

Solving the problem

Solving the problem Real options Can we: Make up our own wrapper? Possibly But this will

Real options Can we:

Make up our own wrapper?Solving the problem Real options Can we: Possibly But this will take a lot of effort

Possibly But this will take a lot of effort and great skill

Use an approach from a consultancy or thought leader?But this will take a lot of effort and great skill Possibly But choose wisely look

Possibly But choose wisely look for a real track record of success

Use a tried and tested approach?But choose wisely look for a real track record of success Ah That will be DSDM

Ah That will be DSDM An Agile approach developed by corporates for corporates

© 2011 nlighten Ltd

24

DSDM Atern or DSDM Agile Project Management Corporate Strength Agile More sophisticated structure of roles

DSDM Atern or DSDM Agile Project Management

DSDM Atern or DSDM Agile Project Management Corporate Strength Agile More sophisticated structure of roles and

Corporate Strength Agile

More sophisticated structure of roles and responsibilities

Aligning with corporate norms for responsibility and accountability

Enhanced ceremonies, processes and artefacts

Providing demonstrable control, traceability and auditability

A full project perspective

From concept through to benefit realisation

Dovetailing with and in no way inhibiting

The Agile values so clearly defined in the Agile Manifesto The Agile philosophy so eloquently defined by Scrum

© 2011 nlighten Ltd

25

DSDM Same team level delivery concept as scrum Some of the names are different, of

DSDM

Same team level delivery concept as scrumDSDM Some of the names are different, of course © 2011 nlighten Ltd Sprint = Timebox

Some of the names are different, of courseDSDM Same team level delivery concept as scrum © 2011 nlighten Ltd Sprint = Timebox *

concept as scrum Some of the names are different, of course © 2011 nlighten Ltd Sprint

© 2011 nlighten Ltd

Sprint = Timebox * Product Backlog = Prioritised Requirements

List Sprint Backlog = Timebox Plan Daily Scrum = Daily Standup Product Increment = Evolving Solution

* Timebox is often more structured than a Sprint more later

26

Roles DSDM Atern © 2011 nlighten Ltd Business Domain Product Owner Solution Domain Team Scrum
Roles
Roles

DSDM Atern

© 2011 nlighten Ltd

Business

Domain

Product Owner
Product
Owner

Solution

Domain

Team Scrum
Team
Scrum

Management

Domain

Scrum Master
Scrum
Master

27

Business Sponsor Responsible for the Return on investment Business Visionary Big picture for the enhanced

Business SponsorResponsible for the Return on investment Business Visionary Big picture for the enhanced business Technical

Responsible for the Return on investment

Business VisionaryBusiness Sponsor Responsible for the Return on investment Big picture for the enhanced business Technical Coordinator

Big picture for the enhanced business

Technical CoordinatorBusiness Visionary Big picture for the enhanced business Technical quality and coherence Project Manager Managing the

Technical quality and coherence

Project ManagerTechnical Coordinator Technical quality and coherence Managing the world around the project © 2011 nlighten Ltd

Managing the world around the project

© 2011 nlighten Ltd

Key DSDM Roles

Business Ambassadorworld around the project © 2011 nlighten Ltd Key DSDM Roles Day-to-day guidance and assurance Business

Day-to-day guidance and assurance

Business AdvisorRoles Business Ambassador Day-to-day guidance and assurance Specialist input Solution Developer / Tester Build the right

Specialist input

Solution Developer / Testerguidance and assurance Business Advisor Specialist input Build the right solution Business Analyst Facilitates shared

Build the right solution

Business Analystinput Solution Developer / Tester Build the right solution Facilitates shared understanding across roles Team Leader

Facilitates shared understanding across roles

Team LeaderTester Build the right solution Business Analyst Facilitates shared understanding across roles Keeps the team focussed

Keeps the team focussed 28

DSDM Atern Process Framework © 2011 nlighten Ltd 29

DSDM Atern Process Framework

© 2011 nlighten Ltd 29
© 2011 nlighten Ltd
29
DSDM Atern Process Framework With DSDM Atern, typically the Exploration and Engineering considerations are addressed

DSDM Atern Process Framework

With DSDM Atern, typically the Exploration and Engineering considerations are addressed together in a single
With DSDM Atern, typically the Exploration and
Engineering considerations are addressed together
in a single timebox as they are in Scrum Sprint
© 2011 nlighten Ltd
30
DSDM Atern Process Framework So If desired Scrum can simply be slotted into the wider-ranging

DSDM Atern Process Framework

So If desired Scrum can simply be slotted into the wider-ranging DSDM Atern Process. ©
So If desired Scrum can simply be slotted
into the wider-ranging DSDM Atern Process.
© 2011 nlighten Ltd
31
DSDM Atern Process Framework Revisit Foundations to validate/shape next release Get straight on with the

DSDM Atern Process Framework

Revisit Foundations to validate/shape next release Get straight on with the next release © 2011
Revisit Foundations to validate/shape next release
Get straight on with the next release
© 2011 nlighten Ltd
32
DSDM Work Products Also align with the three domains Business The what and the why

DSDM Work Products

Also align with the three domainsDSDM Work Products Business The what and the why Management Planning and coordination Solution Development and

Business

The what and the why

Management

Planning and coordination

Solution

Development and QA

Great depth and detail available in product set but only to be created where they add value only to be created where they add value

Decide on something as simple as Scrum where that is appropriate and/or use the depth and detail as requiredQA Great depth and detail available in product set but only to be created where they

© 2011 nlighten Ltd

33

The Corporate Challenges How does DSDM address the corporate challenges? Project Context Business Change Context

The Corporate Challenges

The Corporate Challenges How does DSDM address the corporate challenges? Project Context Business Change Context

How does DSDM address the corporate challenges?The Corporate Challenges Project Context Business Change Context Governance Context Through: Comprehensive and

Project Context Business Change Context Governance Context

Through:Context Business Change Context Governance Context Comprehensive and structured roles and responsibilities

Comprehensive and structured roles and responsibilities High level up-front work in Feasibility and Foundations Appropriate use of the rich product set Sophisticated Agile techniques to drive predictability:

MoSCoW Prioritisation Timeboxing

© 2011 nlighten Ltd

34

Feasibility Foundations DSDM Atern: Up-front Work Feasible solution (business and technical perspectives) Identify
Feasibility Foundations
Feasibility
Foundations

DSDM Atern: Up-front Work

Feasible solution (business and technical perspectives) Identify benefits likely to arise Outline possible approaches for delivery First cut estimates of timescales and costs

Firm Business Foundations Firm Foundations for the Solution Firm Foundations for management of the project

High level only not the big up-front analysis and design of traditional approaches

© 2011 nlighten Ltd

35

DSDM Atern: Rich Product Set Business Foundations Feasibility Foundations Solution Foundations Management

DSDM Atern: Rich Product Set

Business

Foundations

Feasibility Foundations
Feasibility
Foundations
Product Set Business Foundations Feasibility Foundations Solution Foundations Management Foundations Documents

Solution

Foundations

Foundations Feasibility Foundations Solution Foundations Management Foundations Documents created where they add

Management

Foundations

Foundations Solution Foundations Management Foundations Documents created where they add value, not by default

Documents created where they add value, not by default

Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten

Development Approach Definition

Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten
Foundations Documents created where they add value, not by default Development Approach Definition © 2011 nlighten

© 2011 nlighten Ltd

36

DSDM Atern: MoSCoW Prioritisarion MoSCoW and the Business Case Must Have Maximum Minimum 60% of

DSDM Atern: MoSCoW Prioritisarion

DSDM Atern: MoSCoW Prioritisarion MoSCoW and the Business Case Must Have Maximum Minimum 60% of Useable
MoSCoW and the Business Case Must Have Maximum Minimum 60% of Useable total effort SubseT
MoSCoW and the Business Case
Must Have
Maximum
Minimum
60% of
Useable
total effort
SubseT
Maximum
80% of
Maximum
total effort
Should Have
Cover all the benefits
agreed in the Business
Case for the project
100% of
total effort
Could Have
Additional benefit not
accounted for in the
Business Case might
be delivered

© 2011 nlighten Ltd

37

DSDM Atern: Timeboxing More Structure than other Agile approaches Control points Auditable Timebox Review Records

DSDM Atern: Timeboxing

More Structure than other Agile approachesDSDM Atern: Timeboxing Control points Auditable Timebox Review Records Kick Investigation Refinement Consolidation

Control points Auditable Timebox Review Records Auditable Timebox Review Records

Kick Investigation Refinement Consolidation Close Off Out
Kick
Investigation
Refinement
Consolidation
Close
Off
Out

© 2011 nlighten Ltd

Formal reviews include expert participants responsible for assessing whether the evolving solution is fit for purpose and meeting regulatory and other governance requirements

38

Project Manager s Workbook Formality where appropriate Light, Focussed, Contemporary, Accessible Example: Project

Project Manager s Workbook

Formality where appropriateProject Manager s Workbook Light, Focussed, Contemporary, Accessible Example: Project Manager s Workbook Created by

Light, Focussed, Contemporary, Accessible

Example: Project Manager s Workbook Project Manager s Workbook

Created by the nlighten team and practitioners at Daiwa Capital Markets Europe

© 2011 nlighten Ltd

39

DSDM Atern Easier sell many corporates Built in project focus and governance hooks Broader scope

DSDM Atern

Easier sell many corporates sell many corporates

Built in project focus and governance hooks Broader scope than software integrated business change Appears less radical than other Agile approaches The same Agile heart as the others but with more structure Less Fragile at scale

However:the others but with more structure Less Fragile at scale Still requires a major change of

Still requires a major change of mind-set for many people Full adoption takes skill, effort and commitment

© 2011 nlighten Ltd

40

Organisational Change Is far more about people than it is about process Defining and publishing

Organisational Change

Is far more about people than it is about processOrganisational Change Defining and publishing a standard is easy Getting people to buy into and ultimately

Defining and publishing a standard is easy Getting people to buy into and ultimately exploit a new way of working is difficult The former is a waste of time, effort and money without the latter

Everybody needs to understand and buy into:is a waste of time, effort and money without the latter The detail of the new

The detail of the new philosophy The implications of adopting that philosophy The day-to-day role they need to play in order to make it a reality

© 2011 nlighten Ltd

of adopting that philosophy The day-to-day role they need to play in order to make it

41

Leading Change Establish a sense of urgency Create a Guiding Coalition Develop a Vision and

Leading Change

Establish a sense of urgency Create a Guiding Coalition Develop a Vision and Strategy Empower
Establish a sense
of urgency
Create a Guiding
Coalition
Develop a Vision
and Strategy
Empower broad-
based Action
Expose problems
with the status quo
Strong leadership
by powerful players
To frame and track
effective change
Break the status quo
& encourage creativity
Communicate the Vision and Progress towards it
Generate Short-
term wins
Consolidate
Push further and
deeper into the Vision
Gains
Institutionalise
the Change
Demonstrate success
with pilot projects
Reward successful
behaviours
Generate more
Change
Formalise the new way
Guard against regression
Promote & develop
staff to new paradigm

© 2011 nlighten Ltd

Based on the 8 Stage Process of Creating Major Change by John P. Kotter

42

Kotter s Eight Causes of Failure Allowing too much complacency Failing to create a sufficiently

Kotter s Eight Causes of Failure

Allowing too much complacencyKotter s Eight Causes of Failure Failing to create a sufficiently powerful guiding coalition Under-estimating the

Failing to create a sufficiently powerful guiding coalitions Eight Causes of Failure Allowing too much complacency Under-estimating the power of Vision Under-communicating the

Under-estimating the power of VisionFailing to create a sufficiently powerful guiding coalition Under-communicating the Vision Permitting obstacles to block

Under-communicating the Visionguiding coalition Under-estimating the power of Vision Permitting obstacles to block the vision Failing to create

Permitting obstacles to block the visionthe power of Vision Under-communicating the Vision Failing to create short-term wins Declaring victory too soon

Failing to create short-term winsthe Vision Permitting obstacles to block the vision Declaring victory too soon Neglecting to anchor the

Declaring victory too soonto block the vision Failing to create short-term wins Neglecting to anchor the changes in the

Neglecting to anchor the changes in the organisational cultureobstacles to block the vision Failing to create short-term wins Declaring victory too soon © 2011

wins Declaring victory too soon Neglecting to anchor the changes in the organisational culture © 2011

© 2011 nlighten Ltd

43

Thank you Email: Andrew.Craddock@nlightentraining.com www nlightentraining com

Thank you

Thank you Email: Andrew.Craddock@nlightentraining.com www nlightentraining com

Email:

Andrew.Craddock@nlightentraining.com www nlightentraining com