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?