You may have many good reasons to set up fixed-price, fixed-deliverable deals. However, you should not use them if you are in a hurry. Fixed-deliverable tasks cause two types of delays.

First, it takes time to specify the tasks. Then you have to negotiate the deal. Then you take time to do acceptance testing. This adds to the calendar time to complete a task. It also adds to the time spent by managers, which is often in short supply, since they are doing jobs like specification and testing that would ideally be done by developers.

Second, you can’t take the task away from the contractor, in whole or in part, until the job is closed. That can take a long time. If you have a job that should be finished in 6 weeks, you probably will know within 2 or 3 weeks if there is a problem. You won’t definitely shut down the contractor for nondelivery until 10 or 12 weeks are up. If you are on an hourly or weekly contract, you can bring someone else in after 3 weeks to try finishing the task, and switch, or work with both resources in parallel. So, the time to recover from a problem is THREE TIMES as long with the fixed price deal

I’m working with a client now that has suffered a four month delay while they wait for a development company to deliver a key piece of their product. If the product is delayed, why are they waiting around instead of hacking away frantically on the release? Because they hired the development company on a fixed-price, fixed-deliverable deal, and they want to see if they can get what they paid for.

The solution is to get rid of the fixed price deal, and get back to a situation where they can bring in someone new, or work on something different, as soon as they see early milestones are being missed. If a task is not finished when it needs to be finished, than another resource should take over the task immediately and finish it.