Important alert: May 9, 2012 11:29:40 AM EDT.

My apologies for the inconvenience: the system for processing emailed responses was not processing all of them correctly (and it was only reported to us recently, so we didn't realize it). This has been fixed, but may result in older messages (from the last two weeks) showing up on May 8 and May 9 in your message thread. We have also taken steps to monitor this system more closely so we will know immediately in the future if there is a problem. Again, my apologies and thanks for your understanding. Ian Ippolito CEO and Founder of vWorker
Attention employers: One Million by One Million is looking to interview employers who have used vWorker to help build their business and have earned at least $1 million in revenue over the past 12 months. Your company must be independently held and you must be willing to openly discuss revenue numbers. If you are interested in being interviewed, please contact us for more information.

The vWorker Best Practices Sourcing Model

Since we started doing business in 2001, we've watched hundreds of thousands of outsourcing (and more recently crowdsourcing and trialsourcing) projects finish successfully. Unfortunately, we've also seen tens of thousands that didn't. Too many of these happened because the employer didn't understand how to source properly or use the site features and protections available to them. These easily avoidable mistakes unnecessarily cost employers countless sums of money and man-centuries of wasted time and effort.

So we created the "Best Practices Sourcing Model" to educate employers on how to avoid these problems in the first place. The practices also discuss "black-belt" techniques that take project success rates to the next level.

(If you want to take advantage of these without bothering to learn all the details, then consider hiring a Sherpa. Sherpas are pre-screened experts who are knowledgeable in all of these advanced methodologies, and will allow you to use any or all of them without lifting a finger.)

General

1) How can the Best Practices Sourcing Model help me?

Interviewing and hiring:

2) How do I best pick the location of my worker?

3) How do I select the best performing worker? (the "Trial By Fire" method)

Payment models:

4) Which payment model has the highest project success rate?

5) Why do standard pay-for-deliverables projects tend to fail on larger projects?

6) What are better alternatives to a standard vanilla pay-for-deliverables project?

7) How can I save the most on the vWorker.com fee (and also reduce overall project costs)?

8) Why should I switch from pay-for-deliverables to pay-for-time when I rehire a worker?

Work management:

9) The worker I hired keeps missing deadlines. What can I do to stop this?

Entrepreneurs:

10) Self Defense 101: 5 Things Every Entrepreneur Must Do, to Avoid Getting Burned by a Rogue Techie

11) What's the difference between a Technical Co-founder and a Tech Sherpa?

Software Specific Advice:

12) What is spiral development and how can it help me with my project?

13) What payment methods work best with spiral/agile development?

14) The final deadline arrived and my project is nothing like what I asked for! What could I have done differently?

15) What is technical debt and why do I need to manage it?

1) How can the Best Practices Sourcing Model help me?
	These practices were created for employers and will help you in the following areas: Safety: Maximize the protection of your funds. Quality and productivity: Improve project quality, speed project delivery and increase worker productivity. Risk management: Minimize the risk of your project failing. Costs: Cut the vWorker.com fee substantially, and the long-term costs of getting your project completed. Recruitment: Establish long-term, mutually-beneficial relationships with the best workers and reduce the costs of worker turnover. ...and many more. If you have a best-practice that is not listed here, please tell us about it!
	Back to top

2) How do I best pick the location of my worker?
	It's important to understand how location affects the speed, qualify and cost of your project so you can choose the best location for your needs. (Note: the names of the categories below assume you are an employer from the United States. However, the concepts are similar for employers in all countries.) On-shore: (United States) Pros: Time synchronization: You share the same time-zone, so they are working when you are working. Communication: You share a common culture which makes communication of abstract concepts easier, quicker and more accurate. You are both native English speakers which minimizes the chance of delays due to language miscommunication. Legal: Strong intellectual property laws and non-disclosure agreement protection mean that the worker cannot disclose your secrets without catastrophic consequences. Cons: Most expensive: $45 - $85 / hour When to use it: Ideal for your core business, your "secret sauce" and anything involving intellectual property that you need to keep secret. Also ideal for complex or time sensitive projects where communication is critical. Near-shore (Canada, Ireland, Philippines, South America, etc.) Pros and cons: Similar to on-shore, but with some additional cost savings. Prices are typically $25 - $35 / hour Off-shore (Romania, India, Bulgaria, Pakistan) Pros: Cost: Lowest and cheapest option. Typically $10 - $25 / hour Cons: Legal: No enforceable intellectual property and non-disclosure agreement laws. As such a worker can resell or redistribute the work they do for you to others, and not suffer any legal consequences. However, this can sometimes be minimized by breaking larger projects up into smaller parts, so that no worker has the entire solution. (If you want to do this but are unsure, a Sherpa can do this for you for an hourly fee). Different time zone: Much more difficult to coordinate with them because they are asleep when you are awake, and vice versa. However, many off-shore providers will work U.S. hours if requested. Also, some employers actually use this difference to their advantage by pairing an off-shore team with an on-shore/near-shore team, to do "round the clock development". This allows progress to be made at twice the speed. Communication / English: Broken English and a different culture can cause project delays due to miscommunication. However, you can minimize this by vetting their English in advance and only using workers with English skills that will work for you. On vWorker.com, you can view the location of every worker on their profile, so you can make the best choice for your situation. When you post a project, you can also choose to limit bidding to workers in countries with certain economy types (emerging, mature or both).
	Back to top

