During a project, let's make sure we understand the root cause of all issues.

As we close a project, let's list what we have learned.

As we open a new project, let's ensure that we do not repeat the mistakes of last time.

I think you need to distinguish between analysis paralysis -- that is, continuous analysis with no intention on moving forward -- versus understanding root cause and applying lessons learned.

- Unparalyzed

Dear Unparalyzed ...

There's a subtle distinction to be made here, which starts with the recognition that the root-cause/don't-repeat-mistakes approach often isn't based on an underlying detailed model of the overall system. Without that systems model, there's no good way to predict the impact of any proposed change; what appears to be a mistake might easily turn out to have been the least of the available evils instead.

The approach I've been discussing differs from yours as follows:

Start with a detailed model of how things work.

Build a methodology based on that model.

During a project, keep track of what doesn't happen the way the model predicts things should happen.

During the debrief, discuss how the model needs to be changed to account for the occurrences it failed to predict.

During the debrief, determine how the methodology needs to change based on the improved model.

It's steps 1 and 4 that generally don't occur in the standard approach to continuous improvement.