developers community

The first step in outsourcing a project is to make sure you have a clear idea of what you want. This holds true whether your project is a simple or complex one. Before requesting bids on SYPAD, take a few minutes to write down your project requirements at a high level. This means a few sentences describing your project. Here’s a simple example.

Title: Update the look and feel of my blog

Overview: I have an existing blog in blogger and want to update its look and feel. You will need to create a new design for my blog and then implement it. I would also like my blog to support an email subscribe box from Feedburner, a list of recent users from MyBlogLog, and a tag cloud. I also want a list of my 10 most recent entries, and links to archives of my blogs. When bidding, please provide a few examples of other blogs you have worked on.

Create a Project and Request Bids

             The next step in the process is to create the project and request bids. Potential sellers (coders) will receive the project description and can choose whether to bid. Developers who receive a large number of bid requests can easily read this description and quickly figure out whether they want to submit a bid or not. A longer overview might provide more detail, but it would also be overwhelming for potential sellers.

Review Bids and Select a Seller

Once you receive bids on a project, you can evaluate the bids based on past ratings of sellers as well as specific responses to your project overview. Looking back at the sample project description, it makes a simple request of potential sellers: “please provide a few examples of other blogs you have worked on.”

When reviewing bids you have received, you can first filter by sellers who responded to this request (as opposed to those who didn’t), and then more specifically by the examples provided. You’re likely to have better communication during your project with a seller who took the small amount of time required to provide some examples of previous work than one who didn’t.

             It’s often beneficial for both you and potential sellers to have a short dialog before you choose a seller. For example, you might provide some additional detail about the project and ask the seller to respond with any questions or comments. This serves a dual purpose of getting you in the mode of communicating frequently with your potential sellers (which is critical to project success), and further filtering potential sellers by those who continue to be responsive. Going back and forth too much is unfair to potential sellers, but going back-and-forth once or twice is a good idea for both parties.

Communicate During the Project

Both sellers and buyers benefit from frequent and clear communication. It can be incredibly frustrating to a hard-working developer not to hear back from a buyer when a critical question needs to be answered or a deliverable is ready for testing. It’s better to over-communicate than to under-communicate, especially when you are first “getting to know” each other. Good communication saves time on the part of the buyer and the seller.

Once you receive a deliverable, it’s important to test it and provide feedback quickly. Following this simple rule means makes it a lot more likely you’ll get exactly what you want. When providing feedback on a deliverable, be specific. When reporting bugs, it often helps to number them so that you and the developer can communicate easily about a particular issue.

For example: Bug #2: The hyperlinks in the output on the page output.php should be absolute links that, when clicked, appear in a new browser window. (To see the issue, go to page output.php and click on a link. You will see the links are relative, causing the target of the links not to appear. Also, they don’t appear in a new browser window.)

The above example is effective because it makes clear not only what’s wrong, but also what the desired behavior is. It’s specific about how to reproduce the issue (“go to page output.php and click on a link”) and how the problem should be corrected. By taking the time to provide this level of detail, you’ll save both you and the developer time in the long-run, because you’ll get the fix you want.

Project Completion and Additional Features

Over the course of the project, you’ll likely think of new features that you want in your product or web site. It’s important to handle these features properly so that you get the deliverable you want. Introducing major features in the middle of a project is like switching to a new recipe for a dinner party, while the old recipe is already under way. It can be done, but there are tradeoffs and costs.

Just like you have to buy the ingredients to cook a special dinner, a developer lays the foundation for a project based on the requirements you initially specify. It all comes back to defining clearly what you want. There are two things to think about when defining new features.

First, when you initially specify a project, you should make clear to the developer whether the project is something that you expect just to build and use as is, or something you think might have some major enhancements in the future. If you suspect you’re going to add a lot of features in the future, it can be helpful to tell the developer this up front so the developer can architect the design of the site or product accordingly. While this may cost a little more initially in terms of time and money, it’s often well worth it because the developer doesn’t have to re-architect the product on the next version. However, if you just need a quick script or utility written, it probably doesn’t make sense to invest a lot of time, effort, and money into an extensible design.

Second, the best way to handle new features is to create a follow on or bonus project in which you specify and request the new features. This way the developer can deliver what was originally specified and you can get a working version. Seeing a working version of your product or web site will often lead you to a lot of new ideas that you wouldn’t have considered in the absence of an actual implementation. Keep a list of your new ideas, and be sure to prioritize them. Software is an iterative process, and the best way to get what you want is to specify a few more features, get another deliverable, and so on. If you specify too many changes or features, the time tradeoff may not be worth it. The key is to find a balance between features and time.

Conclusion

Outsourcing software or web site development is a lot like managing any other project. Whether you’re cooking dinner, remodeling a house, or building software, a succinct definition of what you want, followed by clear communication makes for a great result.

As a great developer once said, “ship early, ship often.” The sooner you get something out there, the sooner you can get real customer feedback, which is often as valuable, if not more valuable than any features on your feature list. Your users can take you in unexpected yet often very helpful directions. So get started with your outsourced project today.