Especially when working with legacy systems, it’s important to test technical assumptions before scoping any kind of procurement because there are almost certainly unknown hazards that can put your procurement at risk. These hazards can’t be known unless you start building something.
Unlike most kinds of prototypes, technical prototypes are not focused on user experience, but rather on the mechanics behind the user’s experience. They test things like “Can we really access the data we think we need?”, or “How does this external API actually work?”—so they’re pretty bare-bones. They show just enough of the user-facing functionality to verify some kind of technical implementation. Practically, the prototype follows some user on a “happy path” user flow through that implementation.
Prototyping a small end-to-end user flow is something that teams can do quickly before writing an RFP, and should help identify any hazards in the code, the deployment process or any other technical aspect of a project. This will help teams properly scope the procurement and build out a reasonable RFP with some useful documentation for buyers and for vendors.
Our prototypes:
Throughout this project we will be using technical prototyping whenever we are faced with some question about integration with existing systems, the nature of existing data sources, or any other existing technical process that we plan to leverage as part of our planned acquisition. We may change direction at times, based on what we learn through prototyping. We may decide to pursue a completely different implementation, or even a different set of features entirely. Best case is that we can proceed with the original plan, only now with much more information that will help ensure the success of the acquisition.
Prototyping is learning. For us, it allows us to learn firsthand about the challenge before us so that we can take on the work from a more empowered position. Technical prototyping helps us:
| Reduce risk | Prototypes help us identify problems fast when the risk is far lower than when time is ticking with a vendor on board so that we can remove barriers to success early. |
| Validate direction | By testing out our intended vendor ask, we can validate if the planned work is viable. If it is, we can proceed. If the planned path proves unviable, we can more easily adjust course. |
| Understand business needs | By exploring a small end-to-end user flow, our product team surfaces and learns about business and policy needs, developing greater subject matter expertise. |
| Write a good RFP | The lessons learned through prototyping help inform the content of our requests for proposals, making the project focus sharper and less speculative. |
| Prepare vendors | Vendors benefit from the investigation by having more detailed and accurate information upon which to build their proposals. After award, they understand the landscape better and can jump right into the work. |
| Develop expertise | By actively working in system code to prove out hypotheses, we retain and grow in-house technical expertise with our systems and understanding of what vendor developers need to succeed. |
| Refine infrastructure | Technical prototyping creates opportunities to improve and refine our infrastructure. |
| Be transparent | By working in the open on our prototypes, we increase visibility for all our stakeholders and the larger Alaska community. |
Technical prototypes should address risks identified by the product team. The approach to using technical prototypes borrows heavily from the idea of a code spike in agile software development. Code spikes are not meant to produce production ready code, and should be designed to leverage the simplest possible solution to identify solutions to an outstanding question or potential risk. Technical prototypes. like code spikes, should help give the product team clarity on the level of efforts required to address risks that have been identified in the planning process.
Through our initial prototypes efforts, we worked through a variety of initial challenges. Having done so, we are now positioned to more easily and quickly prove out technical questions. We can now take advantage of…
Producing technical prototypes requires DOH developers and product managers to devote time and energy working in the systems and building. To do this, we leverage some or all of the following: