A friend of mine recently sent me an RFP. He is considering launching a company where he needed some engineering help. He is very smart lawyer with business background. Reading the RFP it looks like he got help from someone who works in Engineering at a Fortune 1000 software company. the following is an excerpt from the advice I gave him. It was a very comprehensive RFP. However, what I saw in the RFP are common mistakes people do while engineering early stage products.
My recommendation to him (in no particular order)
1. Use lots of open source. He was thinking Drupal, Joomla. My recommendation additionally consider LAMP, Ruby, (even IBM has an opensource version ) etc. Make it a requirement. Use the Amazon cloud to host. It is an awesome service for startups. There is no upfront cost to you.
2. pick an architecture that works for now, ie, don’t over-engineer. If you are successful, you can always rebuild. If you try to over-architect version 1.0, you will incur a larger cost to build V1. When you company is successful, hire someone really smart. Think Twitter.
3. The team (or Vendor should be experts in Agile software development. Where they do a lot of incremental development. Give you working code that you can provide feedback on a 15 days cycle. I think this is very important.
4. Have someone from your team interface with the vendor on a regular (daily or 3 times a week) basis. Single point of contact from the vendor. Typically in off-shoring company this is the key guy. You don’t need to go thru all the resumes, that is there job. You should be looking at your key point of contact. Ideally he should be either a product manager or a project manager. Someone who understand business (first) and technology (second).
5. If you off-shore, be prepared for late hours.
6. You might want to break-up the activity in to two RFP into two phases. A first phase where you get mock-ups (wireframes) of the product that you are looking for. For the creation of the wireframes, either someone from your team or from the vendor should have a crisp answer to the queries that the engineer will have. And a second phase where they engineer the wireframes. If you are looking for accurate (no surprises), then do the wireframes with your internal team. This is something we did very successfully at GlobalLogic (http://xsachin.blogspot.com/2008/05/sample-design-phase-output.html)
7. You have three models to engage
· fixed cost - vendors will make all kinds of assumptions. They will make you lock the scope and all changes will cost you. Ideally for where you are this is not a good idea.
· go FTE (lawyer pricing). You take control on who is working on what
· define your budget and let the vendor tell you iteratively (ongoing) what they can do. This way there is no sand-bagging and you get to decide what you want, just when folks are ready to code.
8. I would encourage you to think of what use cases are a must have and what are good to have. in any development you have time, money and scope. My experience with early stage products, keep scope flexible. Fix the other two.
9. Have a very firm go-live date. Almost like Y2K. None of the Y2K projects were delayed. Plan a big marketing hoopla or something so that there is pressure to get the product out by that date. Pressure then helps control cost, take quick decisions and control scope.
10. If you are working with off-shore team, make sure they have web systems that they and you can track the development. This will give you the visibility of what is going on in development organization. emailing Excels and Word documents just does not work.
Popularity: 26% [?]
Leave a Reply