3) How do I select the best performing worker? (the "Trial By Fire" method)
	Important update: This article was written in early 2011 before newer on-the-job trial techniques (crowdsourcing and trialsourcing) were created. These newer methods have several advantages over "Trial by Fire": You only pay the ultimate winner. You don't have to pay for participants who complete the project but are not your final selection. They do not require you to spend the time and effort to go into arbitration to get a refund on all candidates who fail (or use up precious self-mediations to avoid the hassle). They optionally allow you to harness the power of the crowd and let participants build on what other participants are doing. They are less complicated and simpler for youto manage, because all candidates are on a single project (rather than scattered across multiple projects). For these reason, we recommend the newer methods for most situations. However, "trial by fire" can still ocassionally be useful. It is a more effective motivational tool, because each participant knows that they will get paid if they finish (versus only the winner being paid in the newer methods). So this article is being kept here for those who still wish to use this technique. The number one determinant of your project’s success or failure occurs long before your worker even logs their first hour on your project. Choosing the best worker is the most important step you can take to make sure your project is successful. Why is this so important? The worst workers are 1/10th as productive as the best. So choosing a “bum worker” can be ridiculously costly. So how do you make sure you choose the best? If you’re hiring a worker in a field you’re an expert in (say you’re an expert programmer and are hiring another programmer), then it’s often pretty easy. You know what to look for and how to spot the best ones by simply talking to the best candidates. But sometimes even that isn't enough. And if you are hiring someone outside of your range of expertise (say you're a writer hiring a translator, or a marketer hiring a designer), then you probably have no clue about where to begin. So what do you do then? Looking at profiles and resumes can help. But both of these can be faked, too. When the stakes are so high, they are not certain enough to rely on. Past ratings by employers are also helpful. But often a worker hasn't done something exactly like your project before, or doesn't have a long enough history on the site. Requiring the worker to place an Expert Guarantee (forfeitable deposit) does help quite a bit, and weeds out the majority of the bad apples. But it still doesn’t weed out those bozos that have money to burn. So what’s the ultimate answer? The best way to choose the best worker is by watching how they work on your project. But how can you possibly figure this out, before they’ve even started? There’s a simple way to do this. We call this technique “Trial by Fire”. Basically you “interview” several candidates by giving them a small piece of your project and watching who meets the deadline and does the best work! It’s so simple: there’s no better way to predict performance than by watching the person when on the actual job itself. Yes, by “racing” workers like this, you may have to pay more than one (if they all finish by the deadline). But the small up-front investment will pay dividends in the long term, by saving you from wasting time and effort from choosing the wrong worker. And by keeping the “interview” piece small, you minimize your costs. And you can further minimize costs by using all the tools mentioned earlier (profiles, portfolios, ratings, Expert Guarantees) to weed out the majority of your candidates and keep your trial candidates to a minimum size. Finally, once you’ve found your uber-worker, you can save even more money with another best practice: switching them to pay-for-time.
	Back to top

4) Which payment model has the highest project success rate?
	Pay-for-time projects have the highest project success rate. They fail very rarely: only 1-5% of the time... ...while Pay-for-deliverables projects fail 11-27% of the time (which is 500% to 10,000% more often)... As the project size gets bigger, the numbers can become dramatic. A $200 pay-for-time project has a 3% chance of failing. But if you do the same project using pay-for-deliverables, your chance of failure sky-rockets to 23%. That's more than seven times (700%) riskier! Why is this? The main reason is that pay-for-deliverables requires you and the worker to do two things which are either difficult or impossible to do on larger projects: You must document your entire project 100% accurately (and completely) in advance. The worker must then accurately estimate the size of your project in advance (to bid on it). When the first is not done properly, you get an end product that does not meet your business needs (and/or end up with conflicts with your worker over scope). When the second is not done properly, you get a worker that it not motivated to try their hardest, which causes quality and abandonment issues. Both of these together cause the increased project failures. (Click here to read the full details on the above problems.) To avoid these issues and reduce your project failure rate, we recommend using pay-for-time (or one of the other alternatives to standard pay-for-deliverables) whenever possible. And we specifically recommend against using standard pay-for-deliverables when your project is a larger pay-for-deliverables project (one that is more than $200.00 in emerging economies and more than $700.00 in mature ones).
	Back to top

5) Why do standard pay-for-deliverables projects tend to fail on larger projects?
	Larger projects are more difficult for a worker to do than smaller project. So we would expect them to fail more often than smaller projects. However, larger pay-for-deliverables projects fail 500-700% more often than the same sized pay-for-time projects. So obviously there's something more at work here. What causes the difference? Pay-for-deliverables projects have two requirements which are difficult or impossible to do on to do on larger projects. They are: You must accurately document 100% of the details of your project in advance. If you don't, then you will end up with an end product that does not meet your business needs (and/or end up with conflicts with your worker over scope). This sounds easy/reasonable in theory, but in practice it only works on very small projects. On anything larger, you'll find that: You will simply forget to include some requirements. (No human being can design complex projects 100% perfectly in advance). Others you will remember to include, but will be misunderstood by the worker due to miscommunication and will end up wrong. Others will be perfectly communicated and perfectly implemented by the worker. But when you see them live in the product, you'll realize they don't meet your business need (and/or should be done differently). Again, no human can visualize complex projects 100% perfectly in advance. Others will be perfectly communicated, implemented and still be correct...at the time you created the requirements. But due to business needs changing during the time of the development (which can weeks, months or longer), the needs changed and they are now wrong. (Here's a real-life example.) When the requirements are incomplete or incorrect, you end up paying for a project that "meets the requirements" but doesn't do what you actually wanted or needed it to. The worker must accurately estimate the size of your project in advance (to bid on it). Let's pretend for a minute that you can create perfect requirments. Even if you managed to do that, studies have shown that the best workers under-estimate the amount of time a project will take by a factor of two to five times (and others much more). And the larger the project, the worse the under-estimate tends to be. When they do this, they under-bid, which causes quality and motivation problems for you later. You may be thinking "That actually sounds great to me because it saves me money!". But, actually, a bid that severely under-market costs you more in the long-run. Imagine you are a worker who won a project and began work. Then, reality begins to sink in as you realize you under-bid by a factor between two and five. Soon you're calculating what that means. You've just taken a 50-80% pay-cut, and found yourself obligated to work for a period that's two to five times longer than you expected! How would you perform? You would probably not be delivering your best work. You might start taking questionable shortcuts to get thing done quickly, but that would cause long-term problems for your employer later (see technical debt). You might become very difficult to deal with. And you might even throw up your hands and completely quit. This is what tends to happen on larger pay-for-deliverables projects. You might still be thinking "So what? It's their own fault for bidding too low. I don't care because I still get my money back with the triple-point money-back guarantee". Yes, it's true you will get your money back. However, you'll have wasted all the time spent qualifying workers and interviewing, and will be stuck with the hassle of starting all over again. And even after your repost, re-qualify workers, and redo the work process, you still have the exact same 25% chance of ending up in the same place again! Obviously there are better uses for your valuable time and efforts. So how do you solve this problem and still get your project done safely and as economically as possible? Click here to learn the three ways to get around this.
	Back to top

