I have worked on many software development projects where I was asked to do a technical review. During the review, I would find holes in their technical architecture. For example, the security model was not fully built out or the business continuity plan was not defined. When I would raise these issues the development team would respond it was ok because they were just doing a proof of concept (POC) and those items would eventually get buttoned up. I asked if their customer base knew and understood what that meant. This is where the confusion would arise. The customer’s expectations were not clearly defined and this could cause real issues as the team moved forward.
In one project I worked on different team members said the project was a proof of concept, a proof of value (POV), a pilot, and a minimum viable product (MVP). But none had a common definition of what these labels meant. The customers were unaware that if the servers were restarted they may lose data and that none of their data was being backed up. The team had failed to define the stage they were in based on the customer’s expectations.
To address this concern I developed a framework that I think helps. It defines a common stage gate process if you will. It is not meant to be a rigid set of rules but rather a way to make sure everyone included in the project is aware of that state and what the expectations should be.
The framework moves from left to right and as it does the importance of having key items like capabilities, resources, and the scope well defined becomes increasingly important. I use the framework with my solution design process to generate the needed artifacts to support the stages.
The Five Steps
Ideation
In this stage, we are merely trying things out. We are looking to establish technology positions and understand what it would take to use the solution on a larger scale. Typically we are focused on a specific architectural domain area like information architecture, or security models. The work from this stage should produce white papers and position papers and help establish approach notes and decision documents to help design larger project efforts.
The scope is in a sandbox and focused on targeted key learnings. It may consist of conference room demos or local installations with limited access. There is no real production value expected. No security impacts should be expected and obfuscated data should be used if needed. The user count is very limited most times to one or two users.
Proof of Concept
If we see value in the Ideation stage we may move to a POC. Here we move out of the sandbox mode. We want to validate how the approach works in the larger context of the Enterprise. How will work with our reference architecture models? These areas are documented and used to support the next stage.
We are broadening the scope and want to validate domain-specific capabilities. Will the POC work with our security models, network capacity, or integration patterns for example? We are starting to bring in defined business value to ensure we have alignment. Little focus is placed on implementation or support concerns from a production point of view. There is a very limited user count and all users are aware of the POC limitations and expectations.
Proof of Value
I have not seen POV used a lot but I believe it can benefit solution design processes to be more successful. Here we are starting to harden down production requirements. Our user experience becomes more important and traceability to business value is being captured and validated. Does the proposed solution give us the needed value we have designed in the product plan or project charter? Can we move to a Pilot stage and begin the development of an MVP?
The scope has become broad now and should closely mirror what a production deployment will look like. All key domain areas have been documented and accounted for. Gaps are understood and efforts are planned to close the gaps. We may start to see real data being used and the user count will rise as we move close to a production design.
Pilot
You could consider the Pilot stage the delivery of the Minimum Viable Product concept from Lean Startup. It might not have all of the requirements but it is viable. This means it functions as intended and can deliver the defined business value. Production data is being used. While the user count may be controlled user expectations should closely match the production release. While gaps may still exist, they are well-defined and plans have been validated to close them.
For example, we know we will use the company’s identity system for user access and control but for the Pilot, we will use local accounts and manage access at that scope. Users may be informed that data could be lost so use the system with caution. A critical outcome of this stage is a go or no-go decision to production. Are we ready to close all of the gaps and scale the solution to the expected user base?
Production
This is the complete system with all gaps closed. New features may still be added in the future but the solution has been deployed and can deliver the needed business value at scale. All architectural domain areas have been addressed.
Conclusion
It might seem like common sense but having a framework similar to this can help organizations have a shared understanding of where a solution design is. It takes on more impact if we tell the users this is a POV or Pilot. They know what the expectations of completeness are and become better contributors to the success of the ultimate solution design process.
