What is an Improvement Kaizen?

• Lean IT

November 15, 2021

The Improvement Kaizen explained

The improvement Kaizen is the most popular and visible form of Lean IT Kaizen within IT. Simply said: improvement Kaizen is about bringing together a group of people who have an interest in having a particular problem solved, and getting them to solve this problem. It is sometimes referred to as a Kaizen event. Improvement Kaizen does have the drawback of requiring a substantial time investment and the results may not always be as successful as desired.

This sounds simple but this generally requires some organisation and management to ensure that the right people are involved and the right things happen. In this chapter, we will look into the governance and organisational aspects of Lean IT Kaizen events.

Who starts an improvement Kaizen?

Most organisations have no shortage of known errors or opportunities for improvement. Deciding which Kaizen initiatives deserve the resources, involves deciding which is most important to the customer and the organisation. Having made this primary decision, we must check the feasibility of the initiative. As explained in the Lean IT Foundation course, Kaizen initiatives may arise from one or more sources. These sources are known as the ‘Voices’:

The most important voice is the Voice of the Customer (VoC) which gives the IT organisation feedback on how the customer, the user of the IT service, actually experiences the IT service. The only person who can truly give us this feedback is the person who uses the IT service.

Voice of the Business (VoB): For IT, this concerns the ‘business’ of the IT organisation itself; not to be confused with the fact that the customer of IT is regularly referred to as “the business”. Even if the VoC does not identify any problems, the VoB may well find problems to be solved.
Voice of the Process (VoP): This is about processes not working correctly. Again, the VoC may indicate that the results of the process may be satisfactory and the VoB may not have any issues with the costs or quality. However, the process may indicate that, for example, even though changes are delivered on time and with few incidents, the variability of the process gives cause for concern.
Voice of the Regulator (VoR): It may seem that regulators primarily have their sights set on particular business sectors. IT is also directly affected by regulators. The Sarbanes-Oxley act specifically stipulates how IT must create an audit trail of changes.

Who is part of an improvement Kaizen?

In order to solve a problem using an improvement Kaizen, we must accept that the problem is not solvable by an individual; that it is only with the power of a diversity of points of view that the problem will be adequately addressed. Within the team, we find three basic roles:

Kaizen Sponsor: He or she is the owner of the problem, the person who has a direct interest in having the problem solved. In some cases, we may need that the manager of the problem owner is identified as the Kaizen sponsor. Generally, this will happen for budgetary or visibility reasons. This person must want to see the Kaizen event through to its conclusion, i.e. resolution of the problem. Without this person, there is no point carrying out a Kaizen event.

Kaizen Lead: This person manages the Kaizen process on behalf of the sponsor and the team. This role ensures that the correct steps are followed as efficiently as possible, so that the right actions can be taken as quickly as possible to remove the problem. This person must be experienced in managing the Kaizen process and ensuring that the team stays on track. A Kaizen lead must have facilitation and team-building skills in order to turn the group into an effective team in a short time.

Kaizen Team Members: The people executing this role will do the required work. They must be involved with the problem as it occurs on the workfloor. They must have intimate knowledge of the process in which the problem occurs, i.e. they must work in the process on a daily basis. It is useful to have people who are ‘upstream’ and ‘downstream’ of where the problem occurs. Also, having someone who is involved with the problem but can look at it from a dispassionate point of view, can be useful to avoid tunnel vision.

Selecting the correct team members for a Kaizen team is the next challenge. It is clear that we need diversity. This means the team must include people who work in the process, but also a manager who is close to the process, but not necessarily the manager of the process (who may be the sponsor). The team will need technical skills, e.g. understanding the technology involved in supporting the process, or business and regulatory rules governing the process.

Preparing for an improvement Kaizen

Assuming there is sufficient need to solve a particular problem, usually the Kaizen sponsor or a small team of people including the sponsor will create a short Kaizen charter in which the problem is described and an indication is given about resources (people, time, and money) requirement for the resolution of problem.. Also, the time within which a solution should be found will also be indicated. This means that an initial stakeholder analysis must have been done.

Based on the Kaizen charter, the Kaizen event can be planned and prepared. This means organising basic things, such as a location and the relevant information. On top of this, there must be an agreement on how and when the team will communicate progress. The minimum communication must be through daily updating the improvement board containing the relevant problem. This should be supplemented by regular submission of the current state of the A3.

Planning a Lean IT Kaizen is often described as a relatively straightforward affair in which activities are planned in a week. Ideally, a Kaizen is planned within a short time, wherein the Kaizen team dedicates their time to solving the problem. In practice, within an IT organisation, this kind of planning is quite difficult. Especially at the start of a Lean IT transformation, the organisation is not attuned to the fact that people are out of the ‘production’ process for a full week. Even after a transformation has taken hold of the IT organisation, it remains difficult to clear agendas completely to focus on a Kaizen.

A more realistic way of planning the Kaizen is to set up five or six meetings of three hours per meeting at regular intervals over a period of two weeks. This gives engineers the time to carry out operational work in the meantime. The agreement must also be made that work related to the Kaizen be carried out in between meetings, e.g. data collection, processing of data or preliminary analysis. These preparatory activities bring the Kaizen event to its point of initiation. In the Define phase, we will see how this input is validated, enriched, and brought to a point where the problem can be fully investigated.