Improvement process with the Kaizen

Working better is what I endeavour. I am allergic to disorganised work and process of rediscovering the wheel. Whenever I recognise a situation when the work is complex, not defined and can go sideways, I put some structure to it so that we can improve.

My approach for doing it originates in Lean and Kaizen steps.
The steps go:

  1. Identify an opportunity for improvement.
  2. Analyze the current work method.
  3. Develop an optimal solution by investigating ideas.
  4. Propose and implement the solution.
  5. Track results of the change.
  6. Standardize the solution for the scale.
  7. Plan for the future and sustain the change

In one of my previous projects, I faced such a situation. That project was my first assignment in the department. This is where the journey begins.

1. Identify an opportunity for improvement.

Organizational requirements

I learned that every project needs to meet organizational requirements. The list had dozen or so security and quality-related requirements. You must meet all the relevant if you wanted to promote your project to production.

2. Analyze the current work method.

When I get familiarized with the process there were not many things that I could refer to. The expected result was vague defined. It could differ from case to case. From department to department. It was defined on the organizational level and suppose to fit to all the projects.
Everyone was running project-based his/her way. It was built on the previous experience, but no one documented it. Everyone working on the project had to clarify almost everything. Prepare document template, figure out who deliver what and when. Sometimes you worked on the process with someone who has as little experience as you. Then you could get in the thought of war mode as everyone tried to do as little as possible.
I realized that the current way of defining actions and people responsible was unclear. Different people gave me different answers: PO, BA, QA Manager. They all have their own opinion who should do what and how the result should be delivered. The only clear thing was that document preparation is the responsibility of a QA specialist. The person who did not have access to the required artefacts and was a middleman in the whole process.
Of course, going this way we could not improve anyhow. If we do not measure it we cannot improve it.

3. Develop an optimal solution.

At the end of my first project and all the meetings and clarifications, I decided to take an initiative and put some structure on this process. I collected relevant data and prepare a process improvement initiative. Following benefits were foreseen:

  • Remove ambiguity for the team and project members,
  • Simplification of knowledge sharing with the new team members,
  • Transparency of the process; clear and sharable with Confluence link,
  • Professionalism, it is always good to know that responsible people know what needs to be done

Before the meeting with the Sponsor, I have prepared two artifacts.

  1. Table with the time needed for the process & time I have spent with other participants just in meetings.
  2. Process outline in the BPMN notation
How oftenWhoWhatTime invested (minutes)
one timeChange TeamStakeholders meetings150
one time Change Team Change proposal60
one time SponsorApproval5
1/projectChange Team Requirements data delivery15
1/project Change Team Tacit knowledge gathering15
1/project RafalData analysis 10
1/project RafalData consolidation 10
1/project RafalNew process design60
Total325
The time needed for the process to keep on rolling
Time invested for the meetings during reference projectDate
30010/12
12015/12
4017/12
6003/01
12005/01
6010/01
30019/01
6024/01
48029/01
1540
BPMN process improvement
BPMN process definition

Change team

The first step was to find a Sponsor for the initiative and have his buy-in. It was not easy from the beginning. I analyzed data based on my project and estimated potential time-saving in the long go. My estimation for the first noticeable benefits was set to 6 months.
I have held a few meetings with the key stakeholders and process participants. Based on the data collected I proposed following solution.

4. Propose and implement the solution.

The process had 3 key phases:

Phase1: Data collection

As we had 14 different cases and depends on the project approach. Data gathering could differ from project to project. At the end of the project, QA expert shared with me all the relevant documents. At this point in time, all the pieces of evidence landed in one Word document. It didn’t help in analyzing it and drawing conclusions. I decided to split it per requirement.
Next step was to have a quick meeting with the person to gain tacit knowledge:

  • who provided key data,
  • when in the project cycle the data was available,
  • key elements of the evidence,
  • required action from the person creating the document.

Phase2: Data analysis and process definition

Once we had enough data for the given requirement first version of the process was created using BPMN notation. How much data is enough? Based on the observation. In our case, it was when we start recognizing emerging patterns. On average it was after five projects. Based on the input I have created a document defining end to end process. It covered:

  • gathering relevant data,
  • communication flow,
  • store it on Confluence.
    Each process was reviewed and accepted by the team members and relevant stakeholders. After that, it becomes the first version of the working process.

Phase 3: Execute

It took us 7 months to have process created for the 12 out of 14 requirements. At that point, we knew that the most important parts are covered.
As of then at the beginning of the project:

  1. the person responsible for quality identify relevant requirements
  2. reviewed project needs
  3. communicated the approach using defined processes to start building transparency with relevant stakeholders.

5. Track results of the change.

We have worked together on improving processes. It happened whenever someone encountered an edge case. This could be situations that were not covered or adjustment to the flow. Depend on the scope of the change we could have to actions:

  1. The person in charge updated the process and communicate it or if the change was bigger
  2. We gather together to ideate on the best approach to incorporate it in the current flow.

7. Plan for the future and sustain the change

During the next 12 months after finalizing the process, in the team, we didn’t experience any tension or will to get back to old habits. The change was successful. Accepted by the team and organization. Once per while we experienced some tension on the flow, but it never happens more than once or twice. Whenever the situation happened we reviewed current approach adjust and formalize it in the process.

Final thought

In the end, our department got all the expected benefits. The time wasted for the clarification of the responsibilities and managing expectations was gone. Other expected benefit of this approach was knowledge transfer needs. As it was clearly defined:

who do what by when in the project cycle.


It was also easy to ask for help. When any of us was swamped with the project work less busy colleague could help. And these things happen as the whole task was independent and encapsulated. New joiners were able to work on it without any additional guidance. All the actions and already collected evidence were accessible via Confluence for the reference.

Take away

What can you take with you? Whenever you work on:

  • the repetitive task,
  • you have dependencies,
  • it’s not clear what should be done start with:
  1. Identify the current situation – how the work is done? What are the good things? Where are the bottlenecks? Try to collect some data. It’s always good to have a conversation based on the data and not assumptions (or emotions). Visualize it – it helps in fostering conversation.
  2. Ideate ideal state – what are the perfect conditions for this situation. Consider organizational possibilities and limitations. In the best case, you will organize a meeting with all the stakeholders. Listen and write down their struggles and concerns. Bring a common understanding of the possibilities and challenges.
  3. The gap – identify first possible steps that could be taken to close the gap moving you closer to the ideal state. Very often you will be able to identify quick wins. There without much effort, you can get quick improvements and results. Things like checklists or any other quality gates can help here.

And last but not least. Do it together – as a team. It helps to boost morale and bounds within the team. There are not many better ways for team building. Solving problems together and see it working, benefit from it is one of the most profound experiences as a team.