Ask 18F is an advice column that answers questions sent in by federal employees. Our technical experts aim to provide you helpful resources and a good starting point to tackle your problem. Got a question? No matter how small the task or how big the project, email us at 18f@gsa.gov.
Dear 18F: What’s the difference between a Contracting Officer’s Representative and a Product Owner on agile software development projects?
Miatta Myers and Rebecca Refoy - Acquisitions
Uchenna Moka-Solana - Product
18F has helped agencies procure many contracts for software development services with modern and innovative acquisition techniques. Our partners often ask about the difference between the agile role of a product owner (PO) and the government role of a contracting officer’s representative (COR). Are they one in the same? Should they be the same person? What is a product owner? This post will help demystify the two roles and demonstrate the importance of both roles in modern software development in the federal space.
What is a COR?
In a traditional federal acquisition, the contracting officer’s representative (COR)[1] monitors the contractor’s performance, schedule, and spend rate. The COR works with the contractor to provide guidance and direction but can not modify the terms and conditions of the contract.
A person becomes a COR when a contracting officer (CO) “delegates” COR authority in writing. This is a formal process that is required by federal statute. Only government employees can be CORs, and they must receive a federal certification (i.e. FAC-COR or DAWIA) before being designated as a COR on contracts. Any contract can have a COR, but CORs are usually delegated for service contracts or contracts that exceed the simplified acquisition threshold. A COR is required for all contracts that are not firm-fixed price[2].
COR duties are typically assigned to people in addition to their full-time positions due to time and budget constraints. It is not uncommon for a person to be a COR on more than one contract. For larger contracts or contracts that have task orders, there may be more than one COR. When this occurs, there is a main COR and alternate CORs or one COR per task order . In general, COR duties are seen as auxiliary responsibilities to a government employee’s primary job.
Key COR duties include:
- Reviews and/or Approves Invoices: The COR may be one approver of many or the sole approver of vendor invoices. This depends on agency policy. The COR verifies the accuracy of the vendor’s invoice.
- Inspects Contract Deliverables: The COR verifies that all deliverables are in accordance with the quality assurance surveillance plan (QASP) and the terms and conditions of the contract.
- Serves as Technical Point of Contact for Vendor: The COR is the first-line point of contact between the vendor and the agency.
What is a PO?
A product owner is a key leadership role in agile software development that advocates for the business stakeholders and users to the software development team. The product owner must be empowered to make decisions in response to feedback from stakeholders and users to achieve the product vision. The product owner not only sets this vision, but explains how the product will meet users’ needs, align with the agency’s strategy, and fulfill the agency’s mission. The product vision is the guiding force that the product owner uses to establish priorities and direct the team’s work; the “north star” that drives the project. This vision needs to be constantly communicated to the team, the stakeholders, and anyone else involved in the project.
Key PO duties include:
- Own, Define and Communicate the Vision: Product owners should be impassioned about the vision for the product and have the ability to iterate on the vision based on feedback from stakeholders, team and customers.
- Own the Product Roadmap: Product owners develop plans that fuse business objectives with product strategy in order to identify technology solutions that meet both short and long-term goals.
- Develop Product Strategy: A successful product strategy breaks down the vision for a product over time and defines the market, offering, value proposition, distribution, and more.
- Make Decisions: The product owner makes decisions based on feedback from users, business objectives and priority of features. Not only does the PO make decisions, but they communicate to the team how these decisions were made.
- Communicate with Stakeholders, Development Teams, and the Scrum Master: The product owner relays status, educates stakeholders, organizes reviews, and performs solution demos.
How are they different?
Traditionally, a COR serves as the eyes and ears of the contracting officer and monitors the performance of the contractor team. In agile software contracts, the duties of the COR increase or decrease depending on the presence of a product owner[3].
A COR may also be the product owner or it may be a different person. Either way, both roles are essential to a successful vendor development team in the federal government. CORs may have other functional roles on the team, for example, product manager or developer, which give them more insight into the quality of work performed. At a minimum, the COR needs to know the quality of the development team’s work in order to officially accept contractor deliverables. Because the PO is empowered to make product decisions, the COR and PO (if they are different people) must work closely together to ensure delivery. The PO is the government’s decision maker and works with the contractor team lead to prioritize work, groom the product backlog, and other tasks. The PO serves as the liaison between the agency and the contractor team.
The table below gives an overview of the difference between a COR and a PO.
Why are they important?
For agile software projects, a close working relationship between the COR and the PO is essential, if the roles are performed by different people. If the COR and the PO do not collaborate on a regular basis, there will be miscommunication, vendor confusion, and ultimately a product that may not fit user needs. Agile software projects in the federal space should identify a PO and COR at the beginning of a project so that once a contractor is brought on, the PO and COR know what their roles are and have established how they will work together as they manage the work of the contractor team.
Through collaboration and division of responsibility, the PO can focus on making the best product possible, and the COR can focus on making sure the government is getting the best value for its money.