An Unexpected Benefit

All I could see in the meeting room were sad and worried faces. This was our regular Monday morning, start of the week project meeting, which was usually a pleasant occasion . We all came together after the weekend,  with everybody rested and full of energy to continue the project we worked on. But this time the drive and the enthusiasm were gone. People were worried and even resentful because it seemed that we failed at our first actual step in our project.  Previous Friday we spent the whole day to finish our proposal for our first PDCA cycle, to send to the company management for a formal approval, before we left. Now we had an unexpectedly quick reaction to it – and it basically said, “you are forbidden to do this”.

Just for you to understand – we did not rush into this project heedlessly. We had a huge official kick-off with top managers explaining how important the project was for them. Then, in our preparation phase, we spent weeks on making a good charter with risk and stakeholder analysis and had it discussed with and approved by the top management. After having understood all our scope, organization and risks we developed our plan for the first PDCA. And then, the rejection came back very fast. It was even politely implied that we should have known better then to propose such a silly plan. No wonder my colleagues were despondent and losing motivation by the minute.

I was checking for the nth time our PDCA. It was a classical first PDCA where the most important obstacle to reach our target condition was the lack of detailed process knowledge. Fully in the spirit of Toyota Kata our proposal was to do several Gemba Walks in the impacted departments, talk to the employees and record our findings in the “What did we learn” section of the PDCA form. Simple, almost self-evident. I could see nothing wrong there.

Checking the management reaction showed that they forbade us to visit two of the four planned departments on the grounds that they already had projects running and should not be disturbed by the message that a different team is now looking into the same process. This made me pause – were those untouchable departments listed as ”out of scope” in our charter?  After a quick check we saw that they were listed as being “in scope”, even essential, for our project goal. Was our charter approved by management ? Yepp, it was.

As the most enthusiastic proponent of PDCAs,  I felt a bit of guilt for having led the team into a disaster in the very first cycle we tried, but was also relieved, as we really did everything by the book. If we looked at the story with less emotion it was in fact a success. Just think about it – I told the team – if we did not start our PDCA and turned to active steps so early in our project we would have spent weeks in the happy assumption that we were allowed to work with all 4 departments. Even worse, we could have planned crucial activities with them for later and would have learned that they are unavailable so late, that we could not have corrected our project plan.

This way, by taking concrete actions very early in the project the cat had to jump out of the bag at the earliest moment possible. We still had time to adapt and to make this project a success – and all this because we ran our first PDCA at the earliest possible date. This speech was not an easy sell, but the team ended up accepting this view and later we went on to a different approach based mostly on unobtrusive data analysis and finally managed to deliver the insights the management needed.

So, what happened here and how was PDCA helping? It is quite common that people treat project documents, like charters, risk analysis, scope etc., as formalities that have very little connection to “real  life”.   By agreeing to our charter and scope the management at this company did nothing very out of the ordinary. Maybe someone had thoughts about mentioning those other active projects but decided not to waste time on that discussion, just for the sake of some “formalities” no one really cared about.

Now, the moment we proposed concrete steps, like visiting the department on Monday next week, we jumped the divide between theory and practice. The impacted manager had no choice but either to allow us to visit his department or to lay all his cards on the table, and this is what he eventually did.

One important benefit of working with PDCAs, that we rarely talk about,  is exactly this effect of moving to concrete actions very early and making the project be much more “real”. This can be quite shocking to teams used to carefully analyze problems to death before taking any actions, if at all.  Even in simulated PDCAs many people tend to argue about the way a problem should be solved for long periods of times, instead of proposing an experiment, however simple. I find myself quite often in the role of the simple minded participant  repeating our catchphrases all the time  : “let us just try it” or “how can we test this in practice?” in our project meetings.

Of course, we do not advocate to recklessly jump to large actions with high potential impact in the first PDCA cycle, but we definitely start with concrete small steps immediately. This sends the very strong message to all involved, that with PDCAs we will avoid the trap of too many hypothetical discussions and seriously aim to change the processes we work with.

In the end the main purpose of each PDCA cycle is to do an experiment to learn something about reality that we did not know before. This first, apparently failed,  PDCA  in this story certainly achieved this goal and was the key to our later success.  But in this it was no different from other, seemingly more successful ones. PDCAs simply  cannot fail, by design, because even by “failing” we learn important lessons and then we did not fail at all. We just take a deep breath, apply the learnings and design a better next cycle for the next round.

Start image is from hotpot.ai