Ministry of Technology
Show Menu

Optimising Project Delivery - Enabling Change

Optimising Project Delivery - Enabling Change

This is the penultimate article in a series on optimising project delivery in an agency environment. I have covered fostering positive conflictadapting the resourcing modelblockers and reallocating painful consequences. Last time I wrote about improving quality and profitability by use of QA throughout the life-cycle. This time around I am going to briefly look at the key starting point for enabling a lot of the techniques that I have mentioned in my previous articles, enabling change.

The Importance of Change

In a traditional organisation change is often expensive. This is due to, often long established, organisational processes that stunt growth and prevent the organisation functioning in a coherent form without extensive bureaucracy. Such systems are usually extremely hierarchical and are the antithesis of an empowered structure.

In order to make use of many of the techniques that I have already covered in this series it is essential to first adapt the organisation to enable change. Once change is considered to be business as usual and the cost of change is minimised then the organisation can begin to experiment to improve itself.

How to become 'Change Enabled'

There is no one answer to how an organisation becomes change enabled. This process is at the heart of an organisational transformation piece which will be different for every organisation. This is a service that we offer through our Horsepower programme.

The key thing to bear in mind when doing an organisational transformation for change, in an ideal world, is to minimise the level of change that you implement to create an environment to enable change. In the real world you may find that the transformation requires more significant change than ideal for organisational reasons. Every organisation is different. When in doubt the default point should ideally be 'Start from where you are'.

Early on in the process review meetings should be held to drive the initial change. These are effectively retrospectives against the current, pre-change, status quo. These meetings will raise key issues and concerns to drive the initial transformation but should always be balanced with the need to minimise the level of initial change.

Another way of looking at this is, if you 'Start from where you are' your first change is to implement arbitrary team wide retrospectives and then drive changes from there. The scale of these changes is then driven by the needs of the organisation.

Why Minimise Initial Change?

It's a fair question to ask as to why you would want to minimise the initial change. The answer has already been given. Before you enable change to make change the norm change is both expensive and risky. By minimising the initial change you de-risk the organisational transformation itself.

The other key benefit you get from a minimal implementation is the ability to evaluate the change. When you start capturing performance metrics from your teams you can see whether a given change has a positive effect on them. This should become good practice over time as it allows you to evaluate what works and what doesn't. 

If you imagine the organisation as a product then this is the difference between a waterfall delivery of the transformation and an agile, iterative, delivery. If we deliver iteratively then we deliver the key dependency feature first which is the enabling of change. Once this is delivered we can then iterate further change on top of it. Each of these changes is then less risky (as it can easily be reversed to a known good working point) and measurable. You can think of this as the QA of the process itself.

What Next?

In my final article in the series 'Optimising Project Delivery' I will deal with, what I believe should always be both the beginning and the end, the retrospective.