6) What are better alternatives to a standard vanilla pay-for-deliverables project?
	Pay-for-deliverables projects give you the maximum protection on small projects. However, on larger projects, they have a 500% to 10,000% higher failure rate than pay-for-time (due to the difficulty of creating and estimating the requirements up front). And on repeat work, the protection is overkill, so you pay 40% more than you have to, for something you don't need. So what are your alternatives? Switching to pay-for-time is the easiest solution for most people, because it solves both the project failure issue and gives you a 40% savings on the fee. When you pair pay-for-time with the spiral model, you also maximize your protection, cut your costs and best ensure the final project is what you truly want. And if you're doing repeat business with a worker you've hired before, pay-for-time is also the no-brainer choice. But what if you're new to the site (and/or managing with pay-for-time) and hiring a brand new worker? You may not yet feel comfortable without some sort of guarantee on deliverables. So what do you do then? Or what if you simply don't want to (or can't) supervise the worker--as pay-for-time requires-- and don't want to hire a Sherpa to help? There are three pay-for-deliverables variants that are solutions to this problem: Raise the Worker's Bid: This is the simplest but also the most expensive of the three variants. It also doesn't address the issue of incomplete requirements. Click here to learn more. With this variant, you get the worker's pay-for-deliverables bid for doing the work. Then you tell them that to make sure they are fully motivated and protected from the risk of under-estimation, you want them to raise their price by a multiplier. This has the advantages of being very simple and giving you the full protection of pay-for-deliverables. The disadvantage comes from the fact that neither you nor the worker know in advance exactly how much they under-estimated by. If you multiply their intial bid by just two, you may still not have raised it high enough (i.e. they may have under-estimated by five). Then you are stuck in the same situation as not doing anything. And if you raise it by five, and they only under-estimated by two, you've drastically overpaid. Paying five times the price of every bid is not something that every employer wants to do. Also, it does nothing to address the other issue: the fact that you can't reliably specify all the requirements in advance. So, if you would prefer a cheaper and more comprehensive variant, you should use the Hybrid Payment Variant, or Hybrid Payment Variant + Sherpa instead. Hybrid Payment Variant: This is the cheapest variant. It does require you to do additional supervision of your worker. Click here to learn more. This variant is significantly cheaper than "Raise the Worker's Bid" because you only pay for the time the work actually takes. Additionally, it gives you the full protection of pay-for-deliverables when you need it; at the very beginning of the project. Then it switches you to pay-for-time at the appropriate moment, so you can safely enjoy a significantly higher project completion rate and a 40% savings on the fee. You do it like this: Small trial project: Split off a small portion of your project into a trial project (using pay-for-deliverables). This lets you find the best worker for your project, and fully protect your money at the same time. Make sure to size the trial project appropriately (less than $200.00 in emerging economies and less than $700.00 in mature ones). That way it will have the best chance of being completed successfully. Most people don't know how to do this themselves. So if that describes you, simply require the bidding workers to do that for you. Click here to view the text we recommend you add to your project, to do this. This project is a larger sized project and can be difficult for you to estimate acccurately. If you are the winning bidder, I want you to finish it. To ensure you are fairly compensated on this project, I am following vWorker.com Best Practices and using the "Hybrid Payment Variant". To bid: Read about the "hybrid payment variant" at this link. Describe to me, exactly what portion of the entire project you'll do for the trial portion only. Place your pay-for-deliverables bid for doing just this trial (and not the entire project). Remember, your bid must be less than $200.00 if you are from an emerging economy and less than $700.00 if you are from a mature one. In your comment, tell me how much per hour you will charge me for the remainder of the project, if you are selected. Note: I may choose to opt-out of this second stage if I do not like your performance in the trial. So be sure to give me your best work at all times. Judge the trial results: If the worker completes it successfully, then go to the next step and hire them for the remainder of the project. If they didn't, the triple-point-guarantee gives you your money back. Rather than having to have waited until the end of the project to know they weren't good, you've figured it out in a very short time. You can now repost it. And you might consider using some other best practices in this document (such as "trial by fire" or "hiring a sherpa") to improve your worker interviewing process. Remainder of project: You award them a second project for the remainder of the work, using pay-for-time. This slashes the potential for project failure by 5 times (from a troubling 25% to less than 5%)! And, using pay-for-time also slashes the vWorker.com fee from 15% to 9%, saving you 40%! Note that you do need to follow the normal pay-for-time procedures when you get to step #3. This include daily monitoring of your worker's AccuTimeCard™ and progress. If you don't have the time, ability or inclination to do this, then you should use the 3rd variant instead: Hybrid Payment Variant + Sherpa. Hybrid Payment Variant + Sherpa: This is the middle-of-the-road priced variant. It requires no additional supervision of the worker on your part. Click here to learn more. This option works the same as the Hybrid Payment Variant. However: rather than supervising the worker while they are working under pay-for-time, you hire a 3rd-party expert to do it for you. A Tech Sherpa / Project Sherpa is a pre-screend pro, who does this for you and completely relieves you of daily supervision. A Sherpa charges $25-$90/hour (depending on where they live), and at the beginning you can expect they will take 30-45 minutes each day to do their review. Later, as the worker proves to be reliable, you can safely reduce this to monitoring to once every few days and cut your costs further. And as the worker continues to prove themselves, you can ultimately reduce it to just a once-a-week review. Even with this additional cost, it is cheaper than the "Raise the Worker's Bid" variant. And the larger the project, the more it will save, versus simply marking up their bid. To hire a Sherpa, chose that option when you post the project (under "Project Management".)
	Back to top

