Having established what output the team really wanted to deliver during the week, I hoped to be able to identify some key problems this time. Luckily, we managed to do all 30 minutes Project Review Meetings in life mode instead of a conference call, which at least allowed participants to see each other and to share some small talk too.
Again, the first reaction to the agenda of the five questions was defensive. Somehow, people don’t like to be asked about what’s gone wrong. I will explore how we can further improve on this. I’m not too fond of this negative mood yet. At another client, we have started to explore how to merge Lean & Agile, and the Toyota Kata with some of the techniques of Appreciative Inquiry. Which would lead to a slightly different five questions:
What has been our greatest success last week?
What have we accomplished?
In what context can we copy that same practice in order to achieve similar results?
Where do we start?
When will we see the results?
The results of that look promising, but for now I decided stick to the beaten track and to dig for problems in projects done by the Firm and the JV. So, I took the original agenda (What has been our target for last week? What have we accomplished? How come we didn’t accomplish all we wanted to? What do improve first? When will we see any results?) and managed to identify problems in all three pilot projects.
Not reading standardized work instructions
One project was not delivering because of a mismatch in expectations. The project manager of the JV wanted to calculate a fully detailed budget for all machinery to be delivered in their project and couldn’t do so, as long as the detailed engineering hadn’t been completed. Then the project manager of the Firm clarified that he didn’t expect a detailed budget at all and would be happy to go for a reimbursable model of invoicing, combined with open book accounting. As agreed in the contract. This had been explained already during the team building sessions and written down in a first version of the Standardized Work Instructions, but the true meaning was clarified only now. So we decided to read the Standardized Work Instructions again. They were not as clear as we thought and decided to clarify the new rules of the game a bit better, to adjust the document and then to inform all project managers, both at the Firm and at the JV. Easily to be done within a week.
Another project showed an enormous list of unresolved items to be checked on the last day before delivery. Apparently, all specialists who would occasionally take a look at the design of the production line and who would find an issue, would add this issue to an Issues Database. This was considered to be quite a good measurement, since it assured that all issues would be noticed and not forgotten. However, in this project, none of the issues had been ticked off along the way. They had all remained unresolved, until this last day before delivery. There had been some 150 unresolved issues, waiting for a solution and approval by one of eight different specialists. Of course, this was hardly possible to be done. As a result, it hadn’t been possible to close the project. We did a root cause analysis:
1. Why had all these 150 items remained open until the last day of delivery?
Because the project manager had not taken the time to solve them before.
2. Why hadn’t the project manager taken the time to solve them before?
Because resolving issues was not a part of the planned work for the week.
3. Why wasn’t resolving issues part of the planned work for the week?
Because issues were just written down in the database, without an owner and without a due date and then left alone.
4. Why were issues just written down in the database?
Because there was no habit of adding issue resolution to the work plan for the next week.
5. Why wasn’t issue resolution part of the plan for the week?
Because there wasn’t a proper standardized method to plan and monitor the work for the week in the first place.
As a countermeasure, the team decided to add a review of items to be checked to every weekly review. And to add issues to the regular weekly workload for the week. The Standardized Work Instructions were to be adjusted accordingly and all should be told about these changes.
The third project failed to plan the required field studies. The one responsible for doing this didn’t to do it, because he didn’t have all the details ready. We analyzed this and concluded that it shouldn’t be necessary to have all the data ready before planning the meeting. Specially since it might be expected that by the time the data would be available, booking the meeting would be virtually impossible. We decided to add a instruction to the Standardized Work Instructions, to plan the field study ahead and invite all required specialists on the first day of the project and not to wait for the data to collected. This should avoid trouble in finding an appropriate date for the meeting.
Three projects, three simple adjustments to the Standardized Work Instructions. The beauty of this week was that the Project Managers in these projects took control over the process, by addressing problems -as opposed to appreciatieve inquiry-. Solving problems generated a lot of energy too. It’s actually very nice to get ones’ problems and troubles out of the way!
This blog is part of my LAPM Implementation Journal: