Surfing in projects
If you inspect something you will learn about it. Your learning will lead to new insights that will lead to action. Action needs to be inspected and new insights will rise new learnings and further paths to inspect. Sounds like infinite play of waves against the shores and sure it is.
If we take for granted, that we'll learn on the way while we inspect something - when we analyse something - then we cannot deny and have to admit, that the learning is something that changes reality. So staring at reality and learning about it rises the need to deal with change.
Analysing too much, before taking action on it, creates waste. It is not only the waste of missing feedback, to a greater degree I think it is the waste of not catching the insight and the learning. Not preserving the change seems like wasting the investigation at all.
Back down the big analysis change wave
Let's have look at the most project management techniques: Usually we plan, when we have the least knowledge of a project ever. There is huge front-up planning at the start of each project, so we analyse a lot. Makes sense? Yes maybe, but do we really preserve the learning we've created? Do we fully accept that we changed our view about the thing we investigated? Not sure, in most times I would say yes - if the chunk of change is small enough.
As I said: While we analyse we change our view at a lot of things. So with each analysis we need to manage more change. Again: the more we analyse, the more we have to manage change. So far the creation of a big plan, without handling the wave of change created by the analysis, leaves the learning and preservation of insights behind. Instead of making big plans which drown us, we should focus on small batches to analyse where we can cope with the change we've created. So we need to find a batch size so small, that we can cope with the change we created.
Making the drop
You are shouting "Coming down" when you are the first to drop into the change wave? Only few surfers are brave and skilled enough to survive the big waves. So why not surf on the waves big enough you are able to deal with. Even when there are always a lot of change waves following, as soon as the ocean bed flattens out:
At the moment we hand over our experience, means sending out our deliveries to customers and users, we create more change. Now change might increase more than linear, according to the batch size of done work and people involved. If we take feedback outside of the team into account, then there might be a good reason to move to an even small batch size of analysis to cope with this wave of insights and demands again.
Making the drop - again
Now, how can we really make the drop - again and again? To me one answer is to work in small timeboxes, where each timebox represents a small batch size of delivery and a deadline. Furthermore I would arrange a framework around it, which is able to inspect and adapt. This framework should be able to deal with experiments and feedback: something like a plan-do-check-act cycle. Fortunately here is already something out there and they call it Scrum. Wanna try it?
PS: Socrates said: “understanding a question is half an answer”. .. and I want to append: "the second half of answer will change the question".