7) How can I save the most on the vWorker.com fee (and also reduce overall project costs)?
	You can cut the vWorker.com fee by 56% (and cut overall project costs as well) by following the two best practices below. The best part is that when you use them together, you'll not only save considerable amounts of money, but you'll also improve your project success rate and the long-term relationship with your worker. Save 16%: Pay with a preferred payment method. Simply changing the way you pay can save you substantially. If you pay via snail mail check, ACH or wire, it's cheaper for us to process, so we pass the savings on to you. You can save an instant 16% on an open-auction project, with very little additional effort! Click here for more information. Save 40%: Post projects using pay-for-time (using both the standard and hybrid models). Pay-for-deliverables gives you maximum protection and is the safest way to work with a new worker on a very small project. That's because the triple-point money-back guarantee ensures you'll get the work to-contract, on-time and on-budget, or your money back. However, it also comes with a price. It's significantly more expensive than the alternate method which is called pay-for-time. Pay-for-time drops the vWorker.com fee on open-auction projects from 15% to 9%, which is a savings of 40%. It also has a much higher success rate: its failure rate is 500% - 10,000% lower than pay-for-deliverables. For this reason, some employers use pay-for-time exclusively. But unfortunately, standard pay-for-time doesn't work for all people and all situations. First, you do have to supervise your worker closer (check their AccuTimeCard™ and work daily). This has the added benefit of increasing product accuracy and quality (especially when paired with the spiral model). But not everyone has the time, ability and/or desire to do this. For many of those people, hiring a Sherpa to do the supervision is a way around this problem. But what if you don't want to hire a Sherpa? Or what if you are hiring a new worker, and want some sort of guarantee on the deliverables? Fortunately, there are two best-practice variants that overcome both of the above problems and will allow anyone to use pay-for-time on any project (and vastly improve their project success rate and substantially lower their costs). These are called the "Hybrid Payment Variant" and the "Hybrid Payment Variant + Sherpa". Click on the links above to learn more about them. Or you can click here to learn why standard pay-for-deliverables tends to fail on larger projects. When you combine the above two methods, you'll save 56% on the vWorker.com fee on open-auction projects! And your vWorker.com long-term costs will be significantly lower than virtually every industry competitor.
	Back to top

8) Why should I switch from pay-for-deliverables to pay-for-time when I rehire a worker?

Pay-for-deliverables is an excellent way to guarantee safety when hiring a new worker for the first time (on smaller sized projects). However, those safety features come with some requirements that cause it to fail on larger projects (which includes repeat-work). Once your worker has proven themselves, you can save money by removing some of the protections you no longer need, and simultaneously add new ones that are more appropriate to repeat work. You do this by switching to pay-for-time. This will:

Reduce the vWorker.com fee by a hefty 40%.
Slash the chance of your projects failing by 500% - 10,000%. That's because pay-for-time projects fail only 1-5% of the time, versus 11-27% for pay-for-deliverables.
Allow you to use agile development methods like the spiral method that reduce the time it takes to develop your project, create a more accurate product that is more in line with your business needs, and drastically reduce the risk of project failure. These methods are not compatible with pay-for-deliverables (click here for more details).
Reduce admistrative overhead for you and the worker, and gain the flexibility required to handle recurring work:
- You no longer need to setup a separate project for each task you want your worker to do. This substantially reduces your administrative time and effort.
- You no longer need to write a detailed specification of every task in advance. This saves you more administrative time and effort, allows your worker to get to work faster, and allows both of you to work more flexibly and dynamically.
Increase worker productivity by aligning their interests with yours:

It is a myth that workers are able to accurately estimate the time a project will take. Most good workers underestimate by two to five times and some more. And the larger and longer the project, the larger the underestimation.

What this means is that you can almost guarantee that your worker severely underbid (and was underpaid) on your pay-for-deliverables project. That might sound like a good thing, but if you think about it, it's not in your best interests either. When the programmer takes an unexpected 50-80% paycut over a long period of time, this will usually cause them to withhold their best effort. It encourages them to use questionable short-cuts that save them time, but that cost you more later (see technical debt). It encourages an adversarial relationship between you and your worker that can lead to both of you arguing excessively over requirements changes. And in extreme cases, it may even result in them quitting the project in the middle of it.

By switching them to pay-for-time you are saying that you are interested in creating a mutually-fair long-term relationship with them, where they will be paid fairly. This increases their motivation, availiblity to you and their productivity.

Pay-for-time also gives you the "AccuBilling money-back guarantee", where we guarantee you:

No paying for padded time: Your worker will log into the AccuTimeCard™ so their time will be accurate to the second. This eliminates the most common cause of billing fraud: falsified timecards.
No paying for non-work: We give you the ability to view images of the Worker's desktop (and optionally their webcam) so you can supervise them as easily as if they were in the next office. We guarantee refunds for unproductive time like unauthorized breaks, playing games, unauthorized talking on the phone and sleeping on the job. This eliminates the second most common cause of billing fraud.

Using pay-for-time is one of the top "Best Practices" for saving money and is an important reason why vWorker.com's long-term costs are significantly lower than virtually every industry competitor.

Click here for more information on pay-for-time.

9) The worker I hired keeps missing deadlines. What can I do to stop this?

Calculating a Realistic Delivery Date from a Worker's Estimate:

Do you have a good worker, whose only problem is that they can't seem to deliver on time? This is actually very typical in many industries. For example, the Standish Group found that there is a 75% chance that any software project will not be delivered in the time estimated, and other industries are similar.

The good news is that there are ways to manage this. By completing the vWorker.com requirements wizard, you can greatly increase the chances of on-time delivery. But even this is not enough, because a competent worker can still estimate incorrectly despite this.

To avoid an unpleasant surprise, we highly recommend that you take the delivery date that your worker estimated and calculate a realistic delivery date. That date will be either 5x or 2x longer than the worker estimated. You will not reveal this date to the worker, nor will you enter it into the site as an official date (since that would defeat the purpose). Instead, if the worker misses a milestone deadline and is still doing a good job, you will dole out some of the extra slack time that you have. And if they are not doing a good job, then you can still hold them accountable to the original date, and take the project into arbitration for a refund (via your money-back guarantee). This puts you in the driver seat.

Why are competent workers so bad at estimating?

There are a number of reasons. The main ones are:

Only 25% of projects are completed on time. 50% are late/over budget and 25% never get delivered at all.

Unforeseeable problems:

Many of the problems that come up during development are unforeseeable. If you have ever started a "simple" home improvement project and later found it was much more complicated than you realized, then you know first hand how programming can be...even for the experts.
Misunderstood/unclear requirements:

When the requirements are unclear, the worker usually underestimates what it takes to build your project. To use an analogy, they may estimate your project as if you wanted a comfortable house. Only mid-project do they realize that you were expecting the Taj Mahal, and realize that they under estimated.

So, how do I handle this?

With a few simple but innovative management techniques, you can handle this problem so that it doesn't derail your project:

The Realistic Estimate:

