This is often the knee jerk reaction that organizations go to after a minor or major catastrophe, and I'm willing to bet that's what Australia's CommBank is wrestling with right now.  I've even argued against the use of the previous version of SMS 2003 and "it's too dangerous" was one of several of the bullet points.

Out of the box, it is too dangerous.  The way people typically architect the entire solution (which is to say, they don't) is too dangerous.

I'm going to go into more detailed steps with screens in a future blog posts assuming that they are still an issue in SCCM 2012 (and I have no doubt that some of them are) but I wanted to touch a few things that I did to mitigate the risk so that the benefits could be enjoyed.

At a minimum, access to do anything to or with this collection should be restricted to one or two people, preferably two people that don't actually work with the system day-to-day.  SCCM has very granular access controls (so granular that few people bother to use it and I'm told it's been dialed back in 2012 to strike a good balance).  The issue above was an administrator accidentally including All Systems as criteria for advertisement of a task sequence.  This wouldn't happen where I work.  Aside from the collection being restricted at the ACL, everyone who administers it understands the mantra of "Don't use All Systems."

Rinse and repeat for All Workstations and All Servers.

At a minimum, you need three categories for deployment.  Since SCCM is targetted at larger organizations, you likely need more than six.

The first category is "hopeless victims".  These are the workstations of your experts and volunteers.  Include people that have regular backups and that understand, fully, the dangers.  These folks should also understand that it is their responsibility to report problems --- any problem --- immediately, if they suspect it was from SCCM.  Servers in this category would have to be pure development, with impacts to them being minimal if they went down.

The second category is "dev/test".  These are servers your organization would survive a couple of days without at moderate/low impact.  For larger organizations, this would be at least two groups.

The third category is "production".  For organizations with redundant systems, I'd insert at least one additional category "Node A" of redundant systems, followed by subsequent nodes before going to applications that have servers that are a single point of failure.

That's the simplest implementation.  On the workstation side, it's a good idea to create collection criteria that spreads user impact evenly across functional areas.  Make this judgement based on the number of people that can be out sick for a day before a department fails.  Don't deploy anything to more than that many of those user's PCs in a 24 hour period.

Thankfully, the management staff from my level up is fantastic.  They understood the dangers and were willing to sign off on a policy.

Here are our rules:

Nothing gets deployed company wide on the same day it's advertised regardless of its scale.   Regardless if the roll-out is a screen saver for Marketing that goes to all customer facing users, a security patch that isn't being actively exploited or cannot be mitigated through other means or a general operating system deployment that goes to all workstations, the advertisement is at least a business day in the future.  The reason for this is to give a window to account for administrator error.  I've personally been saved by this rule.  I advertised a full Microsoft Office 2007 Professional installation to nearly the entire company (at the time about a 1GB install, multiplied by ~5,000 workstations many of which didn't meet the minimum requirements for that version).  That 24-hour buffer allowed me to review where the deployment was going, and reverse it.

Each roll out group is given one day's buffer.  To the above point: The first group (the "hopeless victims") are the only ones to receive the rollout after one day, and they're given at least one day to provide feedback.  If you've picked the right people for your hopeless victims, you won't have to send an e-mail to let them know to "watch out", they'll scream properly at the first hint of a problem.  The reason should be obvious: containment.  As you roll out, the risk for problems is highest initially.  As each group is added successfully, the risk is reduced while the surface area is increased.

No exceptions, except.  Identify every exception you can.  Some of these are personnel issues--Marketing wants a new screen saver deployed company wide, they just finished testing it and want it there tomorrow.  For my own job protection, I wouldn't do something like this without C- level executive sign off.  Decide what's enough accountability if things go horribly wrong.  Most deployments of this nature are not emergencies, they're eagerness by people who don't know and shouldn't have to care about the risks (that's your job!).