“Haphazardly successful”
After a long and unsuccessful meeting, an ex-colleague from Spain once asked me if I knew what they would say about the Germans. I said no, and he explained that they said the Germans would make the best plans but if these do not succeed, then Germans do not look for an alternative solution, but prefer to argue forever about what was wrong with the plan and do not get out of it.
Naively, one may think that it is good to learn from mistakes and thereby make future plans better. But there are several catches:
Not every point in time is equally suitable for making such an inventory. First of all, it should be about an adjustment of the plan or a variation and improvisation to solve the problem. No matter what the plan looked like before. The retrospective can happen later.
When the time has come for the inventory, it is worth first questioning how important the part of the plan that went wrong was. Was it possibly a detail that influenced the final result only to a small extent insignificant? Or perhaps an aspect that rarely really comes into play and should therefore be classified as a purely academic problem? The question that is actually in the room is how detailed a plan should be.
I have often experienced the second point in software development teams: every “ifs and buts” and “would and would have been” and “maybe” is discussed in detail. Every little detail must be addressed, spoken, recorded and chiseled in stone. At some point, the duration of the discussion is no longer proportionate to the result and its value.
In the agile world of thought, you learn to deal with the fact that a plan is not worked out down to the last detail. You make a rough plan and start implementing it. It is agreed that there will be deviations in the plan. Since you start with the most important thing and look at, examine and evaluate the interim results again and again, and thus realign yourself, something useful is already created very quickly.
In fact, “over-planning” can be observed not only in the development of products, but also in many other places in a company, e.g. in organisational and administrative measures. Without necessity and obvious reason, for example, there is discussion about whether meeting minutes are necessary. The discussion deals broadly with the question of whether they should be created electronically, whether you use Word or rather an online tool for this, whether they need to be archived and for how long. “Not that someone says afterwards that we are not well prepared!”: sheer nonsense. If the meetings become more numerous and should actually turn out that a protocol is really necessary, then and only then, should it be introduced. And the reason for the introduction certainly determines best to what extent and in what form the protocol must be drawn up.
“Being prepared for every eventuality” is usually neither a professional nor a good approach. Firstly, it turns out differently and secondly than you think and then there is Murphy. It’s not about not making a plan at all, but with little effort a sufficiently precise plan. It’s about knowing and sensibly assessing how detailed the plan must be.