Take the worker's estimate and secretly calculate a more realistic estimate by multiplying their estimated time by 5. If the worker has given you the estimate after all of the requirements have been fully documented in a formal document (and/or prototype) and finalized, then you only need to multiply it by 2. (Click here to learn where these numbers come from.) Then, use this realistic estimate in your planning, rather than the worker's estimate.

It's important that you NEVER share your realistic estimate with the worker. If they feel they have too time to spare, they will not work as hard on your project and it will defeat the whole purpose of this technique. Do NOT enter the date into the vWorker.com web site or put it anywhere where the worker might learn about it. Instead keep it like a secret in your "back pocket".
Managing a missed deadline:

Managing missed deadlines properly actually begins before the worker starts your project. If you wait until the end of your project to start managing them, your options will be much more limited than if you did it earlier. To do this, tell the worker that before they start, they must list out all of the tasks in the project and how long they will take to reach each milestone. Each task length should be 2 days or less. If it comes out to be more, then they should split into smaller sub tasks that are 2 days or less. This method has been proven to produce more accurate estimates.

Then let them start the work and have them report to you when each task is complete. If they finish every task as planned, then that is great. But if they don't (which is more likely), then the minute they miss one, tell them to re-estimate it (and the remaining items, as described below). Remember, the slippage won't cause you a problem, because you will have accounted for it in your realistic estimate.
How a worker should re-estimate tasks:

It's important that the worker re-estimate properly. First, to ensure that they are doing a good job, require them to increase their commitment to your project (see "commitment terms" for more details"). Once they do, then tell them to re-estimate the time for the current task. Software estimation experts have found that if a milestones was missed by an amount (say 20%), then the worker should add at least 20% to all other milestones as well. Workers are often tempted to gloss over this, but you should insist on them doing this.
Stay in the driver's seat:

It's important to understand that as long as you DO NOT reveal your secret delivery date to the worker, you are in the driver's seat. You can decide to dole them more time from your secret estimate. Or you can decide not to and take them to arbitration for a refund. However if you make the mistake of telling the worker that your realistic deadline is their "real" deadline, then you no longer have that option, and MUST give them ALL of that time. So it is always better to keep it hidden "in your back pocket".

Where do we get these numbers from?

These numbers (and some of the techniques as well) are taken from the book "Software Estimation: Demystifying the Black Art" by guru Steve McConnell. McConnell graphed the inaccuracy of estimates on tens of thousands of projects that were done by expert estimators and found some interesting patterns. At the beginning of the project, their estimates were off by as much as 4x. When the formal requirements were complete, it was reduced to 1.5x. However, since most workers are not experts in estimation, we recommend using 5x and 2x instead.

If you are interested in learning more about this concept, a good synopsis is at: http://www.construx.com/Page.aspx?hid=1648

10) Self Defense 101: 5 Things Every Entrepreneur Must Do, to Avoid Getting Burned by a Rogue Techie
	New entrepreneurs don’t realize that a falling out with a technical resource is potentially one of the most dangerous times for their fledgling business. I have talked to entrepreneurs who have lost their websites, their customer lists, their emails and even their bank accounts. If this happens to you, you will waste weeks or months scrambling to regain control, and in some situation you never may again. Fortunately, it doesn't have to be that way. Avoiding this situation is very easy, if you just know a few simple tips. Your domain name: You register your domain name with a company called a registrar. The registrar lets you setup different contacts for the administrator (the owner) and technical contact (the techie). It’s vital that your techie set you up as the administrator, and not themselves (which unfortunately happens to a lot of entrpreneurs because they don’t know to ask). If your techie is the administrator, and you have a falling out, they will own your domain name…even if you paid for it. And they will have every legal right to ransom it back to you, keep it for themselves or even sell it to a competitor, and you’ll have absolutely no recourse. So make sure you tell them to make you the administrator, and then verify afterwards that they did what you instructed. To confirm, just go to a WHOIS site like http://www.networksolutions.com/whois/index.jsp . Type in your domain name and you can verify the official record. If something is wrong, immediately call your registrar to get it corrected. Your hosting provider: Once your website is coded, a company called a hosting provider stores your website on its server and allows it to be seen on the internet. Unfortunately this is also an area where many naïve entrepreneurs lose control. There is also an administrator on this account, and if you are not it and you have falling out, your techie can take control of your website. You might be able to take the expensive and time consuming step of suing them to get it back. But even if you succeed it will be slow, and they will have plenty of time to deface it, destroy it or give it away to a competitor. So after your techie sets it up, you need to call your hosting provider and verify that you are the administrator and not your techie. Specifically ask them what protection features they offer to safeguard against a rogue techie. They should tell you how to ensure your techie has a subaccount with minimum permissions. If they don’t have any protections, then switch to a provider that does. Minimum permissions: This applies not just to your hosting provider sub-account, but any account you give your techie access to (gmail, secure certificate account, etc). You need to make 100% sure they have all the permissions on the account to do what they need, but not a bit more. This is called the concept of “minimum permissions”. If you are unsure how to do this, then contact the provider of that account and ask them how to set this up. Unique passwords: Many people hate passwords and use the same one they’ve memorized for all their accounts. If you do this, you may think you’re being smart, but you are actually playing with fire. Once you give access to your techie on any of the accounts (or they guess it), then they will have access to everything. As an example, one entrepreneur gave a techie the login to their gmail account, and didn’t think about the fact that it was the same password as their bank account. After the falling out, he was shocked to find that not only were all his email deleted but his bank account was cleared out. Don’t put people into a situation where you tempt someone to do something horribly wrong. Protect all your accounts with unique passwords. The best way to do this is to have a master document where you store all your password. Of course, you should protect this document like you do your passwords: hide it someplace non obvious, encrypt it in case it falls into the wrong hands and have a backup somewhere. If the information is particularly sensitive or involves very large sums of money, it is worth it to invest in a safety deposit box. Kill Access ASAP: If you get into a disagreement with your techie and are forced to fire them, many people might look for a stiff drink or call their significant other to tell them what happened. Those are all fine things to do, but before you do that, the first thing you should do is immediately close every account the techie had access to (or at the least change the passwords). One company fired a particularly bad employee and neglected to follow this rule. The techie logged into the system after hours, copied personally embarrassing emails on the company server and then distributed them to the public. At another company, the techie remotely grabbed their customer list and took them to a competitor, which helped him procure a job there. You don’t want this to happen to you, so kill access ASAP.
	Back to top

11) What's the difference between a Technical Co-founder and a Tech Sherpa?

