This is a high-level guide to continuous improvement. This guide is written as though there has already been an implementation of a Microsoft Dynamics system, but the concepts apply well outside of that assumption as well. If there is a sub-theme to this guide, it is that you need to focus on business value. No changes should be made just because there is a shiny new tool on the marketplace, unless a clear line can be drawn to the business value that will be achieved through its use. 

History 

You can’t really get far thinking about this topic without encountering kaizen, the Japanese term meaning improvement. In management consulting circles, kaizen has come to stand for continuous improvement such as is practiced at Toyota and other large manufacturing industries. The concept was introduced to Japan after World War 2 as a part of the rebuilding programme and was itself based on the US Training Within Industry programme. 

The main focus of this practice of continuous improvement is to move away from top level command and control as a way of governing manufacturing workplaces and instead look to the workforce to be able to generate improvements in their own processes. In software development, the same change was implemented forty years later when the agile software development methods started to appear in the 1990s. 

The adverb “continuous” is especially important in the discussion. Unlike early monolithic fire-and-forget implementations of software solutions, the expectation now is that through software-as-a-service, the implemented system is going to be undergoing its own evolution. Alongside this, organisations should be looking to continually review their systems and processes to ensure that they are running as efficiently as possible. 

One of the founders of the Toyota Production System, Taiichi Ōno, had a precept: 

The workplace is a teacher. You can find answers only in the workplace. 

This idea still holds true today and forms the basis of the guidance set out below. Continuous improvement has no space for ivory towers and theoretical discussions, the imperative is to make things better for the people in the workplace. 

Starting up 

Do anything immediately. Starting something right now is the only way to win. 

Taiichi Ōno 

There are four areas of investigation that will be discussed here, and the most important thing is to do something! The business-as-usual work, or the day job, will always have new challenges and new urgencies to take your time. Because of this, it is very easy and very human to make a decision to sit back and focus on that rather than on an improvement brief. Unfortunately, it is very rare that things happen by themselves – even the original kaizen programmes had a way of prompting change in the first place which had to be internalised by the working team. 

The most important precursor is to get a mandate for the work from a sponsor – the referred power will give coverage for those who might otherwise spend their time asking “why are we doing this?”. Ensure that there is time and space given to some of the workshops described below, make your process and your outputs public so that everyone can see the result of the work that they have put in. 

Back to the execs 

Wisdom is given equally to everybody. The point is whether one can exercise it. 

Taiichi Ōno 

The first step in your continuous improvement programme must be a referral to the group that set company strategy, usually the executive board. What we need is to understand where the company is planning on going over the next three to five years. If the board are planning a change in business model in the next 6 months, there may be no value in making incremental changes to how it currently works. 

The questions we need to answer are as follows: 

• Have the business priorities changed from those that were initially defined? 

• What are the current business priorities? 
• What can we see now that will stop us from meeting the priorities? 

The best way of approaching this sort of meeting is through a facilitated workshop. As we follow Design Thinking techniques where possible, our recommendation is to use a ‘double diamond’ technique of broadening and narrowing the focus of the meeting.

By following this process and being sure to play back the agreed findings at the end of the meeting, you can ensure that everyone gets an opportunity to feed into the session.  

Functional teams 

Waste is hidden. Do not hide it. Make problems visible. 

Taiichi Ōno 

As this guide focusses on delivery after an initial implementation you may like to assume that the functional teams are in a post-project world of unconfined joy. Realistically though, there will have been compromises made to get to the point of go-live. Also, each of the teams will have been working on the live system and had a chance to translate from theory to reality. As a result, there will now be areas which can be identified for a future focus of improvement. 

In the spirit of making this visible, we need to work with the team to expose and out the current pain points so that they can be factored into potential improvement initiatives. Again, a facilitated workshop is the ideal way to do this and for this one there are a couple of angles to be aware of as we approach the meeting.  

1. The functional team may believe that there were promises made during delivery of the system which have not been met 

1. The delivery team will have put hours and days of blood, sweat and tears into the project delivery for which they may feel underappreciated 

We therefore need to be careful to be clear that the past is history and needs to remain that way – explicitly we have to draw a line under any previous work and focus instead on the future. The current solution is the only truth and if it requires improving then we should be approaching that in an open, honest and ego-less way. 

Although this workshop is an open discussion of what improvements are required, it can still help to give it a focus. For most teams, they will have a way of tracking how they are running – operational or business metrics. It can be a good idea to base the workshop around these as it will stop you from drifting into ‘nice to have’ conversations. 

Take each of the business metrics, spend some time to make sure everyone in the room understands: 

• How they are measured 

• How regularly 
• By whom 

Then brainstorm against this start position – what can we start or stop to improve this metric. As with any workshop of this type, there are no wrong answers and this isn’t the place for a discussion about how to achieve it, that will come later. Once the ideas are all out on the table, you can then get them prioritised in terms of importance to the team. Again, at the moment we are capturing the themes and concepts, no design or feasibility required. 

Revert to the business case 

Re-improve what was improved for further improvement 

Taiichi Ōno 

There will have been a business case for the initial implementation project. An important part of any business case is that it sets out the business value benefits that are expected to be achieved as a result of the project, the timeframe in which we can expect to achieve them, and who owns the achievement of the benefit. 

Now that the project has gone live, the nominated individual or role should be monitoring to ensure that the benefit has been achieved. Many organisations fall down on this point and never track back to ensure that expected value has been realised. 

If the value is not being tracked, now is the time to delve back in and ask why we are not measuring against the expectations. One of the most common reasons not to measure is because people don’t think that the value is being achieved. In reality, most benefits will not hit exactly the level expected before implementation, they will either be over- or under-achieved. 

