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. Many new employers 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 sprial development 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.
Subscribe to the vWorker Latest News Blog through RSS or email. Visit vWorker.com.
© 2001-2011 Exhedra Solutions, Inc.
