HW23: Chapter 22
22.6. Fixed-price contracts, where the contractor bids a fixed price to complete 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.
The primary way this type of contract could increase risk arises because if the contractor is motivated primarily by profits they may find certain risks more acceptable to increase their profit margin. This is due to the fact that often the methods to mitigate risks come at increased cost thereby decreasing the profit made by the contractor. For example, if the project manager identifies a deficiency in the number of personnel with a certain skillset the plan to mitigate this risk may be to hire another engineer with similar skills. The contractor may see this risk, but also know that hiring an additional engineer comes at a significant cost and decreases the profit of the project and may choose to accept the risk without managing it effectively.
Another way this model may increase risks takes place in the bidding process. In my experience outside of software engineering, contracts are often awarded to the contractor with the lowest price. While it is possible that this contractor is willing and able to complete the project at a far lower price point than their competitors, it is often the case that the delivered product reflects that lower price point. Even still, assuming the lower cost contractor is able to deliver a similar product to their competitors, doing so almost certainly means that more risks were taken. Whether the risk management strategy is avoidance, minimization, or contingency plans, there is almost always an increased cost associated with implementing one of these strategies.
It is also possible that the contractor has developed a more effective approach to development that companies due to extensive experience and a large pool of experienced developers and are able to better manage the risks than even the company itself. But as Sommerville points out, software management has challenges that other disciplines may not have such as the product being intangible, the engineering processes differing between organizations, and maybe the most important one being that many large projects may be different enough that lessons from past projects do not apply to new projects.
As a side note, in my previous work outside of software engineering even the lowest bids for contracts seemed highly inflated but when considering the shift of risk from client to contractor it makes more sense that this would be the case.
The primary way this type of contract could increase risk arises because if the contractor is motivated primarily by profits they may find certain risks more acceptable to increase their profit margin. This is due to the fact that often the methods to mitigate risks come at increased cost thereby decreasing the profit made by the contractor. For example, if the project manager identifies a deficiency in the number of personnel with a certain skillset the plan to mitigate this risk may be to hire another engineer with similar skills. The contractor may see this risk, but also know that hiring an additional engineer comes at a significant cost and decreases the profit of the project and may choose to accept the risk without managing it effectively.
Another way this model may increase risks takes place in the bidding process. In my experience outside of software engineering, contracts are often awarded to the contractor with the lowest price. While it is possible that this contractor is willing and able to complete the project at a far lower price point than their competitors, it is often the case that the delivered product reflects that lower price point. Even still, assuming the lower cost contractor is able to deliver a similar product to their competitors, doing so almost certainly means that more risks were taken. Whether the risk management strategy is avoidance, minimization, or contingency plans, there is almost always an increased cost associated with implementing one of these strategies.
It is also possible that the contractor has developed a more effective approach to development that companies due to extensive experience and a large pool of experienced developers and are able to better manage the risks than even the company itself. But as Sommerville points out, software management has challenges that other disciplines may not have such as the product being intangible, the engineering processes differing between organizations, and maybe the most important one being that many large projects may be different enough that lessons from past projects do not apply to new projects.
As a side note, in my previous work outside of software engineering even the lowest bids for contracts seemed highly inflated but when considering the shift of risk from client to contractor it makes more sense that this would be the case.
Comments
Post a Comment