1. Orientation
2a. Planning phase
![Vector](img/vector-38@2x.png)
![Vector](img/vector-39@2x.png)
![Vector](img/vector-40@2x.png)
![Group 2](img/group-2-10@2x.png)
![Union](img/union-64@2x.png)
![Rectangle](img/rectangle-6@2x.png)
![Rectangle](img/rectangle-7@2x.png)
![Ellipse](img/ellipse-21@2x.png)
![Ellipse](img/ellipse-22@2x.png)
![Ellipse](img/ellipse-23@2x.png)
![Vector](img/vector-41@2x.png)
![Group](img/group-7@2x.png)
![Vector](img/vector-42@2x.png)
![Group](img/group-8@2x.png)
![symbol-dev](img/symbol-dev-12@2x.png)
![symbol-dev](img/symbol-dev-13@2x.png)
![Vector 3](img/vector-3-4@2x.png)
![Vector 5](img/vector-5-3@2x.png)
![Vector 4](img/vector-4-4@2x.png)
![Union](img/union-65@2x.png)
![Group 2](img/group-2-11@2x.png)
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.