Patterns can be used to generate stable systems, such as project environments. (Jim Coplien's generative organizational patterns are good examples of such patterns.)
Software projects are seldom stable systems, especially when under intense time pressure. Project leaders/managers spend much of their time applying "corrective actions" to bring the project back into stability, either by rebalancing forces or by restructuring the project. (Projects can pass through many types or variations of structures during their lifetime.)
Corrective Action patterns are those patterns that capture knowledge and experience on how return a system/project to stability.
Many Anti Patterns are Corrective Action patterns gone awry.
-- Dave Smith 10/19/95
I'm taking a bit of a leap by positing a new classification. Feedback, please.
I don't over-use the word "profound", and that's profound. -- Jim Coplien
Project leaders also employ Preventative Action patterns, which seek to keep the project system in stability by removing or mitigating potentially destabilizing events. -- Dave Smith 11/1/95
I wonder if Corrective Action patterns are really not so much patterns in themselves, but a measure of the divergence away from a pattern. In other words, if a software project is entering territory from which it should return (via the postulated Corrective Action), wouldn't it be returning TO a state wherein proActive patterns apply? -- Bob Gleason
One of Alexander's key principles is the principle of diagnosis. He is also concerned that budget always be in place for repair. The Corrective Action pattern fits nicely with A's ideas. -- Brian Moore
Knowing that Ward likes to see excerpts of other publications and pages here, also that wiki supports group conversation, here are a couple of paragraphs from the Risk Management Catalog, a closely related topic ... (Located chez members.aol.com 
)
?Project management by risk reduction will only become common when there is a catalog of risk reduction strategies available to every project manager and team member. Feel free to download one of these pages and edit it to describe a risk reduction strategy you have encountered. Send it back to me and I'll put it into the catalog. Please put your email in so an interested reader can contact you about your suggestion! At some point, we shall find a way to organize them to make a proper catalog. In the meantime, we'll be putting our heads together. ?
Team Per Task part of Distractions To Progress at (members.aol.com )
Sacrifice One Person part of Distractions To Progress at (members.aol.com )
All At Once part of Efficiency By Parallelism at (members.aol.com )
This last has been informally rechristened to Day Care. Each page works diagnosis to prescription using a topic-specific pattern form. Incidentally, I am looking to host a workshop on Risk Management (patterns or strategies) this August, but have not decided through which organizations to host it. Any suggestions?
If you are still looking for alternatives to All At Once, how about
Fire And Remember (a take on Fire And Forget, though if my explanation is needed, then the name loses it's major point) This name mostly refers to the later communication of upstream to downstream processes.
the tongue in cheek Walk And Chew Gum (excuse the near pun) misses the former discussed aspect, but is as clear as can be on the parallelism....
The All At Once got renamed to Gold Rush after a project manager thought that All At Once meant Water Fall!!
Actually, all of my risk reduction project management patterns are of the Corrective Action variety. There is not even problem mentioned, there is only a set of indications. The default problem is that the project is out of balance. These actions can be taken in advance to avoid getting out of balance, or as remedial actions at the time. -- Alistair Cockburn
In cybernetic terms Corrective Action is a kind of feed back and Preventive Action is a kind of feed forward. Feeding a signal back into a system can be an effective tool as long as it acts to reduce the original error (Feedback Is No Cliche) but can go badly wrong when random or acting to make the error greater. -- Dick Botting (3rd Nove 1999)
See original on c2.com