Now that we're officially out of a disastrous decade, we can make fun of one it's signature expressions "too big to fail."  The idea is that, regardless of whether we wanted to end up with them, some institutions are so big now that letting them fail would be worse than anything else we could do. (Who'd have thought that after ten years of our politicians' historic misuse of language, the biggest head-scratcher of the decade would come from some obscure finance industry regulator.)  

But as we bash our politicians for getting us here, we can learn something too.  How many of our own projects have we allowed to get to a "too big to fail" state of mind?  When something is complicated, like a Web project, the "big" solution is tempting, whether its the requirements "this time, we're going to get a real UI design!" the technology "we're going to build for high scale from day one!" to the commitment level "we're going for C-level buy-in from day one!" to the process "we're going to put everything through a real change request process this time!"  And still we find ourselves taking longer, doing less, spending more than we planned, and wondering how to go EVEN BIGGER the next time.

But with "too big to fail" now imprinted on our psyche, maybe we can finally realize that success usually means doing just the opposite - going small.  Really small.  As in, as small as you can possibly make something.  

Going small is not a new concept, but it's gaining speed.  Most notable, for software development at least, is the "Agile Process" which has been around for a decade or so.  (We've adopted it here at Percussion, first for our Solutions offerings, and now for all our software development.) But there is more here than a process revolution.  Witness the proliferation of Widgets and Gadgets, "app stores" and the success of products like Twitter built entirely as a "side project."  Each does one or two simple things, often without any ambition to ever do more.  Many end up being something totally different than even their developers anticipated.

Organizations are starting to learn that the problem with "going big" wasn't size, but hubris.  We think with more information, research, buy-in, debate and design, we can make better decisions.  But reality is closer to the Heisenberg Principle; it's not that we didn't know enough to predict, but that we cannot ever know enough - not until it actually happens. 

"Get it live, then decide" may seem backwards but it works. It is then that "going small" suddenly makes total sense.  It means you'll never build too much before you know whether it was ever going to work.