How to get good off-shore developers - Part 2
June 19th, 2008Off-shoing your web-development is a great way to save money and, if you are bootstrapping a small start-up, it could be the perfect strategy to hang on to more equity and delay financing. However off-shoring your development is also fraught with risks, it is far harder to manage your development and communicate ideas, so it is vital to take proper steps to protect yourself. In this post I continue describing the system I’ve used several times in order to ensure that I get developers who are motivated, technically capable and trust-worthy.
You’ll find stages 1 and 2 discussed here.
Step 3 - Send the developers you’ve found a “Request for Information”
A Request for Information (or RFI) is a questionnaire to help you short-list developers. The objective of the RFI is to enable you to decide which developers can deliver your project in the right sort of price range. Your RFI should at least gather the following information:
- Hourly rates for different staff types
- Which currencies the developer can raise invoices in
- Whether they are prepared to set a fixed cost for the project (you want a fixed cost, right?)
- Between 3 and 5 customer references
- Information about the company (how long has it been running, how many people it employs)
- Information on their typical project (how big it is, how long it lasts)
- The development methodology employed and development technologies supported
- Whether they have a design house
- Their preferred development technology
- Any technology certifications which they may have
- A “difficult technical problem” which is related to your project, ask the developers to sketch out how they would solve it
I’ve included an example RFI in the documentation bank to help get you started.
When asking for references, try and get projects which are similar to yours. Also get a reference for a company which is physically near you and then arrange to meet up with them for a coffee and a chat.
Your RFI should also tell the developers all the key deadlines for the selection process. It ensures that the developer knows where they stand at all times, and it gives you targets and deadlines to meet yourself. When you issue it give the vendors at least 2 weeks to respond and an opportunity to ask you questions.
If you are worried about controlling your IP, then there’s no need to discuss what your actual business is in the RFI. However, you might want to describe in broad terms the type of business you are launching, or refer to some similar companies.
When you send the RFI out, update the vendor dashboard which you set up at the start of the process.
Note that not every company will respond to your RFI. Some companies will respond but fail to answer the final question, some companies will send you back documentation packs which probably contain the answers, but they’ve not bothered to put them into your format. All these companies should be immediately dropped from the list.
Step 4 - Short-list the developers
Two weeks after you’ve issued your RFI you should have all the responses you are going to get. I tend not to bother chasing any companies who don’t reply to the RFI and just stick with those that do. Your next step is to short-list the developers, you want to work through the responses until you have 4-7 companies to take through to the next stage.
Before you start short-listing the developers, you need to think about what your ideal company is. You might want to work with a small company, or you might be looking for a larger company with ISO or CMM certification, you may have a particular development methodology in mind, or you might want your system built with a particular technology, etc. Collate all these thoughts to help piece together what you are looking for.
You are then ready to start “the sift”. First stage is to remove any companies which just aren’t right. Personally when reading through these responses I arrange them into three piles: yes, no, and questions. I then ask the questions and update. I continue to do this until I have only a yes pile and a no pile.
Remember to always check the references, this is one of the best signals of quality company. If they are in your country, arrange to go and see them, otherwise drop them an email. You want to know whether the developer delivered on time and to budget, if they still use them, if they’ve given them any new work and if they’d recommend them.
Keep working the list until you get between 4-7 companies. It is important that you don’t take too many vendors through to the short-list round as you don’t want large numbers of companies knowing what you want building. If you don’t have enough, approach more companies. Finally, ensure that you feedback to all the companies involved (good news and bad) and update the vendor dashboard to so can keep track of where each company is.
In the next post we’ll look at how to get a price for the development and how to select which companies is going to build your business.
Email This Post
Posted in Aroxo, business, development, entrepreneur, entrepreneurship, how to start, off-shoring, out-sourcing, start-up | Top Of Page |
Leave a Comment »
Personal: Welcome to the world Hallam Rogers
June 16th, 2008I’m delighted to announce that on Monday May the 12th I became a father for the first time.
Hallam Rogers was born in Kingston General Hospital at 2144. Both mother and baby are doing well.
As you can see, he’s already an Aroxo fan!
M.
How search engine spam created Web 2.0 and drove the social revolution
February 19th, 2008A friend of mine mentioned something to me recently. He commented that a site he works with recently changed the text on their registration button from “Register here” to “Register for free” and, as a result, registrations shot up.
That really blew me away.
Clearly pretty small decisions can have an enormous and disproportionate impact.
This got me thinking and something else occurred to me, namely how a similarly small decision caused by search engine spam created the Web 2.0 phenomenon.
Back in January 1996, Page and Brin were busy building a new search engine. One that we now know as Google. Their starting point for this adventure was fixing the problem with the other search engines: that their search results were not very accurate.
There were two problems, firstly the search engines were happy to take payment from companies who wanted to appear in their search results and secondly the order of the search results was both arbitrary and easy for spammers to fool.
Companies which wanted to appear in the search results would just stock up their pages with the search terms they were interested in and, voila, in came the traffic. The problem was that the people using the search engine didn’t find what they were looking for. The existing search engines basically weren’t working.
This is where Google came in, they calculated the search engine positions by looking at how many other sites linked to the page, the text which the user clicked on, and how popular the referring page was. They built Google like this because (at the time) this had not been spammed.
This technique worked, web users were suddenly able to access the pages they were looking for and Google became massively popular. What also then happened is fascinating.
This decision encouraged genuine content producers to generate inbound links in order to get access to Google’s traffic. It drove more and more linking on the web, and instead of people getting annoyed about losing control of their content, they loved it. It drove greater sharing,
communication, and integration - the bedrock of Web 2.0.
This, small architectural decision has had a massive impact on the web, both its utility and its social impact.
I wonder whether Page and Brin considered this when designing Google?
How to test your system with real users
February 14th, 2008Aroxo recently turned a major corner in its development, we moved from closed functional testing to using real live alpha testers, people who’d never seen Aroxo before.
Without doubt, this is one of the most revealing, painful, and valuable stages in creating your start-up, so I thought I’d blog about it.
When launching anything you want ensure that not only does it work, but people find it easy and natural to use. Your own functional testing should cover the first objective, your alpha testing should cover the UI.
At Aroxo we’ve employed four different techniques to get the system ready for launch:
|
Test type |
Description |
How many people |
| Over-the-shoulder | The main sticking points in the system. Where the system confuses users. Start when functional testing at 80% readiness. Earlier with mock-ups also possible. |
10-15 |
| Task-driven testing | How well the system stands up on its own. Start when the major usability holes uncovered in OTS testing have been fixed. |
Start with 20-30 keep growing invites to 100 or so |
| Goal-driven testing | End-to-end flaws across the system. Start when functional testing at 95% system readiness with a slick UI. |
150-200 |
| Beta testing | The marketing points for the site, highlights future developments. If there are enough users it may also reveal performance issues Start when the system is 99% ready. |
250+ including members of the public |
Not only is each stage different but you get different learnings from it. I discuss each stage below.
Email This Post
Posted in Aroxo, development, entrepreneur, entrepreneurship, how to start, start-up, testing, web 2.0 | Top Of Page |
4 Comments »
How to get good off-shore developers - Part 1
December 14th, 2007A really effective way of boot-strapping your start-up is to off-shore and out-source your development. But doing this also carries risks, how can you be sure that you are going to get a developer who’ll see it through and has the right experience? This post lays out an effective process to find the right developer.
From starting the search, to the first developer writing code should take around 3-5 months and there may be further delays whilst you complete your documentation. In this article I’ll talk you through what you should be doing at each stage, and what the objective of each stage should be. Here’s an overview of the process:
- Build a long list of development companies
- NDA all the companies on the long-list
- Issue a Request for Information (RFI)
- Analyse responses and short-list the developers
- Issue a Request for Quotation (RFQ)
- Analyse responses and select a preferred vendor and a spare
- Negotiate contract with preferred vendor
- Commence development based on your documentation
This is a long process, and therefore I’ve split it up into 4 sections, these will be posted each week for the next four weeks. Any regular readers can relax – the whole lot has been written in advance, so there won’t be any 1 month gaps in between!
Finding a great development company is one of the most important decisions your company will make. Changing developers mid-way through a development is near impossible and so it is important that you select a company which you are confident has the ability to see it through. The purpose of this 8-step process is to stack the odds in your favour by finding out as much as possible about the development company before you sign the contract.
At several stages I’ve included sample documentation to give you more guidance on what should be included. You can download these examples from the documentation bank on Aroxo.
Before we start, one word of advice. Running a vendor selection process will involve giving a large number of developers bad news (and only one company good news). When I first started doing this I found the process of giving bad news quite unpleasant. It is, but it is still important to do it. Vendors are used to receiving rejections, so they tend to take it more easily than expected and I also find that giving the bad news, along with some personalised feedback is always much appreciated.
Step 1 – Build a long-list
Before we start populating a long-list, it is worth spending a few minutes getting properly organised as running a vendor selection process involves a lot of time, organisation and communication. I find it easiest to run these off a spreadsheet which we’ll develop going forwards. There’s a sample vendor dashboard included in the documentation bank.
Building a long list involves populating this dashboard. The aim is to get 20-30 companies into the dashboard that satisfy your broad requirements for the type of system you want to build. You want to make sure that each company has:
- Experience in building the type of system you’re looking for (if you think your system is entirely new, it almost certainly isn’t, there will be parallels which you can look for, even if those are purely functional elements)
- Experience working with start-ups
- Offices somewhere in the world you are happy doing business
- Experience in the technology you want your system built in (if you don’t have a preference, then ignore this)
By far and away, the hardest of these objectives to meet is the first. You may need to contact many companies to determine whether they have built a similar application to the one you’re looking for.
In order to find companies, there are a few tricks you can employ:
- Use your network – ask anyone you know who works in the software industry for 2-3 development company recommendations
- Use referral companies to provide connections and act as a filter
- Use associations to help pinpoint development companies
- Use tools like eLance, Scriptlance and Rentacoder to find developers
- Use Google to help find companies
- When you’ve found a company you like, do a reverse search for their homepage on Google to see if they belong to any associations with links to other companies
You may need to look through a large number before you’ve found 20-30 companies which can meet the 4 requirements set out above.
Step 2 – NDA everyone
You’re a start-up (I’ll return to this point later), so an NDA offers no protection. If you’ve got funds to sue a company then, frankly, they would be better spent fixing the mistake with a new developer. However, it is still essential that you NDA all the vendors, even though you are not going to be providing them with any confidential information (other than of your existence, just yet).
First thing you’ll need is an actual NDA. There are plenty you can download for free on the web, so I’ve not provided one. Read it to make sure that you are comfortable with everything included in it. If you’ve selected a lawyer at this stage, ask them to provide an NDA, but don’t pay them to write out a new one.
Email it to all the developers on your long-list and ask them to fax or scan signed copies back, make sure there’s a deadline for return in your email. When you receive one back, open up the Vendor Dashboard and update it so that you don’t forget you’ve received it. Then print it out and file it.
When you hit the deadline, ignore any further submissions, if the development company can’t meet this simple deadline they are not going to meet any further deadlines.
In the post coming next week I’ll detail how to write and issue and RFI and then short-list your developers.
Email This Post
Posted in Aroxo, business, development, entrepreneur, entrepreneurship, how to start, off-shoring, out-sourcing, start-up | Top Of Page |
2 Comments »
