How many times do we see project teams waiting for a working test environment, or a working code build – or even – for an agreed design? Wouldn’t it make sense to apply a continuous improvement mindset to make these repeated activities slicker?

We typically see several areas for big gains:

  • Project Mobilisation – a week lost in project mobilisation is as critical as a week lost just before go-live, yet the time never seems as precious. There are big gains to be made through applying a Lean Startup approach to project mobilisation
  • Rolling Releases – there is often a heap of wastage in rolling (N, N+1) releases which can be eliminated:
    • Is code branching smooth and ordered (and locked down without exceptions)?
    • Does the workload of each team stay constant from release to release, or is it “spiky”?
    • Can you create a backlog of analysed changes, to allow you to delay scope lockdown as long as possible?
  • Development and Test – application of DevOps / Continuous Integration tools and techniques can drastically improve your critical path, through minimising the delay in finding out if the code doesn’t work!
  • Change / Release Management – often a painful process of Change Approval Boards and delays, which can be automated through using the same Continuous Integration toolsets that gave you the benefit in your Dev/Test phases. Automate, and if you can’t automate, be pragmatic!
  • Governance – all too frequently we see companies where the lack of delegated decision-making rights meant that the critical path constraining factor was getting access to the MD to take decisions!

Do you have a clear picture of the critical paths through your change delivery function? Where would you start?

POSTED BY: David Knappett - Consulting Director


View the author's team profile page

Get in touch