When to plan, when to react





Few examples follow.

 Planning is beneficial with Reaction is beneficial with
Customer objectives, priorities and requirements that are known, well understood, and stable Customer objectives, priorities and requirements that are uncertain, ambiguous, or partially unknown, that are volatile and can change because of things that are outside our area of influence and control
Domain that is know and well understood A new unknown domain, a complex domain or a wicked problem
Well known, well functioning, stable technologies A technology that is unknown, novel, unstable, still under development, or used outside contexts and limits tried before
People that know each other and worked together before or worked to similar problems with similar approaches, and the level of interdependency is low
People that don’t know each other and is used to work to different kinds problems and with different approaches, or the level of interdependency to other teams/departments/external partners/suppliers is high   
External dependencies, as other teams/departments/external partners/suppliers, are well known and understood, stable and their response time and service level is known and stable  Some external dependencies are unknown and not well understood, are unstable or their response time and service level is unknown or unstable    
Just enough, just-in-time
When circumstances changes, with the suitable speed, when it is the appropriate time to act

In every project the mix of things on the left and the right can be different.
Sometime even during the same project the mix changes as circumstances change.
A good balance of planning and reacting depends on that mix.


Planning is a form of anticipation, reacting is a way of adaptation. These images below show some examples of the balance between the two:














Back to: Planning ÷ reacting: finding the balance

Print | posted @ Wednesday, June 25, 2014 9:19 PM

Comments have been closed on this topic.