Deal with Causes, Not Symptoms

The health of any entity, whether it be a human body or a project, is both created and sustained through careful attention to root causes.  
 
When dealing with a fire, of course you first reaction will and should be to extinguish it. Once the fire, or critical situation in your project/work, has been dealt with try not to get back to business as usual but spend some time understanding what caused the fire/situation. In doing so you may very well be able to identify the reason(s) that caused the situation. 
 
In complex environments/systems this may not be easy at first. Do not play the blame-game.
 
In a project Erik worked on many years ago, he was confronted with a stuborn project manager who, after having attended a mandatory Prince2 course, was mindlessly filling in the templates. As a result the work this PM produced was sub-par. Initially the reaction of the executive was to reprimand the PM. Erik's initial reaction was also more geared towards the quality of the work then the reason for the stuborness. Afterall, the PM had over 25 years experience and it seemed out of character. Only when Erik started proding a bit more for the reasons behind the PM's behaviour did it become evident that the PM in question was never consulted about the contents of the templates. Remember that this PM had over 25 years of experience.
 
The root cause seemed to be not a lack of understanding but more a lack of buy-in. Once that was established Erik suggested a review of all the templates and subsequent modifications.  This completely got rid of the problems. Problems, because during the review it became clear that the PM in question was not the only who had not been consulted.
 
See also "TEMPLATE LESSON LEARNED"