Software projects are inherently risky, and the ways to run astray begin even before the project begins. The quality of a procurement solicitation governs the results of a project, laying a solid foundation for success or creating unnecessary problems that doom a project.
Since the negative examples are often more illustrative, here are a few pitfalls to avoid:
1. There is no such thing as etcetera in a specification. Over the past few weeks I have reviewed requests for proposals that list open-ended requirements for integration, mentioning one or two specifics and then the dreaded "etc." rears its head. The result is that vendors either decide not to bid or pad the price to cover the risk of the unnamed integration.
2. Fixed price requires fixed specifications. If you choose a fixed price contract, vendors cannot determine a price without complete and detailed specifications. Fixed price combined with vagueness can result in a game of change orders where bidders price the minimum and then add dramatically to the cost and time through a series of change orders. Some integrators specialize in this approach because it is difficult to switch vendors in the middle of a project.
3. Watch out for gold plating. If you need a system for ten people, don't specify that it must scale to 10,000 users. Otherwise, you will end up with a city bus when you had a compact car in mind. Vendors will do their share to upsell and goldplate all on their own without encouragement from the solicitation.
4. Don't dictate how to get there. Encourage vendors to use creative approaches to solve your business problem. You can easily ask for more than you need and therefore pay more than you needed to pay for a solution.
5. Don't wait too long for results. Be sure to break the project into short phases with measurable results. There are many software projects that drag on for years before shipping a product, only to find out too late that it does not meet business requirements.
Writing a solicitation that is specific and detailed, without reaching for the moon and the stars, can be the start of a successful software project.
Since the negative examples are often more illustrative, here are a few pitfalls to avoid:
1. There is no such thing as etcetera in a specification. Over the past few weeks I have reviewed requests for proposals that list open-ended requirements for integration, mentioning one or two specifics and then the dreaded "etc." rears its head. The result is that vendors either decide not to bid or pad the price to cover the risk of the unnamed integration.
2. Fixed price requires fixed specifications. If you choose a fixed price contract, vendors cannot determine a price without complete and detailed specifications. Fixed price combined with vagueness can result in a game of change orders where bidders price the minimum and then add dramatically to the cost and time through a series of change orders. Some integrators specialize in this approach because it is difficult to switch vendors in the middle of a project.
3. Watch out for gold plating. If you need a system for ten people, don't specify that it must scale to 10,000 users. Otherwise, you will end up with a city bus when you had a compact car in mind. Vendors will do their share to upsell and goldplate all on their own without encouragement from the solicitation.
4. Don't dictate how to get there. Encourage vendors to use creative approaches to solve your business problem. You can easily ask for more than you need and therefore pay more than you needed to pay for a solution.
5. Don't wait too long for results. Be sure to break the project into short phases with measurable results. There are many software projects that drag on for years before shipping a product, only to find out too late that it does not meet business requirements.
Writing a solicitation that is specific and detailed, without reaching for the moon and the stars, can be the start of a successful software project.