# Project planning ### 1. Introduction “Failing to prepare is preparing to fail.” Before configuring OpenCRVS for a country, it is important to plan the overall digital transformation journey. Pre‑configuration activities help to: * Build shared understanding of goals and constraints. * Align stakeholders around a realistic implementation roadmap. * Reduce rework during configuration by clarifying priorities early. * Identify risks, dependencies, and data considerations in advance. These activities sit **before** full configuration and pilot work, and make later phases faster and more effective. *** ### 2. Implementation phases A typical OpenCRVS programme is organised into three main implementation phases, plus a pre‑transformation phase that can secure buy‑in and super‑charge business analysis. 1. **Proof of Concept (PoC)** – configure the core product with basic country inputs to prove OpenCRVS’ applicability and identify additional requirements. 2. **Pilot** – test OpenCRVS in a range of real‑world settings to prove that it works, improve the configuration, and refine a scalable, integrated rollout plan. 3. **Scale‑up** – expand digital services across the country using the integrated components tested in the pilot. 4. **Operational support** – manage and maintain the solution for the long term, including regular product upgrades and hot fixes. Pre‑configuration activities prepare the country to move through these phases efficiently. *** ### 3. Proof of Concept (PoC) OpenCRVS can be quickly configured to meet the basic civil registration needs of a country. A **Proof of Concept** uses this capability to test the product and learn more about specific business needs and system requirements before committing to full implementation. #### 3.1 What a PoC is * A quick way to see how OpenCRVS can enable digital CRVS in your country. * Use of existing functionality in the core product, applied to country‑specific data and workflows. * An opportunity to learn what works and what does not, and to identify additional system requirements. * Small‑scale field‑testing to gather user feedback and better understand requirements. * A way to inform the development of a long‑term digitisation and investment strategy. #### 3.2 What a PoC is not * Not a full requirements‑gathering process (that happens once the country confirms it wants to use OpenCRVS). * Not customisation of OpenCRVS with new features; no new functionality is built during the PoC. * Not live registration of vital events; only mock data is used, so data sovereignty questions (such as in‑country hosting) do not affect the exercise. #### 3.3 Outputs of a PoC A typical PoC produces: 1. **Configured OpenCRVS instance** – a basic configuration for the country, hosted in the cloud. 2. **Analysis document** – including “as‑is” and “to‑be” process maps for key workflows. 3. **Requirements backlog** – a structured list of requirements identified during analysis that can be used for subsequent work (this is the start of a backlog, not a complete one). 4. **Pilot plan** – a high‑level plan for piloting the solution to inform a national‑scale CRVS digitisation effort. These outputs feed directly into more detailed configuration and pilot planning. *** ### 4. Pilot A **pilot** is a small‑scale, real‑world implementation used to test feasibility, viability, and effectiveness before full‑scale roll‑out. The purpose of a pilot is to **learn and inform scale‑up plans**, not to deliver a final, nationwide solution. #### 4.1 Why pilot * Validate that OpenCRVS works in different environments (urban, rural, health facilities, stand‑alone offices). * Refine configuration (forms, workflows, roles, workqueues, communications) based on real usage. * Test integrations with other systems (for example, health or ID systems) in a controlled way. * Identify training, change‑management, and support needs for national roll‑out. #### 4.2 Integrated pilot workstreams A successful pilot is an **integrated programme**, not just a technology exercise. Typical workstreams include: * **Business analysis** – refine business and system requirements to help the country achieve its CRVS objectives. * **Product configuration & testing** – design, configure, and test the country instance of OpenCRVS against agreed requirements. * **Change management** – design and deliver activities that secure buy‑in from leadership and staff, and support behavioural change. * **Training** – develop and implement scalable training that equips users to work effectively with OpenCRVS. * **Monitoring & evaluation** – define key performance indicators (KPIs) and a continuous improvement approach that uses data from the pilot to adjust product, service design, and deployment. * **Operational support** – establish tier 0–4 support (self‑help, helpdesk, technical support, vendor support) so services remain operational during the pilot. Findings from these workstreams directly shape the design of the national scale‑up. *** ### 5. Establish project and team OpenCRVS is designed to minimise technical effort for setup and configuration, but a small, well‑structured team is still essential for a successful implementation. At a minimum, countries should identify **two core roles**: * **Technical System Administrator** – responsible for installing, running, and maintaining the OpenCRVS infrastructure * **Business Analyst / National System Administrator** – responsible for configuring application details, forms, workflows, and vital event certificates For a full digitisation programme, additional skills are usually required, including designers, developers, QA engineers, and programme roles such as change management, training, deployment, and monitoring & evaluation leads. For detailed guidance on roles, skills, and team composition, see [Establish project & team](/v2.0/implementation/your-opencrvs/establish-project-and-team.md) *** ### 6. Pre‑configuration checklist Before starting detailed OpenCRVS configuration, countries should consider: * **Vision and scope** – which event types, geographies, and service channels will be included in the PoC or pilot. * **Governance and ownership** – who is responsible for decision‑making, sign‑off, and day‑to‑day coordination. * **Data and integration landscape** – existing systems (for example, health, ID), data standards, and integration priorities. * **Change readiness** – current processes, capacity, and any legal or policy changes required to support digital CRVS. * **Resource planning** – availability of business analysts, implementers, trainers, and support staff to run the programme. Clarifying these elements early helps ensure that subsequent configuration work across Events, Records, Workflows, Access, and Aggregate Data modules is grounded in a realistic, well‑understood plan. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.opencrvs.org/v2.0/implementation/your-opencrvs/project-planning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.