I forgot who put this idea on my mind – but I am pretty sure it started with me finding a tweet about this topic, and then getting all excited at the prospect. It sounded very logical for me, and I was sure I can get one of my customers to try it out. Due to contractual issues, I will have to explain this in general terms, and hopefully it won’t affect the point I am trying to explain. I planned to blog on this earlier, but did not get to it. And then yesterday, Ray Wang said something about fail fast on twitter, and I thought now would be a good time to get this blog done.


Well, it was actually not very difficult to convince the customer. I pointed him to all the literature I had read on the topic. So as not to waste too much time or money, we decided on choosing 3 options to solve a problem, and stick with the best idea to implement and discard the rest. The time frame was 10 days, and each option was worked on by a 2 person team. Generally, we thought that one great solution coming out of this will be totally worth the trouble.


Each team took 3 days to design and mockup their solution, and then they invited business to check out the solution. Option 1 was a non-starter, and that team agreed to step down and let just the other 2 teams go forward. Business liked both options based on their mocked up version. 3 days later, both teams had a working prototype. Once business tried these two – they like option 2 a lot better. So option 3 was killed, and we all agreed that option 2 was best solution. And we finished in 7 days, which was a big saving compared to our plan of 10 days. I was indeed feeling rather smug.


Well, I was wrong – at least mostly wrong. It is a long story, but here is the Reader’s Digest version.


1. Business thought that they could get this solution in a few days in production. They hated it when they realized that everything has to be built according to IT standards again, and they said “shoot, so we wasted all this time? we will never do this again”.


2. Since it is not the first time business has taken this stance, we knew what to do to get them back to the table. So they co-operated and we got the solution developed. Except, just as in normal projects – we started hitting integration problems. Again, to cut to chase – we figured that from an integration point, option 2 would have been a lot easier to do. Few meetings later, we switched to option 2. There is no way we would have known of these issues in initial 7 days, since the pilot did not plan to go that far in the first place.


3. When this was reported in the steering committe – they were not exactly thrilled. The general message from upstairs was “We encourage educated risk taking – so we are ok with you having tried this out once to see if it worked, but we should stop now. We expect IT and external consultants to bring best known methods from past experience, and not just go on a product development type activity”.  We also got chided a little for not respecting the time spent by some business users, who all had to wake up at early hours since they were a few timezones away.


We do a post mortem as part of every implementation, however large or small. And while we totally understood why it did not work the way we planned in our case – we also had to agree that this might not be a good scalable model to go forward with. At least not before we find something new to change our minds.


Lessons learned, and some tips if any one else wants to try this in an implementation scenario.


1. Business teams are generally not used to this model, They expect a more structured waterfall type solution where people do a detailed design for one solution. Essentially, there is some significant change management required to pull this off.


2. Choose the scope of the pilot carefully. If we had chosen to include integration aspects to the pilot, maybe we would have saved some trouble. However, this would make the pilot a more exhaustive exercise, and it comes at a higher cost if 3 options needed to be taken that far, across a large project.


3. Consulting contracts typically do not cater to this kind of model. Even if customer is willing to pay, it is hard to estimate the effort since there are no known metrics to depend on. And not many customers will want to do this on a “Time and Materials” basis, since it can be very open ended.


Maybe this is an excellent way to go about product development for a software vendor. However, in my brief experience, I am not a believer of this working out for a project, especially the big complex ones with lot of integration points, multiple time zones and so on. Or quite simply, I might have attempted this in the wrong way from the beginning.


