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.
