Process code for software procurement

2a. Planning phase
Vector Vector Vector Group 2
Union
Rectangle Rectangle
Ellipse Ellipse Ellipse Vector
Group Vector Group
symbol-dev
symbol-dev
Vector 3 Vector 5 Vector 4
Union Group 2
The previous phase culminated in choosing a strategy for obtaining software—an existing solution (proprietary or open source) or a new one (building in-house or contracting a vendor). You’re here because you either chose to procure existing proprietary software, or contract a vendor to build custom software—both of which will require you to address the market.
This second phase is about planning. You’ll articulate a plan and performance criteria in the form of an RFP that you put out into the market to find a vendor. At the end of this phase, you will have a solid plan for the software process, and be well on your
way to finding an excellent development partner.
Writing an RFP is an exciting opportunity to shape a software tool that will help you and your colleagues do your job better. It is a formal document, with legal and budgetary heft, but also a design document. It is your opportunity to describe the ideal software, and also the perfect partner, setting the terms of a productive working relationship. And it is a way of reducing risk and liability, while ensuring a high-quality end product. The RFP will include criteria for evaluating vendors—mandatory (“eliminatory” criteria) and non-mandatory (“optional” criteria). Optional criteria are a good way to include qualitative goals or values.
It is important for the RFP to reflect agile software development processes. It should describe a full software package that addresses the original problem statement, but also break the work into smaller, interoperable modules that can be contracted individually. Using a modular approach not only helps with continuous deployment and integration, but also reduces risk—if the vendor produces low-quality work, lags on time, or balloons over budget, you can easily bid subsequent modules to another vendor.