Proof of Concept Template (Free, Word): Software POC Plan

1. Purpose and why a POC

Buyer instructions: replace every [bracketed placeholder], delete
anything that doesn’t apply, and delete all italic guidance before you
send this plan. Sections 1 to 9 are the POC plan: make one copy per
finalist, with identical success criteria and scenarios, and have both
sides sign Section 9 before any work starts. Sections 10 to 13 are for
your evaluation team only, so delete them from every vendor’s
copy.

1.1 Purpose

[Organization name] (“we”, “us”) is selecting [type of software]
through [RFP number]. [Vendor name] (“the vendor”) is one of [two /
three] finalists. This proof of concept (POC) tests whether [product]
meets the requirements in Section 1.2 when our own staff use it with our
data, in the environment in Section 5, over the period in Section 7.

The results will update our evaluation of the vendor’s proposal. This
POC does not commit us to buy [product], or either party to enter into a
contract. [The confidentiality terms in the RFP / The non-disclosure
agreement dated [date]] apply to everything shared during the POC.

1.2 Requirements a demo
couldn’t prove

List only requirements that matter to the decision and that a
scripted demo, a reference call or a document can’t settle, such as
integrations, performance at your volumes, loading your real data, or
configuration by your own staff.

2. Scope

2.1 Use cases in scope

• [UC-1, e.g. A sales rep creates an account and order that flow to
  [ERP]]
• [UC-2, e.g. A sales manager runs the pipeline report for all
  regions]
• [UC-3, e.g. An administrator sets up the discount approval
  workflow]

2.2 In scope

• Product: [modules and features]
• Integrations: test connections to [test instances of systems]
  only
• Data: the data sets in Section 5.2
• Users: up to [number] named test users in these roles: [roles]
• Configuration: the vendor configures [list]; our administrators
  configure [list]

2.3 Out of scope

• Production systems and live data, unless Section 5.2 says
  otherwise
• Full data migration beyond the samples in Section 5.2
• Custom development, unless agreed in writing under Section 2.4
• [Training beyond what testers need]
• [Other exclusions]

2.4 Ground rules

• The vendor uses the product and edition priced in its proposal.
• If a scenario needs custom code, a third-party product or an
  unreleased feature, the vendor tells our POC lead before building it. We
  record it in the results log (Section 4.3), and it can affect the
  evaluation and the price.
• Our testers carry out the scenario steps wherever possible. The
  vendor can guide them but doesn’t operate the product during recorded
  tests.
• Changes to the scope, criteria or schedule need written agreement
  from both POC leads, and we make any change to a criterion or scenario
  for every finalist.

3. Success criteria

Use the same criteria for every finalist, and set every pass
threshold before the POC starts. Must: a vendor that fails it fails the
POC. Nice: it adds to the score.

A must-have criterion not met by the end of the retest window
(Section 7) is a fail, and a partial result counts as not met.

4. Test scenarios and results
log

4.1 How the tests run

Base each scenario on one of your hardest real processes, as you
did for the demo script.

• Each scenario is run [once as a dry run, then once for the
  record].
• Testers record each result in Section 4.3 on the day, with evidence
  such as screenshots, timings, logs or reconciliation reports.
• The vendor can fix logged issues during the retest window in Section
  7. Each retest is a new row in the results log.

4.2 Scenarios

4.3 Results log

Complete this during the POC. Share a vendor’s log only with that
vendor, to confirm the facts. “How achieved” uses the RFP’s response
codes; an unreleased feature counts as not met.

5. Environment and data
handling

5.1 Test environment

5.2 Test data

Use the least data that will prove the criteria. Prefer generated
data, or real data with personal and confidential details
masked.

• Real, unmasked personal data is used only if [our data protection
  lead / security team] approves it in writing before the POC starts.
• [Payment card data, health records or other regulated data] must not
  be used in the POC.
• We transfer data by [secure file transfer method], not by
  email.
• Only the vendor staff named in Section 6 can access our data.
• Within [number] days after the POC ends, the vendor deletes our data
  from the POC environment and all copies, [including backups / with
  backups expiring within [number] days], and confirms in writing.

If real personal data is involved, ask your privacy or legal team
whether you need a data processing agreement or other terms before the
POC starts. Requirements vary by country and sector.

5.3 Security

• Before access is granted, the vendor provides [security
  documentation, such as a SOC 2 report or ISO/IEC 27001 certificate, and
  our completed security questionnaire], and our security team approves
  the environment.
• The vendor tells our POC lead about any security incident affecting
  the POC environment or our data within [number] hours of learning of
  it.