Where an expected benefit is not being achieved, the key question we need to ask is whether we still want that benefit. For example, we may have expected a reduction in headcount in a particular team- but have only achieved half of the anticipated value. It may be that there are good operational reasons why this is actually fine and the benefit recipient has decided that there is no further need to make adjustments. 

Equally, it may be that the implemented system has not freed up the FTEs in the way that was expected, and some further work is needed to achieve the benefit, but that the benefit is still desired. 

The list of unmet but still desired business benefits becomes the third feed to the growing list of continuous improvement targets. 

Check the roadmaps 

Once you start something, persevere with it. Do not give up until you finish it. 

Taiichi Ōno 

The final step for building our list of continuous improvement targets are two roadmaps: the digital transformation roadmap that was constructed when the programme was first discussed, and the future development roadmap from Microsoft.  

Often to achieve value quickly, a minimum viable product (MVP) approach is taken, cutting out any solution areas which can be delivered in a later phase. As a part of the continuous improvement initiative, we should go back to the removed areas and establish whether we want to deliver them now. Although it may sound obvious that we would want to bring these functional areas into scope, we need to take account of the fact that the strategic objectives will have changed since the original roadmap was drawn up. Also, now that there is a practical and functional understanding of the use of the solution, the functional business priorities will have changed. 

As Microsoft’s business applications tools are now software as a service (SAAS), they are regularly updated with new features and functionality. These features are usually delivered turned off, with a view that customers can switch them on when/if they are ready to use them. They also publish a list of the features they are looking to bring out in the next releases. This gives you a roadmap of Microsoft change, both available and soon-to-be-available, which can be added for decisions on whether or not to bring it in to your solution. 

To make a decision on these final roadmap areas, first compare them to the list that we have been building throughout this process. It may be that they have all been taken into account already throughout the previous discussions. 

For those which have not been brought up already, come back to the impacted functional teams and assess why it is no longer on the list, and whether it should now be added. 

Solution paths 

Explain difficult things in an easy-to-understand manner. Repeat things that are easy to understand. 

Taiichi Ōno 

Any change initiative can be described in terms of people, process, data and tools. Although it is always tempting to look for a technology answer to a given problem, that is not necessarily right. At this point, you need to be able to look at each item on the backlog list and make a judgement as to what solution path is the right way to move to a resolution. This will need discussion with the technologists within your organisation along with the functional teams that would need to implement any process change. 

The purpose of this discussion is to agree how you are going to solve outstanding business problems and capitalise on opportunities. This exercise will also give you an idea of the time or monetary cost of the change which you can use to compare against the business value that it will bring – important feeds into the final prioritisation exercise. 

Prioritise the final list 

Valueless motions are equal to shortening one's life. 

Taiichi Ōno 

From the four investigation areas above, we now have a full list of candidate backlog items for the continuous improvement initiative. These need to be prioritised against each other so that you can decide as a business which ones you will work on. 

This may be the most difficult part of the entire exercise because there maybe multiple teams looking to use scarce resource. This is why an understanding of cost and value will help to guide the actions of the collective. 

For this kind of prioritisation, although a high/medium/low grading is tempting it is actually better to use a system of absolute prioritisation – each potential change is rated with a unique number, and no duplicates are allowed. This means that although you can say that change A is about the same priority as change B, you still need to make a call on which is more urgent. 

Again this exercise works best as a workshop with all of the stakeholders involved – this removes the risk of having a “middle man” moving between multiple groups trying to get agreement between lots of parties. 

Once you have prioritised collectively, you should be able to start drawing a circle around the changes that you want to target in your next improvement project – it may be that there is a particular business area with lots of requests in the top ten, it maybe that a certain type of value will be facilitated by a cluster of items, or it may be that there is a set of ideas that are all self supporting when considered together. 

Whatever the obvious grouping, you can take the change set and move to the final step – crafting the business case and getting moving! 

Business case & go 

First say, "I can do it." And try before everything. 

Taiichi Ōno 

Although the business case and its format is dependent on your organisation, making the case for change will always incorporate a similar set of headings. As we give these a brief description, you can see how the work already carried out will facilitate this documentation 

• Background – where are you now, what pain points are being experienced in the business 
• Proposal – what is the set of changes proposed and how will they mitigate those pain points 
• Value – what business value is being unlocked by putting the proposal in place – this should be as specific as possible, with a hierarchy of achievable value starting at measurable financial value (e.g. we will save £45k) and ending at intangible immeasurable (e.g. staff will feel better about their roles) 

• Cost – how much will it cost to implement – be realistic and include both project costs and ongoing costs (e.g. licence uplift) 
• Timeframe – how long it will it take before the value can be realised. This is not necessarily the same as how long the project will take, there may be an expectation of further time after that, e.g. to bed in the changes 

Once an agreed business case has been signed off, it’s time to get moving – get this change implemented and then start again with the process to ensure that they solution is always getting better and always delivering more value! 

Summary 

You are a cost. First reduce waste. 

Taiichi Ōno 

This guide has set out how to go about setting up to carry out the discovery of a continuous improvement initiative through 4 investigation areas: business imperatives; functional pain points; original aims and existing roadmaps. By following a structured approach and incorporating design thinking techniques into the process, you will be able to get to an agreed set of changes which will bring improvement and value to the business. 

The last of Taiichi Ōno’s ten precepts is an interesting one – my interpretation of this is that because the person seeking to run continuous improvement is also a cost to the company, they should personally ensure that they are only doing things which have value. Unlike many other employees though, they will have a very direct way of measuring the value that they are personally creating because this is set out in every business case and in every benefit realisation meeting. 

I hope this guide has been of use to you in your continuous improvement journey – good luck! 

To read more about Taiichi Ohno visit: https://en.wikipedia.org/wiki/Taiichi_Ohno

Or to learn more about Inciper