Proof of Concept (PoC)
How do we define a PoC?
A PoC is a test of an idea made by building a prototype of the application. It is an innovative,
scaled-down version of the system you intend to develop. In order to create a prototype, you
require tools, skills, knowledge, and design specifications.
What is the general usage of a PoC?
In software development, POC is often used to describe several distinct processes with different
objectives and participant roles:
 A PoC can refer to a partial solution that involves a relatively small number of users
acting in business roles to establish whether the system satisfies some aspect of the
requirements.
 A steel thread is a technical proof of concept that touches all of the technologies in a
solution.
 By contrast, the objective of a proof of technology is to determine the solution to some
technical problem, such as how two systems might be integrated or that a certain
throughput can be achieved with a given configuration. No business users need be
involved in a proof of technology.
 A pilot project refers to an initial roll out of a system into production, targeting a limited
scope of the intended final solution. The scope may be limited by the number of users
who can access the system, the business processes affected, the business partners
involved, or other restrictions as appropriate to the domain. The purpose of a pilot project
is to test, often in a production environment, whether the system is working as it was
designed while limiting business exposure.
A PoC provide business with checkpoints to determine the feasibility of technology choices and
specified functionality before the "go ahead" is provided for the overall project to commence. This
allows both the service provider and business an opportunity to confirm that the solution that is
being developed is in-line with their expectations.
What is the value of a PoC?




Requirements are not always fully understood before the project begins. By developing a
PoC for business you are forced to understand a large part of the requirements early on.
Users sometimes only know what they want after they see an initial version of the
software. Users are often disappointed with delivery, not only because the requirements
were misinterpreted, but also because they did not really know what they wanted until
they had seen the deliverable. After business reviewed the PoC, they have a better idea
of what they want the final deliverable to look and behave like.
New tools and technologies make implementation strategies unpredictable. Many of the
details that were needed during the design and development of software become known
only during the implementation stages. It has been shown consistently that design
mistakes that are found early in the software-development life cycle are cheaper to fix
than when they are detected later down the road. A PoC system provides you with
feedback and information not always known, which in turn provide you with the
opportunity to adjust design decisions well before the cost of backtracking became too
high.
Reduction in the overall risk of project failure.
What are the high level steps to follow during a PoC?









Define the purpose, goals, objectives, and scope of the PoC demonstration project.
Establish the success criteria for the PoC, with input from all stakeholders.
Outline the benefits of conducting a PoC and risks of not doing so.
Establish an administrative infrastructure to support and guide PoC project activities.
Determine whether preliminary decisions and assumptions made regarding hardware and
software performance, as well as service level required by technical staff, was accurate.
Develop functionality defined as part of PoC scope.
Assess hardware and software, system and database design, and procedures (for
training, scheduling, system management, and maintenance).
Test functionality.
Validate requirements and performance expectations.
What are general points to remember during a PoC?





It is important to keep in mind that a PoC is just a prototype and does not represent the
deliverable. PoC systems are usually developed quickly and without a lot of testing, they
therefore don't make good candidates for early versions of the final deliverable.
In cases in which the deliverable includes a user interface, the PoC is a façade that
illustrates the look and feel of the interface; but there is no functionality behind the
façade.
In cases in which the product is an application programming interface (API), the PoC
illustrates the methods and functionality that the API will provide; but the implementations
of the methods are simply stubs that will not perform real work.
When the PoC has served its purpose, it is best to throw it away and start with the
development of the deliverable. Developers must resist the urge to start development of
the final deliverable by enhancing the existing PoC, unless the reuse of code was
specified upfront.
The features that are implemented as part of the PoC should have the key features of the
project - especially, the parts of the system that have many unknowns or represent
increased risk. At the same time, components of the system that are repetitive
implementations of a given concept should be excluded. Implementation of a single
instance of a given concept in the PoC will provide all of the information that is needed to
match business expectations successfully.
What can go wrong during PoC projects?



Software development: The version of the software you selected may have been
promised in time for your PoC project, but the release has been delayed. Earlier versions
may not have the functionality your solution requires. The service provider may not
always be able to diagnose and fix software problems encountered during the PoC (or
devise workarounds for them) in a timely fashion.
Compatibility: In addition to the server and network architecture, you may need to install
software on participants' desktops. These installations may conflict with other software
loaded at individual workstations resulting in some individuals not being able to view the
full functionality of the software. Unanticipated costs (for new desktop hardware) may be
necessary.
Communications: Excessive communication with your project team and PoC participants
is preferable to not providing enough information concerning the progress being made.







Administration: Make sure that documentation is current. Always know the status of
tasks.
Costs: Make sure all tasks are on budget and that progress made matches costs
expended. Properly used, this can be the best early warning system for a developing
problem.
Training: Monitor the effectiveness of the training effort.
Schedule: Alert all participants concerning any changes to the schedule.
Productivity rates: Make sure that learning curves are established and sufficient user and
system support provided. Ensure that a system is in place for tracking productivity.
Politics: Be aware of changes in workload for areas of the business participating in the
PoC or changes in responsibilities for key personnel within the groups.
Outside influences: New technology and new regulations.
When should you be doing a PoC?
Business doesn’t always realize how powerful a PoC can be until they went through the
development cycle and the project failed or were delayed due to specific oversights or hidden
complexities. There generally exists many ways to approach a solution for a relevant business
area, at times it's good to think out of the box, challenge business and the development team.
When new technology is being used, complex functionality is required or business is not sure
what they want, a PoC is generally a good idea. This provides business and the development
team with the opportunity to ask questions, which ultimately lead to knowledge. It is important to
always define what business expects the result to be and why the functionality is needed, this will
assist in only doing a PoC when needed.
References




http://technologysource.org/extra/227/definition/5/
http://en.wikipedia.org/wiki/Proof_of_concept
http://msdn.microsoft.com/en-us/library/cc168618.aspx
http://www.archives.gov/records-mgmt/policy/pilot-guidance.html
Engela Doman
26/11/2011