Managing Software In CCPM Projects

Some Lessons learned the Hard Way

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 INTRODUCTION

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Martin Heritage

Programme MANAGER – Megger

• Worked at Megger for 2.5 years
• New Product Developments
• Johnston Sweepers / Bucher Municipal for 14
years as a Design Engineer and Engineering
Project Manager
• Experience with CCPM on multiple projects. Megger Instruments Limited
Tel: 01304 502100
martin.heritage@megger.com

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 John Muncaster

• John is a lead consultant at Goldratt UK

• Over the last 12 years he has specialised in supporting
companies implement Critical Chain
• He has worked with a broad range of companies
– Many industrial sectors
– Small companies to multinational and Government

• Martin and John have previously worked on a very successful

CCPM implementation at Johnston Sweepers
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Megger

• Founded 1889, by Sydney Evershed

• Headquarters in Dover, Kent, UK,

• Manufacturing plants in UK, US, Germany

and Sweden

• Group Turnover ~€250m

• 50 Years at the Dover Site, 1966-2016 AVO Model 8

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

6

A leading worldwide manufacturer of Electrical Test Instruments

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 SO WHY IS SOFTWARE DIFFICULT TO MANAGE
IN A PROJECT?

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 No Real Logical Sequence

• If you are to build a house you work in the following

sequence.
– Foundations – Walls – Roof – 1St Fix – 2nd Fix….
• When building a virtual house you don’t need to start with the
foundations

Foundations Walls Roof 1st Fix 2nd Fix

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 No Real Logical Sequence

So why does this make it difficult?

• There is a big temptation to pick and choose bits from across
the project without ever finishing any of the modules.
• This leads to the difficult work being left to the end of the
project generating the typical duration hockey stick effect
seen at the end of projects.

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Interface Definitions

• In the mechanical world it has become the norm to build

computer models.
• These models are virtually assembled to check that everything
fits together well.
• This is relatively easy because in the mechanical world the
interface points are fixed.
• In software the interface will change depending on the
input.
• So it’s hard to document thoroughly how one module
interfaces with another.
• Often its left up to the software engineer to make assumptions
about what these interfaces are
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Building A Plan To Mitigate

• Spent significant time prior to the project being planned documenting the
architecture
• Of the modules
• Properly defining the interfaces
• Broke this architecture in to scope boxed “sprints” with a time estimation
for each sprint.
– In the first CCPM project we broke the scope down into 8 phases of work each
containing about a months worth of work.
• Linked the scope boxed sprints together
• Ensuring the scope boxes with highest risk were addressed first.
• Made sure everyone understood the “sprints” were scope based not time
based.
• In execution reported remaining duration of each scope boxed sprint.
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Results

Software Task Burndown • The actions seemed to

25 work
Phase 1
• Based on the duration
Phase 6
20
updates, phase 1 – 7
Remaining Duration (working days)

seemed to progress
15
Phase 2
Phase 7 nicely without issues.
Phase 3 Phase 5
Phase 4 • Phase 4 experienced a
10
minor issue evident in
the chart.
• So the project finished
5

on time ? ….
0
18.08.2016 07.10.2016 26.11.2016 15.01.2017 06.03.2017 25.04.2017 14.06.2017 03.08.2017 22.09.2017 11.11.2017

Remaining Duration Software 1 Remaining Duration Software 2 Remaining Duration Software 3 Remaining Duration Software 4
Remaining Duration Software 5 Remaining Duration Software 6 Remaining Duration Software 7

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Results

Software Task Burndown

30
• All was going well until
phase 8.
25 Phase 8
• Initial progress of the
phase was good.
Remaining Duration (working days)

20

• But when it came to

15
reviewing the project for
launch it was found there
10
was still much to do from
5
a software point of view

0
18.08.2016 07.10.2016 26.11.2016 15.01.2017 06.03.2017 25.04.2017 14.06.2017 03.08.2017 22.09.2017 11.11.2017 Note: The duration on phase
Remaining Duration Software 1 Remaining Duration Software 2 Remaining Duration Software 3 8 kicked up again after this
Remaining Duration Software 4
Remaining Duration Software 7
Remaining Duration Software 5
Remaining Duration Software 8
Remaining Duration Software 6
chart was created.

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 So What Went Wrong In Planning?

Planning:
Q: Were that actions taken during planning incorrect ?
• No, All the planning assumptions and actions were
good and we will take the same ones again.
• The resulting project plan was also good enough to
deliver on time.

So if planning was good what went wrong in execution?...

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 EXECUTION

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Software Architect

The software architect left the organisation.

• Poor Handover
• No time to understand the plans

• The architecture and the logic for delivering the modules in the
sequence planned.
• The interfaces and what was required to make the jigsaw puzzle
fit together.
• Definition of good enough for each module and the project as a
whole.
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Time Boxing

Despite emphasising that the sprints were scope boxed

not time boxed
• The team treated each sprint as time boxed and closed
every sprint on time and moved any undelivered scope into
the next phase.
• Work bow waved into the future.
✓
Scope

Time

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Not sufficiently Finishing a Phase

Verification of work done:

• Work done was not monitored adequately.
• Work done was not independently verified
• Work was left unfinished and new tasks started.
• Unfinished work was classified as “bugs”!

An illusion of progress
• A significant bug list to fix when the project was
approaching completion

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 Project Management

The fear of reporting a delay was high

• No one (including the project manager) wanted to stick their head
above the parapet and declare a delay.
No focus on completion
• No project level verification of work done. Sufficiently “done” to be
closed on the project plan.
No visibility of delay
• As no delay was reported in the software
tasks, no recovery actions were generated.

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 LESSONS LEARNED

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 What We Have Learned

The steps we took in planning are good.

Execution of the plan was not good enough
– Each task electrical, mechanical, software or administrative needs to have
an agreed definition of what is required before execution of the task
commences.
– Focus and finish needs to be applied to the task until it can be
demonstrated to be complete.
– Project management needs to be checking tasks marked as completed
have meet the required standard.
– Project management needs to be formulating recovery actions for tasks
that are delayed or blocked.
– Project team members need to be rewarded for reporting accurately.

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 BUT IT’S NOT ALL BAD NEWS

www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA

 But It’s Not All Bad news

• Despite the difficulties we have had on this first project we still have plenty
of tangible benefits from critical chain.
• Generally we are aware earlier of when the project is in difficulty
• We are managing better the three facets of project management:
– Time
– Scope
– Cost
• Project resources are becoming increasingly happy with clear work-to lists
that show them where their priorities lie.
• Despite us having issues with software all other aspects of the plan were
delivered on time to scope.
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Performance
Project Delivery Performance History

Planned Completion Date Compared to The Actual Completion Date

Project abc

Planned Duration Project Delay

(defined as 100%) (% of original planned duration)

24
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA
 Performance

• Average Overrun 74% Prior

to Critical chain

• Average Overrun 16% after

Critical Chain Implemented

25
www.tocpractice.com 37th International Conference of the TOC Practitioners Alliance - TOCPA