A proof of concept is the implementation of a small subset of the whole system to prove implementing the whole thing is possible.
Many projects don’t take advantage of the power of proof of concepts to identify ideas that won’t work or will prove impractical to implement. Too many projects find problems too late in development and due to the invested effort they are forced to continue until their eventual failure.
Make sure your proof of concept is good enough and is the real thing. Good proof of concepts implement a thin slice through the whole anticipated architecture covering all areas so as to identify any flaws or limitations. The thin slice should be the real thing in as much as it interfaces with the same things, it’s built to the same standards and same way as the final system. This means it also tests the real practicality of implementing. It also ensures there’s less waste. What has been created can be re-used and built on sideways to add more slices to create the final system. If you otherwise create a compromised, throwaway proof of concept you will usually have pressure from stakeholders to include your poor implementation in the real thing.
Good candidates for functionality for proof of concepts are specific usecases, scenarios or user stories. For example, implement a whole usecase including the user interface, middleware, and server side to get a good feel for feasibility. Choose specific usecases to exercise what you think might be the most difficult or unknown parts of the system.
Proof of concepts can give a feel for the development effort that will be required to develop the complete system thus giving an indication of the project’s cost and the financial viability of the project.
It’s also possible to create proof of concepts that include business goals. Think ‘proof of value’ rather than ‘proof of concept’. Proving a project has value to stakeholders can help unlock realistic funding for development of the complete project.