Non-technical entrepreneurs starting companies are often urged to find a technical co-founder. A technical co-founder performs the same roles and assumes the same responsibilities as a Tech Sherpa™ in a new company. However there are important differences between the two.

Tech Cofounder:

Pros:
- Short-term: Free or substantially discounted work, in return for "sweat equity"
- Doesn't get paid unless you get paid (your company makes profits)
  - Less risk if you never turn a profit
  - Interests are aligned: they want the company to be profitable as quickly as you do
Cons:
- Long-term: Expensive (the more successful you are, the more expensive they are)
- Less control: Requires you to give up control of your company (in return for their doing the work for free or at a substantial discount
  - They may disagree on the direction of the company (example: most entrepreneurs are risk-takers and most techies are risk-averse)
- Poor motivation:
  - Most new ventures take years to show a profit and during that time the tech cofounder is either not paid, or paid below market rates. During that time, they have an economic incentive to prioritize other people's higher-paying projects over yours.
  - Often the cofounder is initially responsive, but over time will become slower and slower to respond (for the same reason).
- Over-dependence: You can be held hostage, because you rely solely on them and they are an equal partner. There are many stories of tech cofounders forcing entrepreneurs to give them larger percentages of the company and higher pay, to avoid a shutdown of the entire company.
- Hard to find the "purple cow": It's difficult to find one who is:
  - A technical expert *and* excellent communicator.
  - Is patient on profits and still fully motivated.
  - Isn’t already working on something of their own.

Tech Sherpa™

Pros:
1. Better sustained motivation:
  You're paying an outside party to perform the work at market rates.
2. Faster:
  They are working full time on your project, rather than just part-time in their spare time.
3. More control over them:
  They are an employee rather than an equal partner.
4. Legal protection:
  Contract states their payment terms and they can't suddenly demand to be paid a larger share of the company.
Cons:
1. Requires payment (but note that this larger expense in the short-term saves you money in the long term, if your venture is successful.)

Click here to learn more about tech sherpas.

12) What is spiral development and how can it help me with my project?
	Note: although this article discusses software development projects specifically, the concepts and ideas apply to any type project which requires intellectual or creative work (such as design, translations, marketing, legal, etc.). The simplest and most traditional way of developing a project is called the "waterfall model". It also results in a distressingly high industry failure rate of 75%. Once the industry realized this problem, it created other models that resulted in a much lower failure rate. On of the most powerful models was the spiral method (created by Barry Boehm in 1986). In addition to significantly reducing your risk, it also allows you to create your software much more accurately, faster, and cheaper than the traditional model. This article discusses both models and how the spiral model overcomes the shortcoming of the waterfall model. (To skip the discussion of the waterfall model and jump straight to the spiral method, click here). The traditional method (waterfall model): Traditionally, most projects are done according to the "waterfall model". It's called this because the steps look like a waterfall: The waterfall method: simple but highly unreliable. To give an example: let's say you are creating the next Facebook. In the "requirements" stage, you create a complete document of the thousands of features you want the site to have. After taking a few weeks to do this, you move to the next stage in the waterfall: "design". When this happens, the requirements are locked and you cannot make any changes to them. This lock-down makes it much easier and quicker for the technical workers to their work (but as we'll see later is one of the main reasons this model results in software that is not acceptable to the end user). Theoretically, at the end, you should receive exactly what you wanted and are delighted. However in practice this rarely happens (except on very tiny projects). A 2004 study found that 75% of projects following this method failed or were never used. Entire books have been written on the many reasons why this model performs so poorly. Some of the biggest reasons are: The myth that you can document all the true requirements in advance: The waterfall model requires you to document your entire project 100% accurately (and completely) in advance. If you don't, then you will end up with an end product that does not meet your business needs (and/or end up with conflicts with your worker over scope). This sounds easy/reasonable in theory, but in practice it only works very small projects. On anything larger, you'll find that: You will simply forget to include some requirements. (No human being can design complex software 100% perfectly in advance). Others you will remember to include, but will be misunderstood by the programmer due to miscommunication and will end up wrong. Others will be perfectly communicated and perfectly implemented by the programmer. But when you see them live in the product, you'll realize they don't meet your business need (and/or should be done differently). Again, no human can visualize complex software 100% perfectly in advance. Others will be perfectly communicated, implemented and still be correct...at the time you created the requirements. But due to business needs changing during the time of the development (which can weeks, months or longer), the needs changed and they are now wrong. (Here's a real-life example.) The myth that your programmer can estimate 100% accurately: Even if you create the requirements 100% correctly (which you can't) the programmer still will not be able to create an accurate estimate from it. Studies have found that time estimates (from otherwise excellent programmers) are too small by (on average) two to five times. The larger the project the larger the chance of underestimation. There are many reasons for this (which you can read more about here). The important thing to understand is that your Programmer will probably seriously underestimate how much work the project will take. This leads to many of the missed deadlines, and slow project delivery problems of the water-fall method. It can also contribute to Programmer motivational issues when the programer's pay is tied to their estimate (i.e. pay-for-deliverables). When the Programmer takes an unexpected 50-80% paycut, this can cause them to withhold their best effort, use questionable short-cuts to save time (that cost you later), argue over changes excessively, and even quit on the job. The myth that you can competently manage something you can't see: There is an old business adage that says, "You can only manage what you can measure". You "measure" software when you actually use it for the first time. And with the waterfall method, that only occurs at the very end of the project (which is weeks or months later). This means you will not be able to tell until the very end if: Your worker did a good job or a bad one. Your worker is fast or slow. The project is on schedule or late The software is high quality or buggy The software meets your requirements or doesn't I'm sure you can imagine the many ways that this makes a project unmanageable. Some new employers think that the away around this is to use status reports. Status reports are useful tools, but they also have several large limitations: Programmers often get "tunnel vision" and don't see problems that you (as a 3rd party) will see right away. If a miscommunication has occurred, the programmer can't and won't realize it's happened on their own. Many programmers want to please their clients and tend to dwell on good news and downplay (or omit) real problems. If the programmer is incompetent or deliberately working too slow, they won't volunteer this information in a status report. This is why status reports rarely give an accurate picture of a project and the only way to truly "measure" the software is to use it. And this is why postponing this until the end of the project (which is what happens in the waterfall model) leads to such a dismal failure rate. The above are just a few of the many reasons that waterfall method projects fail so often and consistently. The spiral method: To deal with the unacceptable failure rate of the waterfall method, newer methods have been created. These are called "agile" because they are nimble and quick. They have a much higher success rate and allow software to be developed much faster, cheaper and more accurately. A very effective one is called the "spiral method". The spiral method, with an example of four iterations. This method results in much faster, cheaper, more accurate software development with substantially less risk of project failure. In the waterfall method, you wait months before you see the product live for the first time. With the spiral method you see live releases of your software much more frequently (often every week). And each release builds on and is an improvement on the last. Also, if your worker is not doing a good job, you'll know right away and can immediately switch to a better one (rather than having to wait until the very end). This method is called the "spiral method" because your software evolves larger and larger (like a spiral) with each release. Here's how it works. You start by identifying the smallest possible core portion of your final product. Your programmer designs it and develops it. At the end of the week, you get to view and try out the live software and see how it works. At that point, you reach the end of the first "swirl" (which is caused an iteration). You may find some things that are wrong. If so, you tell the programmer and they go back to work. The next week, you receive your next release. If it's perfect, you now tell the program to add on the next most important core features, and repeat the process. It will take several iterations to get everything right. But they happen so quickly, that this doesn't take a long time. And every release, you see more and more of your software, until it's finished. Why is this a better way to create software? There are several reasons. Extremely accurate final product: The end result will actually be exactly the way you want it to be, instead of being incomplete or buggy. Ability measure and accurately manage the project: The spiral model lets you view/use the software after every iteration. Every week you will know: If your worker did a good job or bad. If your worker was fast or slow. If the project was on schedule or late. If the software was high quality or buggy. If the software met your requirements or didn't. If they are not doing a good job, you have the ability to recognize it early and switch to someone who will; instead of only knowing after they've wasted considerable amounts of your time and effort. Also, each release of the spiral method is the perfect time to inspect the code and see the worker has accumulated any technical debt. (Click here for more information on technical debt and how to manage it). Less arguing; more working: Workers in the waterfall method are in a mutually-opposed relationship with you. Every change to the software (whether caused by your missing requirements, or their misunderstanding of them or their under-estimation) costs them money. This often results in arguments over requirements, including needed changes. This can severely reduce worker productivity which results in slower progress. It can also cause you to have to constantly cycle through new programmers, which results in high turnover costs for you. With the spiral method, changes become mutually-beneficial. Now, instead of getting into fights over changes, you can harness them for competitive advantage. This results in higher programmer productivity which increases the speed of your project and reduces your time to market. And by creating long-term relationships, you also greatly reduce your turnover costs. Release to the public earlier: Unlike the waterfall-method, you don't have to wait until the very end of the project to release to the public. Since you're forced to work on the most important features first, you'll find you get a feature-complete product for your target market much earlier in the process. Once you do, you can release it to the public and tweak it with further improvements. This lets you get to market sooner and may mean the difference between having the first-mover advantage and losing it. To give a concrete example: If you are creating the next Facebook, the entire site will ultimately be hundreds of pages in size and encompass thousands of features. With the waterfall method you might take several weeks to lay all that out on paper. But with the spiral method, you don't. Instead, you identify the smallest possible core of the product. And after thinking about it, you realize it's the profile page with two things: the wall tab and the info tab. So you start with just that. Now you need some workers. You post your project and hire a programmer and a user interface (UI) designer (unless you are already an experienced UI designer). You describe what you want the profile page and tabs to do to the UI designer and they create paper mockups. After a few attempts they look good to you. So the UI designer passes them on to your programmer, who codes them into a live site that you can then visit in your browser. Unlike the waterfall method, all of this is very quick. In about a week, you're actually viewing your live site with the core working! Of course, once you see the working site, you'll realize it's not what you wanted. You'll see that you forgot some things, made some things too difficult and could do other things better. If you were using the waterfall method you'd be in trouble. But instead, you just tell the UI designer the changes you want and the process repeats itself. This time you might get a live release from the programmer in 3 days. It might be perfect this time; but if not you repeat the process until it is. Then you take on the next most important feature, in the same way. Incrementally, but very quickly, your site takes shape. You are able to build your site faster, cheaper, more accurately and quicker than using the waterfall method. Click here to learn what payment methods work best with the spiral model.
	Back to top

13) What payment methods work best with spiral/agile development?
	The standard pay-for-deliverables payment method requires the worker to place a fixed-price bid on your project at the very beginning. In order to do this, they need to know everything the project entails. This requires you to define your entire project up front, which is the main feature (and shortcoming) of the waterfall method. So this way of working is incompatible with the spiral / agile method. Pay-for-time, on the other hand, does not require you to create a 100% accurate (and complete) requirements document up front, and does not require the worker to make an advanced estimate. This pairs up perfectly with spiral / agile development and is why we recommend this payment method for it. Some may be tempted to try to use a modified version of pay-for-deliverables on an spiral/agile project by doing a new pay-for-deliverables project for each iteration. This is possible to do. However, unless your project is very small, you will find that the increased overhead required to define each iteration completely in advance will negate the main benefits of spiral/agile development: which are speed, and reduced costs. A much better idea is to use one of the hybrid methods ("Hybrid Payment Variant" and "Hybrid Payment Variant + Sherpa"). These methods give you the protection of pay-for-deliverables for the first few iterations when the worker is new and untested. Then once they've proven themselves, you switch to pay-for-time. This gives you and them more flexibility, reduces your vWorker.com costs by 40% and allows you to enjoy all of the previously mentioned benefits of spiral / agile development.
	Back to top

