Estimating the current percentage of completion can be tricky business, but over the years there seems to be a pattern that has emerged in this industry. I call it the 90 Percent Complete Problem. It occurs when the project hits 90% complete, yet the project is nowhere near that close to being finished. Let's see why this happens. In a typical software development project, the client is provided with a status report (usually every couple of weeks) which shows the client how far the project has progressed. This is usually done using Microsoft Project or some other reporting tool. In many cases, funds are released based on how far a project is perceived to have progressed. And I stress perceived. In my experience, most software projects deemed to be 90% complete are usually more like 60-70% complete, if that. It seems like an innocent mistake, but there are serious consequences for the client when this happens. Let me explain.
When a project is deemed 90% complete, usually anywhere from 80-90% of the funds have been released to the developer, depending on how the contract was structured. And the remaining funds usually aren't released until the project is finished. For the developer, this means they have a large part of the project remaining, and no money coming in until it is done. Depending on the size of the project, this can spell disaster to the client, since the developer may not have enough money in reserve to complete the project. If you've ever heard of a company that failed to complete a software project, in 95% of the cases, this is why it failed.
Now you might wonder, why didn't the developer just budget the funds to last the entire project? That's a great idea, but in many cases the funds they collected from you went to pay for the developers working on another underwater project. This type of thing happens all the time.
So, now that I have you scared and ready to abandon your dream project, what can you do to mitigate this risk?
Carefully Review and Understand the Project Schedule
This is easier said than done, but it is absolutely critical that you understand what is behind the schedule. Here are some things I look for:
- Does the schedule consider regression testing, client changes, and other unforeseen issues?
- Does the weight of each component of the schedule seem balanced?
- Are the complex portions of the project pushed off until the latter stages, or are they tackled up front?
In the first point, it is important to understand that many of the unknown and unexpected issues are going to surface late in the project life cycle. That's when the users get to start playing with the application, and the obvious issues start to pop up. That is also why it is important to look at the schedule/project plan for balance. If the developers are doing the basic features early and all the hard stuff is at the end, you don't really have a balanced project plan. Each stage of the project plan should address some complexities of the project, or the difficult aspects should be addressed early on. This way when you get to 90% complete, the hard things are out of the way.
Structure the Payment Schedule Correctly
If you are going to go with a fixed price structure, it is absolutely critical that you pay no more than 5-10% up front, and then leave at least 25% remaining as the final payment. If you do nothing else right, this will save you a lot of grief. Here's why. Your goal is to make sure your developer is always motivated. And nothing motivates most developers like a big juicy payment at the end of the project. It also guarantees that if the project goes bust you are only out 75% as opposed to 100% of the project cost. You need to think leverage. Once you've paid the developer in full, you have none.
Keep these simple things in mind and you might avoid the dreaded 90% complete problem. Don't say I didn't warn you.
