Before going full blown production with a Solution, there are times that you want to validate technical, functional, acceptance, or even general interest in a solution.
I find it helpful to clarify what the terms imply and what the primary focus is of each along with what impact on overall delivery risk it may have.
Overall, the ideal path to follow that helps mitigate risk, refine scope, and provide greater confidence in planning is:
PoC –> Prototype –> Pilot –> Production
This also helps both the delivery team and the customer make tollgate decisions as the project progresses.
Proof of Concept (Poc)
A prototype generally should be done early in the development cycle. It is used to validate technical feasibility, helps identify potential stumbling blocks, identifies what a platform can or can’t provide, helps determine the scope and level of customization necessary to complete the project.
The prototype can also help identify performance issues. Generally, today, we assemble many of our applications / solutions in a “composite” fashion. We’re re-using services, functions, etc. from other applications. This re-use requires integration points. It’s these integration points in our overall “context” that we’re vetting with the prototype effort. While also validating assumptions regarding what the platform or framework can or can’t provide.
The outcome is a technical feasibility confidence factor along with factors that impact overall scope and estimate of effort.
Prototype
A prototype, sometimes called “Proof of Concept Prototype” generally provides a more “complete” implementation allowing further examination on the feasibility of the solution, in my mind, from a functional perspective as it is “layered” on the technical solution. Hopefully, we’ve tactically created Skeletal PoCs to validate our technical approaches on key parts of our technical solution.
This is where the terms become juxtaposed. I’ve heard the inverse sometimes.
However, neither a PoC nor a Prototype should be considered production quality. These are solely for early determination of the feasibility of the technical or business solution.
Pilot
A Pilot is intended to be production quality – albeit on a smaller scale. Hopefully, we’ve completed any PoC and Prototypes to validate our approach, minimize risk, and help determine scope and effort.
The pilot is ultimately useful in getting real user feedback. Here, we pick-off a hopefully friendly group – if we’re gun shy, that can provide constructive feedback but also help mitigate risk. Doesn’t need to be a friendly group, if you’re looking for the fire, a more critical group could be the target, however, it may have a negative impact on the next tollgate decision on whether or not to proceed to full build-out and full production.
Posted on Monday, February 25, 2008 6:03 PM Architecture | Back to top
