Learn how Proof of Concept, Statement of Work, Execution Plan, Design Review and pre-start gates validate the solution and readiness before implementation.
Check it out!
Proof of Concept (PoC) and Statement of Work (SOW) are different and complementary instruments. In an engineering contract, the PoC serves to demonstrate, through a test or objective assessment, that a proposed solution meets previously defined requirements. The Statement of Work, in turn, describes how the work will be performed: scope, boundaries, deliverables, responsibilities, methodology, team, schedule, controls, documents, tests and completion criteria.
The distinction is decisive because a procurement may prove that a supplier has experience and still need to validate specific aspects of the solution or mobilization. Qualification answers whether the bidder meets the capability requirements defined in the tender documents; the PoC may answer whether the offered solution demonstrates a given level of compliance; and an SOW or Execution Plan may answer how the contractor intends to organize execution of that specific contract.
Under Brazil’s Law No. 14,133/2021, proof of concept has an express legal basis: Article 17, paragraph 3, allows compliance analysis of the provisionally successful bidder’s proposal through samples, compliance examination and proof of concept, among other tests, provided these are established in the tender documents. The English term Statement of Work, however, does not constitute an autonomous stage of Brazilian public procurement. When a document with this function is required in a public contract, its obligation, content, timing and consequence must be anchored in the Terms of Reference, tender documents or contract, without becoming a retroactive qualification requirement.
The correct combination is powerful: PoC to demonstrate requirements that need to be tested; SOW or Execution Plan to turn the contract into a verifiable method, set of responsibilities and sequence before implementation. When these instruments are planned from the preparatory phase, they create a barrier between “company selected” and “execution released” without confusing competition, qualification, proposal compliance and contract management.
PoC and SOW answer different questions
The proof of concept tests a statement about the solution. The SOW organizes a statement about the work.
| Instrument | Main question | Typical stage | Expected result |
| Technical qualification | Does the bidder demonstrate capability according to the tender documents? | procurement | qualified/disqualified |
| Proof of Concept | Does the demonstrated solution meet the tested requirements? | proposal assessment, when established | compliant/noncompliant |
| Statement of Work | How will the work be performed and controlled? | contracting/mobilization, when established | document approved/revised |
| Execution Plan | How will resources, method, schedule and controls be mobilized? | pre-start | readiness to execute |
| Design Review | Is the technical detailing mature enough for construction/implementation? | pre-execution and by package | released/commented/rejected |
Mixing these roles creates legal and technical problems. A PoC should not be used to subjectively select the “best idea” when the tender documents established objective evaluation criteria. An SOW should not appear after qualification as an additional capability test that nobody knew they would have to meet.
When a Proof of Concept adds real value
A PoC is useful when a critical characteristic of the solution cannot be safely confirmed solely through declaratory documentation, a catalog or certification.
Examples may include, depending on the scope:
- interoperability between systems;
- ability to process a given volume;
- adherence to a specific functional requirement;
- compatibility with the existing environment;
- measurable performance in a defined scenario;
- execution of a critical workflow;
- reading, exporting or integrating data;
- demonstration of a security or control function;
- validation of an interface with legacy technology.
A PoC is not advisable simply because the contracting authority “wants to see it working.” The requirement must be relevant, testable and proportionate to the effort imposed on the bidder.
TCU guidance on samples and proof of concept reinforces that the requirement must be justified and supported by objective criteria. The test must assess what the tender documents defined, not preferences discovered during the session.
How to specify an objective PoC
A defensible PoC starts before the procurement, in the design of the requirements. The vaguer the specification, the greater the probability that the test becomes subjective.
A PoC matrix may contain:
| ID | Requirement | Test procedure | Input | Expected result | Evidence | Criterion |
| POC-01 | integration with protocol X | connect and run scenario | defined environment | successful communication | log + screen + file | pass/fail |
| POC-02 | minimum performance | run established load | standard dataset | value ≥ limit | exported report | pass/fail |
| POC-03 | export | generate file in required format | test data | valid file | native file | pass/fail |
| POC-04 | workflow | run functional sequence | action script | steps completed | execution record | pass/fail |
The script should also specify the environment, duration, responsibility for infrastructure, conditions for repetition, tolerances, failure handling, documentation and how results will be recorded.
When the assessment depends on human judgment, the criteria must be broken down into observable elements. Expressions such as “user-friendly interface,” “good performance” or “satisfactory integration” are insufficient without a scale or verification criterion.
PoC is not a commercial demonstration
A commercial demonstration and a proof of concept are not synonymous. A demo normally presents functions chosen by the supplier in an environment controlled by the supplier. A contractual PoC tests requirements chosen by the contracting authority, according to a known script and defined evidence.
This distinction avoids a common trap: the supplier giving a convincing presentation that does not test the critical conditions of the scope.
In the PoC, the contracting authority should control the question. The supplier demonstrates the answer.
Transparency and observability of the test
The procedure must be auditable. The TCU has precedents requiring detailed criteria and allowing interested parties to follow the assessment, subject to the rules of the procurement.
This means recording:
- date and environment;
- participants;
- product or solution version;
- requirements tested;
- procedure applied;
- input data;
- observed result;
- evidence generated;
- deviations and events;
- conclusion for each requirement;
- overall conclusion.
When the test produces a native file, preserving it may be more useful than an isolated PDF report. Logs, configuration files, exports, technical captures and hashes can strengthen traceability when the scope justifies this level of control.
Where the Statement of Work fits
Statement of Work is a term used in project management, contracts and procurement to describe the work to be performed. In Portuguese, its function may be distributed among scope, technical specification, work plan, execution plan, service order or equivalent documents.
The most important point is the function, not the language: turning a contractual obligation into a verifiable operational description.
A good SOW reduces gray areas by making explicit:
- work objective;
- scope boundaries;
- exclusions and assumptions;
- deliverables;
- packages and sequence;
- responsibilities;
- interfaces with the contracting authority and third parties;
- team and roles;
- methodology;
- schedule and milestones;
- documents and submittals;
- quality criteria;
- inspections and tests;
- change control;
- completion and handover criteria.
In public procurement, these elements cannot contradict or rewrite the scope after the bidding. The SOW should detail execution within the established obligations, not silently renegotiate what was procured.
SOW cannot become hidden qualification
This is probably the greatest risk of using the Statement of Work concept post-award.
Imagine tender documents that require only experience certificates and a minimum team. After qualification, the contracting authority requests an SOW and decides that it will reject the company if the methodology “does not demonstrate sufficient maturity,” even though no prior criteria exist. In practice, a new qualification barrier would have been created after the bidding.
The solution is to establish from the contracting stage:
- that the document will be required;
- its minimum content;
- when it will be submitted;
- how it will be reviewed;
- which items may generate comments or require revision;
- which conditions prevent the Notice to Proceed;
- which aspects are planning matters only and do not modify scope;
- how differences will be resolved.
In this way, the document functions as a contract-management instrument, not an improvised filter.
From the SOW to the Execution Plan
In implementation contracts, the SOW often needs to be supplemented by a more operational Execution Plan. The former establishes what will be done and how the work is structured; the latter can detail actual mobilization, work fronts, resources, methods and controls.
A practical structure may contain:
Scope and WBS
The WBS breaks the contract into controllable parts and creates a link with schedule, measurement and deliverables.
Organization and RACI
The RACI matrix or equivalent identifies who performs, is accountable, is consulted and is informed for critical decisions.
Schedule and milestones
The schedule must reflect execution logic, dependencies, constraints, approvals, procurement, tests and handover — not merely start and finish dates.
Materials and submittals
Critical items should have a datasheet, equivalence requirement, review workflow and approval deadline compatible with the schedule.
QA/QC
The quality plan and ITP/PIT should define inspections, criteria and witness points.
Document management
The deliverables matrix must establish progressive documents, revisions and their relationship with measurement and acceptance.
Testing and commissioning
Tests must be planned from the beginning, with prerequisites, instruments, evidence and criteria.
Handover
As-Built, Data Book, manuals, warranties and training should not appear as “final pending items”; they need to be planned from mobilization onward.
The Terms of Reference must prepare the ground
PoC, SOW, acceptance criteria and gates only work when designed in the preparatory phase and clearly stated in the procurement documents.
Technical review of the Terms of Reference makes it possible to separate qualification requirements, proposal requirements, compliance testing and execution obligations.
If the organization intends to use PoC, SOW or a pre-start gate, the design begins in the Terms of Reference for Public Works and Engineering Services.
Brazil’s Law No. 14,133/2021 includes in the ToR content elements such as contracting requirements, execution model, contract-management model, measurement and payment criteria and supplier-selection method. This makes it possible to build a coherent journey between requirement, assessment and execution.
The ToR needs to distinguish:
- scope requirement;
- evidence required in the proposal;
- qualification evidence;
- requirement tested in the PoC;
- document required after contracting;
- pre-Notice-to-Proceed condition;
- execution evidence;
- measurement criterion;
- acceptance criterion.
This separation reduces the chance that the same requirement will be demanded in different and contradictory ways throughout the process.
Design Review as a third layer
Passing a PoC does not mean the detailed design is mature. Interfaces, constructability, materials, details and test criteria need to be verified before each package is released.
Design Review reduces the cost of correcting incompatibilities after they have already been incorporated in the field.
PoC demonstrates a characteristic of the solution; SOW organizes the work; neither replaces review of the detailed design.
When implementation depends on detailed design, shop drawings or details produced by the contractor, Design Review addresses interfaces, requirements, compatibility, constructability and maturity before execution.
A typical sequence may be:
- requirements defined in the design/ToR;
- proposal assessed;
- PoC applied to testable requirements, when applicable;
- contract formalized;
- SOW/Execution Plan submitted;
- detailed design and submittals reviewed;
- critical pending items closed;
- Notice to Proceed or package release.
This logic creates independent barriers. A solution can pass the PoC and still have an inadequate design detail. An excellent design can fail if the Execution Plan does not provide coherent resources or sequencing. Each instrument verifies a different dimension.
Project Controls turns the plan into a baseline
An SOW without a baseline becomes only an approved document. WBS, schedule, milestones and deliverables need to feed a control system that shows planned, actual, variance and forecast.
Project Controls turns the plan into a measurable reference for execution.
Approving an SOW without creating a control reference reduces its value. The document needs to connect to the schedule and indicators that will be monitored.
Project Management and Project Controls can turn WBS, milestones, schedule and costs into a baseline. Changes and deviations are then assessed against that reference.
The link can be structured as follows:
| SOW element | Associated control |
| deliverable | WBS + milestone |
| team | mobilization plan |
| critical material | procurement/submittal schedule |
| method | approved procedure |
| interface | action/RFI register |
| inspection | ITP/PIT |
| document | MDR |
| test | commissioning schedule |
| handover | closeout checklist |
This prevents the SOW from being approved and then filed away without an operational function.
Release criteria: the gate must be explicit
A pre-start gate or package-release gate works when there is an objective set of conditions.
Example for an installation work front:
- design released for construction;
- material approved and available;
- area released;
- team authorized;
- method approved;
- safety prerequisites met;
- hold points identified;
- applicable documents at the correct revision;
- interfaces resolved;
- evidence that the subsequent activity can be inspected/tested.
The gate can release the entire project or only a package. In complex projects, package-based release makes it possible to maintain pace without sacrificing maturity control.
The proof of concept must also be designed to avoid risk cannibalization
A less obvious mistake occurs when the organization uses the PoC to test many irrelevant things and fails to test the requirement that actually determines implementation success.
Scenario selection should start from the risk matrix. Ask:
- which requirement has the greatest impact if it fails?
- which characteristic is difficult to prove through documents?
- which incompatibility would have a high cost after contracting?
- which scenario differentiates a compliant solution from one that is merely declared compliant?
- which test can be performed objectively and proportionately?
The objective is not to maximize the number of tests. It is to maximize useful information for the decision.
How to handle failure, adjustment and repetition in the PoC
The tender documents should establish how events will be handled. Not every failure has the same nature.
There may be:
- a configuration error that can be corrected within the procedure;
- failure of the environment supplied by the contracting authority;
- a requirement not met by the solution;
- external interruption;
- an inconsistency in the script;
- an inconclusive result.
Without a prior rule, each event becomes a discussion about correction opportunities, equal treatment and results.
The script needs to define whether repetition is allowed, under what conditions and with what record. The decision should not depend on improvisation during the test.
Technical audit when the process has already started without these barriers
It is not always possible to return to the preparatory phase. A contract may already be signed, with execution underway and doubts about documentation, solution, progress or compliance with the design.
In this situation, it is not appropriate to invent a retroactive PoC to create a qualification effect. The alternative is to establish the actual situation through an Engineering Technical Audit, inspections, document analysis, independent testing and a pending-items matrix.
The audit can reconstruct:
- applicable baseline;
- design status;
- execution status;
- documents received;
- nonconformities;
- existing tests;
- evidence gaps;
- risks to continuity;
- action plan.
The principle remains the same: use mechanisms that are valid for the stage the contract is actually in.
An integrated architecture for PoC, SOW and execution
The architecture shows that PoC and SOW are not substitutes. The PoC belongs to the demonstration of compliance at the established stage. The SOW and Execution Plan belong to the organization of the contracted work. Design Review verifies the maturity of detailing. The gate confirms readiness. Inspection and commissioning verify execution and the result.
How to procure support to structure these layers
For complex scopes, developing the criteria requires different competencies: design, procurement, public procurement, risk management, planning, QA/QC and knowledge of the system to be implemented.
Technical support may cover:
- requirements review;
- proposal compliance matrix;
- PoC criteria design;
- test script and matrix;
- technical support for the evaluation session;
- preparation/review of SOW and Execution Plan;
- Design Review;
- WBS and baseline structuring;
- submittal matrix;
- ITP/PIT;
- gate and release criteria;
- inspection and Owner’s Engineering.
Consulting engineering does not replace the public agent responsible for the decision. Its role is to produce method, evidence and technical recommendations so that the authority can decide with better information.
Final considerations
Proof of Concept and Statement of Work solve different problems and should remain distinct.
The PoC is a tool for objective confirmation of the solution when a relevant requirement needs to be demonstrated and the tender documents establish its use. The SOW is an instrument for operational definition of the work and, together with the Execution Plan, transforms contractual obligations into method, resources, deliverables, controls and verifiable criteria.
The greatest benefit appears when these instruments form part of a larger architecture: mature requirements in the ToR, appropriate qualification, objective PoC, clear contract, SOW, Execution Plan, Design Review, baseline, pre-start gate, evidence-based inspection, testing and acceptance.
The purpose is not to multiply documents. It is to create independent layers of protection, each answering a specific question before the project moves to a stage where correction becomes more expensive, slower or more contentious.
When the contract is already underway and the barriers were not structured from the beginning, the answer is not to create a retroactive PoC or a new qualification stage.
Technical Audit establishes the baseline, evidence, nonconformities, document gaps and action plan to recover governance.
Technical references
[1] BRAZIL. Law No. 14,133 of April 1, 2021 — Public Procurement and Administrative Contracts Law. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] BRAZILIAN FEDERAL COURT OF ACCOUNTS. Procurement & Contracts — Samples and proof of concept. Available at: https://licitacoesecontratos.tcu.gov.br/5-4-1-2-amostra-e-prova-de-conceito/.
[3] OFFICE OF THE ATTORNEY GENERAL OF BRAZIL. Models under Law No. 14,133/2021 — Pregão and Competitive Tendering. Available at: https://www.gov.br/agu/pt-br/composicao/cgu/cgu/modelos/licitacoesecontratos/14133/pregao-e-concorrencia.
Frequently asked questions
A PoC objectively tests whether a solution meets defined requirements. A Statement of Work describes the work to be performed, including scope, deliverables, responsibilities, method, team, schedule, controls and completion criteria.
Yes. Article 17, paragraph 3, allows proof of concept and other compliance examinations of the provisionally successful bidder’s proposal, provided they are established in the tender documents.
No. SOW is a project- and contract-management practice. In public procurement, any document with this function must be anchored in the ToR, tender documents or contract and cannot create retroactive qualification.
The procurement design must comply with the law, tender documents and applicable case law. The TCU recommends caution and generally directs the proof of concept to the provisionally successful bidder, avoiding unnecessary restrictions on competition.
Objective, scope and exclusions, deliverables, WBS, responsibilities, team, methodology, schedule, materials and submittals, QA/QC, documents, tests, changes, handover and completion criteria.
No. The PoC verifies solution requirements at the established stage; Design Review verifies the maturity of technical detailing; commissioning verifies performance and readiness of the implemented asset.
Supplementary technical materials
Related solutions
- Requirements, Evidence and Acceptance Criteria Management
- Contract, Scope and Deliverables Management
- Document Governance and Document Management System
Related services
- Terms of Reference for Public Works and Engineering Services
- Technical Procurement Support and Proposal Analysis
- Engineering Design Review
- Project Management — Project Controls
- Engineering Technical Audit
Main content on the topic
- Can pregão be used for public works?
- Technical Qualification in Engineering Procurement
- Engineering Design Review
- Inspection and Test Plan — ITP/PIT
