Search This Blog

Thursday, May 8, 2008

Rapid Prototyping

If you are in this emerging 'applications' market, and are in the business of building applications for OEMs/ISVs or Service Providers (yes, some Operators actively invest in R&D work), the term 'Rapid Prototype' is not new to you. In short, people are always looking at 'quick and dirty' demonstration code that shows off a cool concept which they can take to prospective customers as a viable product or service to be rolled out. Customers who ask for this are not sure if that idea will go anywhere, but are willing to test the waters with you (if you are willing). A typical software development organization follows the 'Build Rome one stone at a time' model whereas this particular market needs the 'pre-fab modular home in 1 month' model and therefore struggles with this particular market. I know of many organizations who  believe this is not an area to be in, because of the limited scope and length of such projects. The problem however, is that they fail to understand that this market is actually very attractive and profitable, but only if you look at it the right way, and approach it the right way. Last week, I was chatting up with a friend on the same issue and was sharing some insights into what one should try and institute to make this model work. He suggested a blog post, so here goes - some common problems, pitfalls and solutions:



  • Identify some of your best  guys who are out of the box thinkers and put them into prototype development. If you are working with inexperience people, because you think this project does not warrant any more focus, you have already made sure the prototype will fail before it starts. I cannot re-enforce how important this is.

  • Process is important, but you need the 'feather-weight category' not the 'heavy-weights'. I can't tell you how many companies I know, who completely throw process to the dogs and just hack code to get things working. The problem is that if you have no documentation, no clue what you tested, no clue if what you built meets your customer's requirements, or whether it will work on his network, you are all set for a grand bust. (If your answer to all of the above is 'Yes', then you are actually following a process - you just don't know it) - which brings me to the 'feather weight' part. Make sure what you do is trackable and documented. Very often a prototype needs to be modded and the original folks may no longer be available. Look into methodologies like extreme programming and elements of Agile, leading to the next point:

  • Don't spend your time ditching your existing process for an unknown one (example, from CMMi to Agile). You'd be surprised how many elements of Agile can actually be borrowed into CMMi to fit your needs. So adapt, don't replace.

  • Don't ignore scripting - too many people dive straight into C or C++ and Java to build applications. Look around to see if there are any high level scripting interpreters available for that platform. For example, if you are building a new idea on Symbian, take a look at mobile-python (In fact, we just concluded a really cool social networking prototype on Mobile Python for Symbian - we noticed drastic reduction of time with that).

  • In 'quick throwaway prototype' the word 'throwaway' is a myth. If you build a throwaway prototype, your chances of a prolonged customer engagement disappears. I can guarantee, if the prototype is done well, the customer will come back asking for changes, or his customer will come back asking for changes. And at that stage if you tell him 'Oh ok - we need to restimate from scratch, as we built a throwaway code', he is going to shop for other options which may not include you

  • Get involved  - The most frustrating thing with any developer is to see his 'baby' ignored. If some smart guys build a prototype on their own initiative, get involved early to guide it from a market perspective - 'Why are you building it ?', 'Where do you want to take it', 'Why don't you do it this way, because I really don't think in its current form it has potential due to blah reasons' etc. As companies get bigger, individual contributions which are not necessarily the core company focus often get overlooked and that kills the spirit of prototyping. In our company, we have set up lots of initiatives just for this one cause - keep people involved and interact, get engineering and market folks together frequently and often. Send me a personal email if you want to discuss more on this point.

  • Re-discover the process of estimation. An overbloated estimate will never get you a win in this market of prototyping. An under-specified estimated will result in you delivering bad code, or, you will not be able to realize the actual invoicing.

  • Don't balk at the small deals. Volume is key here. Don't keep waiting for that large prototyping order. There are only a few companies in the world who can fund a high six-figure prototype. But there are likely 200 companies who can fund much smaller ones. Build on volumes.

  • Build and re-use. It is always a good goal to set aside a metric that in each prototype, you will build at least 40% of the code in a way that it can be used by other future prototypes. Sometimes you will create more or less of reusable code. Personally, I don't think more than 40% is practical for prototypes because you are against tight deadlines, and you just don't have the time to generalize any more, but your mileage may vary.

  • Help your customers win- don't just sit pretty with what they tell you. Feel free to suggest other options, ask them how else you can help them succeed. For example, if the customer is demoing a prototype to their customer, is it easier for a 3rd party sales guy to fumble through the demo or is it better for the creator of the prototype to give a passionate demo in front of the customer ? Passion is a large part of winning deals. Hey, remember this post ?

No comments:

Post a Comment