How work gets done. Guaranteed.

 

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 fixed-price projects tend to fail on larger projects?
6) What are better alternatives to a standard vanilla fixed-price 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 fixed-price to hourly 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:
  1. Safety: Maximize the protection of your funds.
  2. Quality and productivity: Improve project quality, speed project delivery and increase worker productivity.
  3. Risk management: Minimize the risk of your project failing.
  4. Costs: Cut the vWorker.com fee substantially, and the long-term costs of getting your project completed.
  5. 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.)
  1. 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.
  2. 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
  3. 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 occasionally 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 hourly.

Back to top


4) Which payment model has the highest project success rate?
   
Hourly projects have the highest project success rate. They fail very rarely: only 1-5% of the time...


...while Fixed-price 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 hourly project has a 3% chance of failing. But if you do the same project using fixed-price, your chance of failure sky-rockets to 23%. That's more than seven times (700%) riskier!

Why is this? The main reason is that fixed-price requires you and the worker to do two things which are either difficult or impossible to do on larger projects:
  1. You must document your entire project 100% accurately (and completely) in advance.
  2. 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 hourly (or one of the other alternatives to standard fixed-price) whenever possible. And we specifically recommend against using standard fixed-price when your project is a larger fixed-price 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 fixed-price 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 fixed-price projects fail 500-700% more often than the same sized hourly projects. So obviously there's something more at work here. What causes the difference?

Fixed-price projects have two requirements which are difficult or impossible to do on to do on larger projects. They are:
  1. 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.
  2. 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 fixed-price 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 fixed-price project?
   
Fixed-price projects give you the maximum protection on small projects. However, on larger projects, they have a 500% to 10,000% higher failure rate than hourly projects (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 hourly 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 hourly 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, hourly is probably the best choice.

What if you’re new to the site and trying to hire a new worker? If you do not feel comfortable without some sort of guarantee on the deliverables for your project, you may want to try one of our fixed-price variants. Although some of the variants below include doing parts of your project on an hourly basis, these strategies are meant to increase the success rate of your project while helping you save on the vWorker fee.

There are three fixed-price variants that are solutions to this problem:
  1. 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.
  2. Hybrid Payment Variant:
    This is the cheapest variant. It does require you to do additional supervision of your worker. Click here to learn more.
  3. 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.

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.
  1. 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.
  2. Save 40%: Post hourly projects using both the standard and hybrid models.

    Fixed-price 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 hourly.

    Hourly projects 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 fixed-price.

    For this reason, some employers exclusively use hourly projects, but unfortunately, standard hourly projects don't work for all people or in every situation. With the hourly project type, you will have to supervise your worker more closely (check their AccuTimeCard™ / 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 people, however, hiring a Sherpa to do the supervision is a way around this problem.

    Although you may not want to hire a Sherpa or you would rather have some sort of guarantee on the deliverables, there are two best-practice variants that will help to overcome both of these problems. The "Hybrid Payment Variant" and the "Hybrid Payment Variant + Sherpa" methods will allow anyone to use hourly on any project, vastly improve their project success rate, and substantially lower their costs. You can click on the links above to learn more about them, or you can click here to learn why standard fixed-price projects tends to fail more often the larger they get.
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 fixed-price to hourly when I rehire a worker?
   
Fixed-price 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 hourly. This will:
  1. Reduce the vWorker.com fee by a hefty 40%.
  2. Slash the chance of your projects failing by 500% - 10,000%. That's because hourly projects fail only 1-5% of the time, versus 11-27% for fixed-price.
  3. 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 fixed-price (click here for more details).
  4. 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.
  5. 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 fixed-price 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 hourly 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.
Hourly projects also give you the "AccuBilling money-back guarantee", where we guarantee you:
  1. 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.
  2. 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 the hourly payment model 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 the hourly payment model.

Back to top


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:
 Software Industry Project Success Rate
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:
  1. 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".
     
  2. 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. 
     
  3. 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.
     
  4. 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

Back to top


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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Back to top


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).
  1. 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:
     
    1. 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.)
    2. 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. fixed-price). 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.
    3. 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:
      1. Your worker did a good job or a bad one.
      2. Your worker is fast or slow.
      3. The project is on schedule or late
      4. The software is high quality or buggy
      5. 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.
     
  2. 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.
    1. Extremely accurate final product:
      The end result will actually be exactly the way you want it to be, instead of being incomplete or buggy.
    2. Ability measure and accurately manage the project:
      The spiral model lets you view/use the software after every iteration. Every week you will know:
      1. If your worker did a good job or bad.
      2. If your worker was fast or slow.
      3. If the project was on schedule or late.
      4. If the software was high quality or buggy.
      5. 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).
    3. 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.
    4. 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 fixed-price 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.

Hourly, 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 fixed-price on an spiral/agile project by doing a new fixed-price 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 fixed-price for the first few iterations when the worker is new and untested. Then once they've proven themselves, you switch to hourly. 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 fixed-price projects, you should be checking in at least once a week for a longer project and more often for a shorter one. With hourly projects, you should be checking the timecard daily at first to ensure that the worker is progressing at an acceptable rate and completing the work to your satisfaction.

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:
  1. 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.
  2. 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:
  1. 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.
  2. 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):
  1. 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.
  2. 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:
  1. 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.
  2. 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.

Back to top