22.6
Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise.A blog post from Salsita Software, a professional software consulting company, nicely summarizes the issue with fixed-price contracts: “accurate software estimation is not possible even when perfect information is available about project requirements.” Software is intangible, complex, and generally differs from project to project, making it extremely difficult to accurately estimate a timeline and budget at the beginning of a project. If the contractor’s estimates end up being too optimistic, then the contractor might have to take a loss in pay, the developers might have to work overtime, and bad code may be produced as a result of a rushed schedule or tight budget. In this case, the risk of missed deadlines, blown budgets, and developer turnover increase. Additionally, if poor quality software is produced, which is likely, then the contractor risks their reputation, which can lead to fewer projects in the future. If the contractor plays it safe and estimates the project to cost much more money and take much longer to produce than it actually took, then the customer pays more than a fair amount for the work actually done. In this case, quality code may be produced, but the customer may not be happy that they overpaid for the contractor’s services, again risking the contractor’s reputation.
A better way to manage a software project is to have open and frequent communication between the client and contractor, and follow Agile methodologies when appropriate. This approach supports unforeseen changes in a software project, and allows the contractor and client to easily communicate changing requirements, costs, and timelines.