• Every tester has their own account. Accounts and passwords aren’t
  shared.

5.4 Who provides what

6. Roles and responsibilities

All communication about the POC, including commercial questions, goes
through the two POC leads. The contact rules in the RFP still apply.

Ask the vendor to staff the POC with people who would work on
your implementation, where possible.

7. Schedule

An example only: about a week of preparation, then three weeks
from kickoff to decision. Adjust it to your scope, allow more time if
test integrations have to be built, and give every finalist the same
length of time.

8. Costs and who pays

Whether vendors charge for a POC varies. Agree every cost below
in writing before the POC starts, and budget for your own: testers’
time, data preparation, the security review and test connections on your
side.

• Any POC fee covers only the work in this plan, and nothing more is
  chargeable without our POC lead’s written approval.
• [If we sign a contract for [product] by [date], the POC fee is
  credited against [first-year subscription / implementation] fees.]
• The POC does not commit us to buy. Test licenses end on [date] and
  do not convert to a paid subscription.
• [Configuration, scripts and documents created during the POC belong
  to [us / the vendor]. The vendor [may / may not] reuse them in an
  implementation for us.]
• Apart from the items above, each party bears its own costs.

Public-sector buyers: check with your procurement office before
accepting a POC at no charge or paying for one, and offer every finalist
the same terms.

9. Plan sign-off

By signing, both parties agree to the scope, success criteria, test
scenarios, data handling, roles, schedule and costs in Sections 1 to 8.
This plan does not commit either party to a contract for [product].

Have legal review the plan before signing if the POC is charged,
uses real personal data or connects to your systems.

10. Evaluation and scoring
(internal)

Internal: delete Sections 10 to 13 from every copy you send to a
vendor.

The POC doesn’t replace the RFP evaluation. Its results update the
scores for the RFP criteria it tested, at the weights set before
proposals arrived. Before the POC starts, decide which RFP criteria each
POC criterion informs.

10.1 Scoring the POC criteria

• Must-have criteria: Pass or Fail. A Fail at the end of the retest
  window means no-go for this vendor (Section 12).
• Nice-to-have criteria: score each from 1 to 5 using the scale below.
  Each evaluator scores independently, then the group agrees one score and
  records the reason.

Edit the definitions to suit, before the POC starts.

10.2 Updating the RFP scores

The weights shown are an example only. Use the weights from your
RFP, unchanged.

Recalculate each finalist’s weighted total the same way you did for
the proposals. If a scenario passed only with custom work or a
third-party product, get the vendor’s written price for it and add it to
the cost comparison before you rescore cost.

11. Comparing
finalists side by side (internal)

Use this when two or three finalists take part, each with the
same plan, scenarios, data and length of time, run as close together as
you can. If your testers can’t give that time two or three times over,
test the leading one or two finalists and keep the others in the process
until you decide.

• Never tell one vendor how another performed, or share its
  approach.
• Give every vendor the same tester time and the same retest
  window.
• Record anything that made the tests unequal, such as an outage in
  one of our test systems, and agree how to treat it before scoring.

12. Go/no-go
decision and next steps (internal)

12.1 Decision rules

Set these before the POC starts.

• Go: every must-have criterion passed, and the
  vendor ranks first on the updated RFP weighted total.
• Conditional go: every must-have criterion passed,
  but [named issues] remain. Go ahead only if the vendor commits in the
  contract to fix them by [date].
• No-go: any must-have criterion failed at the end of
  the retest window, or [other condition, e.g. custom work found during
  the POC takes the total cost over budget].

12.2 Decision record

12.3 Next steps

After a go:

• Finish any outstanding reference checks, then negotiate. If your
  rules allow it, keep the runner-up in the process until the contract is
  signed.
• Write what the POC proved into the contract and statement of work:
  the integration approach tested, the performance results as acceptance
  criteria, and any fixes the vendor committed to.
• Give the delivery team this plan, the results log and the decision
  record.

After a no-go:

• Move to the next-ranked finalist, or, if no finalist passed, revisit
  the requirements and budget with the sponsor.

In every case:

• When you award the contract, tell every finalist the outcome, and
  offer the unsuccessful ones a debrief.
• Get written confirmation from every vendor that test access is
  removed and your data is deleted (Section 5.2).
• Keep the plans, results logs, scores and decisions with the
  selection file.

13. Decision sign-off
(internal)

We confirm that the results in Section 4.3 and the scores in Sections
10 and 11 are accurate, and we approve the decision in Section 12.