14) The final deadline arrived and my project is nothing like what I asked for! What could I have done differently?
	It's extremely rare for a software project to just suddenly go bad at the end. A project that fails catastrophically usually shows many warning signs throughout its life-time. If you are paying attention and managing your project correctly, you should never get to the very end of the project and be so horribly shocked. The most important key is to touch base with your programmer as often as possible. This lets you identify problem programmers early and resolve issues while they are still small and easy to fix. Most new employers do the exact opposite. They believe that once they give they've given the initial description to the programmer, their work is done. They expect they can relax while the programmer works, show up at the end of the process and pickup perfectly delivered software. But this is not how software development works. The main reason is that with even the simplest contract, there are numerous ways to interpret the terms. To use an analogy: imagine you are hiring a contractor to "build the house of your dreams". You tell the contractor and he imagines this: The contractor's interpretation of "the house of your dreams" So he quotes you $300,000 for it and says he'll be done in 6 months. You think "Wow! This is the most amazing deal, and unbelievable! I'll take it!!" That's because in your head you are imagining this: The actual "house of your dreams" Obviously, there is going to be a huge problem! If you simply sign the contract and take a vacation for three months, you'll return to an enormous headache. Had you been checking in consistently with your contractor, you would have realized something was wrong the minute he started pouring a driveway instead of a reflecting pool! Software development is the same way. You need to check-in on your programmer as often as possible to identify problem programmers early and resolve issues while they are still small and easy to fix. On pay-for-deliverables projects, you should be checking in every week at a minimum (and more often if the project is a short one). On pay-for-time, you should be checking their timecard daily, at first. Once you know for sure the project is on track, you can reduce the check-ins to every few days and eventually once a week. When you check-in, don't just ask "How's it going"? You'll almost always hear back, "it's going great!" because the programmer doesn't want to disappoint you. This kind of check-in gives you no real clue as to how the project is really progressing. Instead you should be requiring the programmer to show you a live demonstration of what was completed since the last time. A great way to do this is using the spiral / agile develompent method, which is designed to give you the superior feedback of frequent demos. If your programmer says they can't demo something until the very end (on any project longer than a week), then that is a huge red flag. Explain to your programmer that you need them to perform in a more agile manner. If they won't, then strongly consider choosing another programmer that can. All of this checking does require time and effort. So it is worth it? A study by Boehm and Papaccio found that getting a requirement right at the beginning of the process cost 50x to 200x less than doing it at the end. So if you want to cut your costs and reduce your chances of project failure significantly, then the answer is "yes". But what if you don't have the time to check as often as you should? Or what if you don't know anything about programming and simply don't have the knowledge or ability to do it well? Are you doomed to a string of never-ending failures? Fortunately, the answer is "no". You can hire a Tech Sherpa to do the check-ins on your behalf. The Sherpa is an expert themselves in programming so they know what to look for. They can tell if a programmer is not going to work out, as well as sniff-out requirements issues and other problems early in the process. This lets you eliminate them before they become larger and more costly. A Sherpa does cost a little extra, but this investment will more than pay for itself in time and cost savings on your project. And the larger the project, the more the savings.
	Back to top

