Every project plan I've seen for a national system has a neat Gantt chart. Almost none of them have a bar labelled "waiting for parliament".
That's usually where the time goes.
The short answer: a CRVS or DPG pilot can go live in about three months. A full national implementation typically takes six to 12 months. The software is rarely the constraint. Legislation, procurement and political decisions are, and they can add years if the groundwork isn't done in parallel.
Key facts:
- Publishing a new DPI standard can take as little as 3 to 4 weeks (CDPI)
- A "conversion" DPI building block on existing systems typically takes around six months, and extending it to more use cases around 12 (CDPI)
- OpenCRVS's Bangladesh pilot ran for 12 months across two locations to prove the model (UN ESCAP)
Typical timelines
| Phase | Typical duration | What drives it |
|---|---|---|
| Scoping and design | Weeks, not months, if the use case is clear | Stakeholder alignment |
| Pilot to go-live | About 3 months | Configuration, training, one integration |
| Pilot period | Often 6 to 12 months | Proving the model before scaling |
| National implementation | 6 to 12 months | Number of districts, integrations, training |
| Legislation changes | Can add years | Parliamentary timetables, politics |
| Historical records | Often longer than the rollout | Volume and condition of paper archives |
Why DPGs are faster than building from scratch
With a digital public good, you start from a tested, deployed product. The work is configuration and integration, not writing software from nothing.
That's the speed-to-market advantage I keep coming back to. A bespoke build spends its first year on things a DPG already has: user management, security, audit trails, certificates, reporting. You get to spend that year on what's actually specific to your country.
What actually slows projects down
- Legislation. If the law doesn't allow digital registration or digital certificates, nothing goes live until it does. That lag can be years.
- Procurement. Tender processes not designed for open source can add months before any work starts.
- Decisions. Which ministry owns what, who approves the certificate design, which district goes first. Every open decision is a delay.
- Integrations. Each connected system brings its own team, timetable and priorities.
- Hosting. Waiting for government hardware, network access or VPN set-up is a classic hidden delay.
My take: start the legal review and the hosting set-up on day one, in parallel with everything else. They're the two things that most often sit on the critical path unnoticed.
How to keep a rollout on time
- Scope the first release tightly: a few life events, a few districts, one integration
- Get a named decision-maker for each open question
- Treat historical records as a separate workstream (see digitising historical records)
- Train as you go, district by district
- Budget support from the start, so go-live isn't followed by a cliff edge
Frequently asked questions
How long does it take to implement OpenCRVS or a similar CRVS DPG? Around three months for a pilot and six to 12 months for national implementation, depending on scope and integrations.
Why do government IT projects take so long? Usually because of legislation, procurement and decision-making, not the technology.
Is a DPG faster than a custom build? Yes. You start from a tested product, so the work is configuration and integration rather than building from scratch.
Sources
- How much does it cost to build DPI?, Centre for Digital Public Infrastructure
- OpenCRVS goes live in Bangladesh, UN ESCAP
Planning a realistic timeline for a DPI or CRVS programme? Let's talk.
