Failing Small

One of the things I've learned over the years of building standards is that the best way to implement something new is to have several good examples of what you work with.  The first one should be simple, and will get you probably two thirds of the way there.   The next should be equally simple.  If you can do it the same way, you've probably validated your initial approach.  The next should be a bit more compex, and expose some of the edge cases you ignored in the beginning.  If it still fits in without change, you must be a master at this already.  That has never happened with anything I've worked on. 

After you get that far, you really need to try this out at several scales, first just by testing, next in a pilot, and finally in regional and national deployments.  Each time you try it out, you move up a level in scale. The advantage here is that each time you can bring lessons learned into the next stage.  Unfortunately, when programs have lofty goals, they often don't allow enough time for the pilot and subsequent stages.

That can result in abysmal failures.  We've seen examples of this in implementation of Health Insurance Exchanges in the US and in my home state, as well as in many national projects worldwide.  

The point is that not only do you want to fail fast, but also to fail small, so that you can succeed big.