From "think unless" to "act unless"

There is this old issue of "analysis paralysis". In other words, spending lots of time on analysing a problem at hand, studying several potential solutions, all the while not solving the actual problem as it exists in the real world. This has resulted in several caricatures of analysts and designers losing themselves in "model space", while enjoying large quantities of coffee in their ivory towers.

Meanwhile, at the other extreme, we find the pushy project manager who only has sight for the project deadlines, as well as the eager, hyped on coca-cola, engineer who already has "the solution" and looks in total amazement at those analysts who still haven't found "the solution".

Then there are cases where one makes hasty decisions during analysis and design, bravely referring to "pragmatism", where this is really used as an excuse to not think. "Well, you know how it works in practice, we have to be pragmatic". More often than not tomorrow's legacy in the making!

Somewhere deep down, all of us really know we have to think before acting. We all know about the proverb of sharpening the ax before cutting the tree. At the same time, it is wise to make sure we do not end up with analysis paralysis.

In my opinion, when confronted with a "problem", we should start by gauging how much time is available before a solution should really, really, really, be implemented. Say n hours. Now divide n into two halves. During the first half, we should operate according to the principle of think unless, while during the second half we should adhere to act unless. In other words, during the first half any urge to start acting should be treated as suspicious and as a signal of trying to "avoid thinking in the name of false pragmatism". During the second half, any urge to continue thinking without acting should be banished, and branded as an attempt to shy away from actually getting work done.

Of course one should always be prepared to reduce n when we learn new facts about the problem, and jump more quickly to the act unless mode when needed.

During the think unless stage, several excuses may pop up triggering us to start acting prematurely. Use this as a trigger to once more establish if your estimate of n is correct. If so, once again examine your assumptions on what the problem really is. Is the designed solution really going to solve the right problem? How can you be sure? Doesn't it cause undesired side-effects? Do you have the abilities and resources available to realise the solution during the act stage? If you're absolutely certain that you're on the right track, then take a deep breath, and move to the next stage with confidence. Once in the act unless stage, make sure you don't fall back into thinking unnecessarily. Accept the fact that you haven't found the perfect solution. In the end, a solution is better than no solution.

If you're not really sure about n, one strategy might be to start by formulating a time-boxed hypothesis of the problem and its solution. Then expose these hypothesis to challenges/scenario's, and continually refine the hypothesis of the problem and its solution. Once you're halfway through to n, trust your hypothesis and stick to it! That is, unless you really hit a big snag. Then it is time to use the unless part of the act unless principle.

Getting stuck into analysis paralysis might at times be caused by analysts loosing themselves in "model space". However, another important causes is reluctance of decision makers (not just the analysts and designers, but also sponsors and owners) to make decisions when there is no analytical answer to be found. In other words, reluctance to take the lead. True leadership requires the courage to make gut feeling decisions. These cannot always be rationalised.


  1. In Lacan's theory of Logical Time, there is "a moment to conclude". Lacan is one of the few thinkers who appreciates the need to explain why decisions and actions take place at a particular point in time - helping us understand, among other things, how decision-makers are affected by haste and hesitation.

    Business Organization Management (time)


Post a Comment

Popular posts from this blog

Three perspectives on enterprise architecture

Models that matter; Return on Modelling Effort

Fundamentally understanding IT? - Why Web 2.0 needs architects. Part II