I am all ears, and would love to hear success stoies of people who could make it work in an implementation project scenario.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Anonymous
    Hello Vijay,

    Realize in this general example you are discussing a specific project, which no doubt is on top of a stack of technologies from SAP,IBM, and others, but thought I would chime in as I was interested to check your experiences on this topic given some similarities in our backgrounds, but from different perspectives.

    I was one of those guys back in the mid 90s doing such things that were popularized by others– notions like fail fast, lean venturing and the like.

    Our small private lab and incubator in conjunction with the web and global social/learning network proved a good place to experiment. We found that fail fast worked in a very specific context, particularly in the early days of the commercialization of the web, and so we shared it with the network that included most universities, top tier VC firms, and many leading corps. The fail fast scenario worked well for us primarily due to the newness of the medium — much of what pioneers were doing in those days hadn’t been tested, particularly relating to consumer products and businesses.

    However, like so many trendy terms and acronyms, me too efforts in venturing and when passed on in social networking, many essentials were lost.

    For example, we found fast fail to work particularly well in trying out applications for a specific audience — one that comes to mind was the original portal and campaign “shop the web” — 1997,to help jump start e-commerce for SMEs. In this case it became viral immediately, growing very quickly worldwide, but there was no infrastructure in place in AZ to scale such a venture. It turned out to be a great idea that benefited others– primarily search engines and major retailers in SV, so we killed it quickly. One lesson learned in that case included that in the consumer web requires massive scaling, often free services with a very high break even point, and with applications and models are easy to copy– usually are; so public incubation should only be attempted by those with a fast success infrastructure in place. You can see that in evidence in how some of the super angels, VC incubators, and consumer web incubators are structured.

    At the time we were already working on enterprise applications and systems, which we found to be very different, and frankly I am surprised by how influenced the enterprise market has been by consumer innovation–needs, interests, and models are all very different, even if the needs of a human working with computing are similar.

    In my experience fail fast doesn’t work well in the enterprise, except perhaps for small apps like mobile or to test new consumer web applications. The bulk of the important systems, architecture, and applications for us have been long-term, more traditional R&D, with certain milestones that require agile testing. I view the enterprise more like “prevention is the best medicine”, and “innovate until we get it right”, in part because the stakes are so high.

    But again these days I am working on holistic architecture, and this case sounds more like a smaller project to test out ideas. I guess the primary issue I wanted to raise is that while popularized terms like fail fast, lean venturing (take your pick)sound simple with broad value, it’s been my experience that at the source a great deal of complexity was found that may have been overcome–usually at great expense, with rich experience that was lost in the popularization of the term– particularly in social media. Thanks for the post and bringing up the issue. — Mark

    1. Vijay Vijayasankar Post author
      Hi Mark,

      What an amazing reply – thanks very much for sharing your valuable experience here. A lot of people who make these popular terms do not try them out in practice, and the rest of us who live in the weeds have to try these out and take a risk on it.

      But , I am glad I was able to try and gain some perspective. So I guess I should not complain too much 🙂


      1. Anonymous
        Yes lots of weeds indeed — it may seem naive on my part, but we were already seasoned– the amazing part is that so many think what they see is all they will get– one of the reasons failure rates are so high in IT venturing– bar to entry is low, but the bar to success is high.

        I did some borrowing of my own from one of the old days of mountaineering who became one of the greats, and wrote a great book “No shortcuts to the top” by Ed Viesturs — very good for any leader.

  2. Dennis Howlett
    @vijay – you didn’t ask the fundamental question – what kinda rat’s nest are we dealing with here in the first place? In my experience, if you have standard (as in vanilla – cough) for most major functions (excuse me while I cough even louder) then the problems you describe are significantly diminished. But as we both know – that’s incredibly rare.
    There’s a whole philosophical argument here but it wont do either of us any good. The enterprise IT landscape is largely a mess so what you experience in these situations is what I loosely call ‘payback.’
  3. Mark Chalfen
    Hi Vijay – great blog and topic. My initial reply would have been to talk about making sure you have a bought in customer.

    But thinking it through further I would look at it in a different light.

    If you have an issue (a business issue) that you want to use technology to solve then you need to invest some time up front to frame the issue.

    Once you have done this, your solution should look to add value to the issue. If you can say it takes a user 20 mins to process an order, and you have 1000 orders a month, if you can reduce that to say 2 mins, you will reduce effort.

    I have first hand experience of this, we automated a financial process that was taking 2 full FTE per country. We proved the theory in an AGILE way. It took less that 10 days to build the prototype. Once the business could see the benefit, they were happy to invest more time into the solution and rolled it out across Europe, saving nearly a dozen FTE’s.

    1. Vijay Vijayasankar Post author
      Hi Mark, thanks for chiming in.

      quick question – in the example you gave – did you try prototyping multiple options, or did you choose one on paper upfront and then use an agile methodology to build and deploy it?

      1. Mark Chalfen
        we had a problem. A process was implemented that in practice did not work with the actual volumes.

        We spent a week or so on coming up with the best solution, and played it back. After that we had the green light to create a prototype.

        We only ever built one solution.

      2. Anonymous
        In this case we were playing catch-up to a viral campaign that was frankly based on two issues — from an economic perspective, given the network effect of the Internet, I was confident that enormous problems would arise in the global economy if a few companies dominated e-commerce, which was the trajectory. Unlike computing, e-commerce increasingly represents the entire economy.

        The campaign was email and became very viral. We had experience in building portals with the internal and external infrastructure to execute, with experience in portals, so it was very much an agile method, even though long before hearing about the new-found religion…

        It was a business opportunity however with sufficient scaling that needed and justified resources far beyond anything willing and able in the U.S. SW. So while specific store front applications needed maturing, the business venture lacked the resources. It was primarily a failure of the financial ecosystem to properly fund and scale new business based on current technology, need, and demand– quite common these days as incumbent industries and technologies control most of the resources.

        If memory serves it required only about a month to get up and running–too fast really but I was personally getting 1k emails per day by end of first week and growing fast so speed was essential in this case. 

  4. David Hull
    Knowing nothing about the actual customer or project, I won’t comment on those items, but I will say this:

    It takes people willing to take risks for innovation to happen. Doing things the way they’ve always been done may be safe and more comfortable for the client, but making a proposition like this, taking the theoretical exercises into the real world, getting client buy-in on it and executing on it, takes a real innovator.

    Sadly, failures happen, but the important thing is that we learn from them. With more people like you taking such chances and sharing the results of them, we all move forward.


    1. Vijay Vijayasankar Post author
      Thanks David.

      I am always up for trying new things – but I am not a big risk taker by nature. If my client didn’t want to go forward with it, I would not have pushed it much probably 🙂

      See you soon at SAPPHIRE


  5. Kumud Singh
    Hi Vijay,
    The term FAIL FAST has been in the air for quite a while now. I personally feel that every one of us experience this irrespective of the fact we realize this or not. For example: A developer can have an idea to implement a design in a particular way. That  may not work and the developer realizes this only after doing this. So whats the solution, the developer should have some sure shot alternatives and implement that as soon as one idea fails so that nothing is stuck.
    This term is applicable at all levels.
    However, thanks for emphasizing the idea in blog.
    Probably I would have to read this thrice to understand in details.



  6. Michelle Crapo
    But the practice leaves a lot to be desired.  When some of these demos are set up they show the bells and whistles that can not be applied to the company’s business.  The problem is without the blueprint – how do you really know what is the correct 3 solutions to offer?

    There is a lot of time setting these up.  Double the work.  I like the idea of demoing a straw man model.  BUT… only if you are sure it will work within the time frame given.


  7. Charles Kichler

    Great message. The key is measuring the risk of failure.  If the project fails and it means a plane falls out of the sky (sorry just finished What Happened to Air France Flight 447? http://nyti.ms/k0yMdr), then no, it is not appropriate.  If we can find non-critical features with limited impact, it is probably a great model. 

    It is certainly a very natural model.  Insects, bacteria, other small critters are each small investments of the species to see how to survive best.  Even high value creatures like human who invest 18 or more years in our offspring uses this model.  A toddler learning to walk falls and falls a lot, but in the end they do get to success and start knocking the vases off the coffee table.  As the transportation cost goes up and your teenager starts driving, we invest in class because the cost of failing is now too high to have failure.

    So an example in IT, as Basis person, I might want to add new feature to analyze performance of system.  My design team is me.  My test team is me.  My implementation team is me.  The business team is me.  If it fails, I’m the one who is disappointed.

    Now let’s say it fails a few times and then succeeds wildly.  I now post it.  It gets shared all around the world.  Cool.  I’m famous.  I get interviewed for some Geek Publication and everyone ask how I did it. I say I did it through “failing fast”.  I did. 

    As a consultant, we are generally brought in to lower the risk of failing.  Often to go into areas clients don’t know or are afraid to ask about.  We also take a lot of the client’s money in a blatant way via a contract.  Results really are not optional.  Failing to meet the goal is just not optional.  We are involved because the risk is too high or the need to get there without a learning curve is worthy of the fees.

    Failing fast is really about taking bigger risk or lots little ones in less tried path.  I’d suggest you try your method, but you perform the increments away from someone who has linear set of goals like the business team paying you.

    I know as the Basis guy, long before SCN had all sorts of great advice, we used play around a lot with memory and cache values.  About 90% of the time, it just didn’t do anything or made it worse.  Every so often, you’d get a winner.  We’d share it amongst ourselves.  Who knew I was “fail fast” pioneer in 1996 on SAP.

    Do keep trying and failing.  We generally learn more from our failures than our successes, but you knew that.

    – Chuck


Leave a Reply