15) What is technical debt and why do I need to manage it?

Have you ever been in this situation before? You have a project and at first your programmers make fantastic progress. You’re delighted and add on a bunch of new features. This time, you notice that progress slows down and they start missing a deadline here and there. But you know they are giving your project the same attention as before and working their hardest, and they delivered so well before. So you chalk it up to bad luck and ignore it, and give them some more features to do. This time, they take even longer than before and you get a little more worried, but decide to press on. The process repeats itself until progress finally slows down to a snail’s pace. You end up receiving you later releases horribly late…or not at all. You end up spending much more time, effort and money than you planned and are unhappy with the result.

What happened to you? After all, your programmers weren’t goofing off or not putting in enough hours. What happened is that you probably were a victim of technical debt. If so, you aren't alone. Gartner group estimates that the cost of current global technical debt was $500 billion in 2010, and will reach $1 trillion in 2015!

What is technical debt? Every time your programmer creates a new feature for you, they must choose between two ways to create it:

The "short-term fast" way:
This gets it done very quickly, but in a way that will be difficult for you/them to add features or fix bugs (perform code maintenance and enhancement) in the future.
The "short-term slow" way:
This gets it done much slower, but in way that will make it much faster to perform code maintenance and enhancement in the future.

You might think the "short-term fast" way would always be the best. However it rarely is. The "short-term fast" way is actually the long-term slowest and most expensive way, because:

Only 10-20% of the money and time you spend on any feature will be on the first release. 80-90% will actually be for maintenance and enhancements.
The later in the process you wait to do work on something, the more expensive it becomes to do it. Often the costs grow exponentially.

So every time your programmer chooses the "short-term fast" way, it costs you more in the long run. That is what technical debt is. You will not see it as an end user when they release it to you, because your software works the same regardless of how they build it. But inevitably you’ll pay it back when you try to add to the software or have to fix bugs. And you will for it back with increased time, money, effort and missed deadlines.

So if the "short-term slow" way is so much better, why would programmers ever choose to incur technical debt? There are a few reasons (one good, and the others not):

Good reason:
1. They understand that you need to get your first version to market as quickly as possible (perhaps to win funding). So they explain the choices to you and you choose to take on the technical debt for now. If you achieve your goal, you are fine with spending much of version 2 cleaning up the debt that you've accrued in version 1.
Bad reasons:
1. The programmer sees they are falling behind schedule and doesn’t want to miss the deadline so they take shortcuts to make up the time.
2. The programmer doesn't understand that there is a better way to implement a particular feature. So they unintentionally take on technical debt that they did not need to.
3. The programmer is too inexperienced to understand the trade-offs involved in technical debt and inadvertently takes it on without even considering it.

So how do you avoid this problem? Obviously you can’t rely on your programmer to announce, “I’m taking on technical debt, now!” when they themselves may not always realize they are doing it. And technical debt is very insidious because you can’t actually see it when you test the software (as an end-user). The software will look and works exactly the same way no matter how they build it (as long as they code it successfully). So testing won’t reveal it.

So what do you do? The way to determine when technical debt is occurring is called an inspection. If you are technical then you can do this yourself. If you are not (or are managing a project outside of your technical expertise) then you can hire a Tech Sherpa to do this for you for a small number of hours a week. Inspections are like an investment in your own future, and will save you far more than you spend.

Here’s what needs to be inspected:

Design/architecture inspections: After the design/architecture is completed, the documentation is reviewed. Technical debt is identified and either deemed an acceptable trade off or eliminated.
Code inspections: All code is reviewed (line by line) for technical debt. If you are using the spiral development method then this will occur right before or after each release to you. Again, technical debt is identified and either deemed an acceptable trade off or eliminated.

Managing technical debt does take time and effort. However it is an investment that pays back on itself many times over. On very small programs that you know will never grow into anything bigger, you may be able to safely ignore the issue of technical debt. But on medium to large sized projects, managing the debt is essential to completing the project on time and on budget.