Design

This phase is about setting up your OCDS implementation to be a success.

On this page, you will find guidance on how to:

  • Determine your priorities for data use

  • Set up your team

  • Build buy-in

  • Understand your context

  • Understand your key decisions and publication goals

  • Include OCDS in requirements for software developers and technical consultants

Note

Open contracting is about more than just implementing OCDS.

Visit the Open Contracting Partnership's website for help implementing wider open contracting reforms and for guidance on open contracting reform design and management.

Understand your context

How does public contracting work in your jurisdiction? What does the law oblige to be made public? What are the opportunities or barriers to greater openness? Which stakeholders ought to be involved? What institutional and technical skills and experience do stakeholders have?

The answers to these questions will help you to develop a robust publication plan. A scoping study can help your team to understand your political, legal, and technical context.

Resource: Methodology for Open Contracting Scoping Studies

If your contracting data is mostly on paper, in local spreadsheets or in unstructured electronic documents, and you don’t have the capacity to create a new IT system to collect data, consider reusing one of the existing tools for collecting OCDS data.

Set your goals and priorities

The most useful OCDS implementations are those that were designed around real-world goals and priorities. To achieve success, you need to understand your policy goals and user needs, and use them to inform the design of your OCDS implementation.

Identify stakeholders

Different stakeholders in your OCDS implementation can have different objectives. Journalists, civil society organizations, policymakers and auditors will all have different goals.

Consult stakeholders early in the design of your OCDS implementation to identify your key goals.

Resource: How to make sure open contracting data gets used: A guide to defining the use case

Action: Identify your stakeholders and their use cases.

Set goals

Common goals include:

  • Tracking and improving value for money in procurement

  • Measuring and increasing competition for contracts

  • Helping business understand what government buys and how

  • Promoting public integrity by monitoring for 'red flags' of corruption

  • Increasing participation of small, women-led, or minority-led businesses

  • Enhancing service delivery by tracking quality, delivery and milestones in contracts

Resource: How can OCDS help to assess the quality and performance of a procurement system? A step-by-step guide

Determine data needs

Each of the goals above have different data needs. These needs ought to inform your choices about how to implement OCDS, for example:

  • Which fields to publish

  • How often to publish or update data

  • Whether to publish a change history

  • What data formats and access methods to provide

Resource: Open Contracting Data Use Cases

Resource: Red Flags for Integrity Guide (red flags to OCDS mapping spreadsheet)

Resource: Indicators to diagnose the performance of a procurement market guide (procurement indicators to OCDS mapping spreadsheet)

Resource: How to calculate sustainable public procurement indicators with OCDS data

Action: Prioritize your goals based on the recommendations in the Technical Assessment Template.

Build your team

Implementing OCDS is easier when your team combines both policy and technology experience. Team members might be part of your own organization, or you might need to identify partners who can bring extra insights and skills.

To achieve success, an OCDS implementation team ought to include the following roles, though one individual might play several roles:

  • A project manager who will oversee the project timeline and deliverables.

  • A data expert who will identify where data put forward for publication in OCDS exists at a technical level. They need to be familiar with the IT systems that capture and store contracting data and related documents.

  • A procurement expert who will identify which procurement information matches which OCDS fields, at a semantic level. They need to be familiar with procurement legislation and procedures.

  • A policy champion who can help navigate the policy decisions of publishing and using OCDS data.

  • A system architect who will define the architecture for publishing OCDS data. They can be an internal team member or an external consultant.

  • A software developer, or developers, who will write the code for publishing OCDS data. They can be an internal team member or an external consultant. If you're updating an existing system, ideally the developer should be familiar with that system, or at least the relevant technologies, frameworks, and programming languages.

  • A user champion who will represent the needs of data users throughout the project. They can be an internal team member, an outside partner, or a representative of external stakeholders.

Action: Identify your team members.

Action: Ask everyone in your team to read the Primer.

Action: Contact the Data Support Team or complete this form to arrange an online introductory training for your technical team, in English or Spanish.

Action: Join the OCDS discussion group to keep up to date and engage with other implementers.

Writing OCDS requirements for eGP developers

If you will be hiring a team to develop or update an electronic government procurement (e-GP) system or open contracting data portal and wish to include the OCDS in the terms of reference, please refer to our Guide to Defining OCDS Functional Requirements for e-GP Systems, which includes functional requirements and template clauses that you can adapt for your technical specifications or procurement documents (terms of reference, request for proposals, etc.).

The World Bank Group's e-Procurement Toolkit offers additional advice and template requirements for procuring e-GP systems, and its Open Contracting Data Standard Implementation Methodology has guidance relevant to OCDS in e-GP systems from section 3.2.3 on page 27 onwards. (Note: Its earlier sections are based on OCDS 1.0.0.)

Resource: Guidebook: Crafting a Results-Driven Request for Proposals (RFP), by the Harvard Kennedy School Government Performance Lab

Resource: Contract Design Pattern Library, by World Commerce & Contracting – provides solutions to common usability and understandability problems in contracts, to help you organize and communicate your contracts more clearly, so that they are read, understood, and acted upon

Resource: What data should I collect? A guide to prioritizing data fields in an e-GP implementation

Next phase: Map