Some of it depends on the seriousness of the flaw and the likelihood of it being exploited, versus the inherent risks of applying the patch.

For example, with the WMF patch I manually tried out a W2K and XP workstation and then rolled it out straight away. In this case it was a serious flaw being actively exploited, and the risks of being hit by a nasty outweighed the risks of the patch screwing something important up.. and even if it did have problems, it was only going to be pretty limited.

On the other hand, when it comes to IE patching we are much more careful - exploits via IE tend to be one machine at a time and can be largely mitigated by anti-virus and antispyware apps. IE patches have a tendency to break business critical applications for us too, so on balance we tend to evaluate those for much longer.

Basically, when Patch Tuesday comes around we do an analysis of all the different factors individually for each patch and come up with an action plan for each individual case. We draw up a draft plan on the Wednesday and authorise any "no brainers" and then that gives us a couple of days further investigation before we hit the weekend (which is a good time for patching servers).

It's important that you set some time aside every month for an analysis of the updates. I've set up a reminder function in Exchange for all the relevant people on our side (starting on the Pre-Patch-Tuesday-Friday) as a reminder.