Observation 2 - Our traditional delivery methods assume a stable knowable environment

 Our world is changing and changing fast.  Despite this the way we deliver change assumes that they environment is stable and knowable in detail to enable accurate planning. 


Most organisations, particularly "analogue" organisations deliver change through traditional waterfall methods (eg  PMI or Prince 2), led through a central PMO or perhaps a "transformation team" and require an upfront approval in the form of a business case that specifies scope, task, resources, cost and sometimes benefits.  

I define an analogue organisation as one that was established and matured it's business model before the internet was a significant commercial reality aka early 1990's or before.

The core assumption of waterfall methodologies is that the project is knowable and can be planned in detail and with certainty.  If this assumption is correct then once approved all we have to do is complete the tasks as planned and project success is more or less guaranteed.  This approach maybe fine for repeatable tasks or projects, that is projects:
  • that have been done many times before and this project is exactly the same, meaning we can create a detailed plan based off of evidence from previous deliveries
  • where there are no assumptions because we have detailed proven data and evidence 

and of course where the environment we are delivering into is stable. 

These conditions don't exist and they particularly don't exist for organisational change.  Never does an organisation deliver the same change in the same environment.  Each "project" is unique and because it is unique it is not genuinely repeatable.  Add to that the changing environment and that our most strategically important projects are often large and complex and almost always take at a year and can easily take 2 years or more to complete is it any wonder that many projects fail? 

A word on agile.  As I write this I can hear a number of you saying that's why we need to adopt agile practices.  Maybe that's true, agile certainly does a better job at encouraging shorter cycles making the change from start to "go live" more manageable and the introduce flexibility in how scope is managed that are probably more appropriate for a changing world than traditional large project methods.  They are no panacea however as they can cause other issues including weak governance and incompatibility with our preferred contracting methods.  Besides what many organisation's call agile is waterfall rebadged or at best "wagile", a blend of agile and waterfall.

To illustrate, I have been exposed to a number of software implementations where the software provider and implementation partner have trumpeted there use of agile methods as their approach to implementation.  When you push past the marketing campaign that "we use agile" the reality is quite different.  When they say they are agile what they almost always mean is:
  • traditional waterfall based requirements gathering, project scoping and sizing
  • development of requirements by the vendor development team through "agile cycles".
  • development of requirements not directly controlled by the vendor are delivered through traditional waterfall methods
  • waterfall based testing which begins when development is complete (ie not by cycle)
  • one off / one chance training for end users
  • and a go live that concludes the project with limited ability (budget and time) to adjust

How long do these projects take until they go live?  Anywhere from 9 months to 2 years.  Not really agile in the dictionary terms and consequently they suffer from many of the same issues.  Where it comes to software package implementations I have yet to see a genuine agile implementation.

There we have observation 2, our change methods assume stability and assumptions of stability in an environment that is changing faster than ever is a bad mix.

I am interested in your views, particularly as it relates to wagile or more "pure" agile methods.

In the next blog - Our understanding of how innovation typically happens is wrong.

Comments

Post a Comment

Popular posts from this blog

From Observations to Recommendations ..... a new approach to change and strategy implementation.

 The previous blogs in the series have made a number of observations about how most organisations lead and deliver change and how these delivery methods are inconsistent. with observable evidence.  These series of observations culminated in the last blog where I suggested the inconsistencies between actual delivery practice and observable reality were at least in part responsible for why organisations are collectively so bad at delivering change.  This blog concluded with a series of counter observations that took account of existing evidence and proposed that if we were to deliver change in a way that is consistent with observable evidence then we would improve our chances of successfully delivering change to our organisations.  For completeness here are the six counter observations or principles of change for todays world: Recognise that the world is changing rapidly and continuously and explicitly allow for this in our approach to change and the implementation of strategy.  Break la
Read more

From Observations to Principles For Change

 In the beginning of this blog series I posed the question - why are we collectively so bad at delivering change?   I believe a big part of the answer to this question is we collectively act on a series of beliefs that are inconsistent with observable evidence.   Consequently the next series of blogs has set out to identify specific instances of these inconsistencies through a series of observations.  By way of summary these observations are 1 : Our traditional delivery methods assume a stable environment but the world is changing faster than ever. We act as if innovation occurs through a genius having a big idea but in reality innovation occurs over time through iterations and interactions We suck at delivering large complex projects but we are actually quite good at delivering small and simple changes We predominantly focus on solution and scope (time cost and quality) and pay scant regard to benefits once approval has been given We tend to manage change through fear and short term e
Read more

Changing Change, Introductory Thoughts

  Change! It's everywhere and omni present. In our personal lives, at work, the expectations of our customers and the market offerings of our competitors. Not only is change omni present we all believe that change is happening at a faster pace today than it ever has before (more on this later). "change is the only constant in life." Heraclitus, (a Greek philosopher) approximately 535 BC For something that has been around "forever" we are notoriously bad at managing change. I have written about this is various forms over the years. Consider this extract from my Value Led Change White Paper. Mckinsey report that 70 % of change programmes fail to deliver. The Standish Group, in their aptly named Chaos report, state that only 29% of software development projects are successful.  The remaining 71% being troubled or considered an outright failure.  To make matters worse, the larger and presumably more important a project the lower the chances that it will succe
Read more