DEV Community: Dr. Om Mahajan

Most eGovernance RFPs are solving the wrong problem

Dr. Om Mahajan — Tue, 22 Sep 2026 15:44:20 +0000

Most eGovernance RFPs are solving the wrong problem.

They ask vendors to "digitise this department." The department was never the problem.

Across 50+ delivered projects, the scope in the tender was almost always the same: one department, one workflow, page after page of functional requirements.

What was missing: who owns the data once it has to cross a department boundary.

A citizen's record sits in one system. The approval sits in another. Each department is certain its version is the right one, and nobody in the tender is named to decide when they disagree.

So the software gets delivered, the forms get digitised, and the same file still travels between offices by hand or by email.

That isn't a technology failure. It's a scoping failure, and it's baked in before a single vendor bids.

Try this on your next tender: mark every data element that a second department also touches. Then check whether anyone is accountable for its accuracy.

If the answer is no, the data ownership gap is already in the contract.

PMU and procurement colleagues, what does your RFP say about cross-department data ownership?

eGovernance #DigitalTransformation #GovTech #PublicProcurement #PublicSectorIT #RFP #DataGovernance

100+ five-star reviews in the first month — for a government portal

Dr. Om Mahajan — Tue, 22 Sep 2026 15:43:16 +0000

100+ five-star reviews in the first month — for a government portal.

We didn't replace a single backend system to get there.

A state land-records department had grown to 30+ portals over the years. Each one worked on its own terms. Each had its own login and its own logic.

For a citizen needing one basic service, the problem wasn't the service. It was working out which portal, which login, which form.

The obvious fix was a rebuild. We went the other way.

We built one citizen-first front door: a single entry point, a single login, organised around what a citizen is trying to do, not around which department owns the system.

Every backend stayed exactly where it was. The complexity moved behind the door, where it belongs.

No data migration. No big-bang cutover. The citizen services were always there. People could finally find them, and the reviews followed.

What it actually took wasn't a bigger platform. It was agreeing that the citizen's journey, not the org chart, sets the structure.

Citizens don't experience your architecture. They experience your front door.

If your department is sitting on a similar sprawl, which service would you bring through the door first?

eGovernance #DigitalTransformation #GovTech #PublicSectorIT #CitizenServices #LandRecords #SingleSignOn

What 13+ Years in Software Taught Me About Scale?

Dr. Om Mahajan — Thu, 23 Jul 2026 07:45:05 +0000

In the early years, scale looked like a technical problem.

More users. More data. More transactions. More load. The solution seemed straightforward. Improve infrastructure. Optimise performance. Strengthen architecture. Add redundancy. Tune databases. Increase throughput.

Scale was measurable, predictable, and largely mechanical.

If the system could handle volume, it was considered scalable.

Over time, scale started looking very different.

The Shift From Volume to Variation

Systems rarely struggle because they cannot handle volume. Modern infrastructure, distributed architecture, and cloud environments have largely solved that problem for most applications.

What systems struggle with is variation.

Different interpretations of rules.
Different levels of administrative discipline.
Different leadership expectations.
Different operational habits.
Different ways the same process is understood in different places.

This is where scale becomes unpredictable.

When a system expands across departments, regions, or institutions, it stops encountering more of the same. It encounters more of the different. And difference is far harder to engineer for than volume.

Capacity Is Easier Than Diversity

Most systems are designed to expand capacity. Few are designed to absorb diversity.

Capacity scaling is quantitative. You plan for peak load, estimate growth, provision resources, and optimise performance.

Diversity scaling is qualitative. It involves judgment, interpretation, context, and behaviour. It introduces ambiguity into environments that systems prefer to keep deterministic.

Public sector environments amplify this challenge. They are defined by diversity, of context, constraints, priorities, administrative culture, and decision-making styles.

Two departments may operate under the same policy yet implement it differently. Two officers may follow the same rule but interpret its boundaries differently. Two regions may run identical workflows but attach different practical meaning to each step.

From a technical perspective, nothing is inconsistent. From an operational perspective, everything is.

When Identical Systems Feel Different

A system can perform perfectly in one department and feel unworkable in another without anything changing technically.

The code remains the same.
The architecture remains stable.
The infrastructure performs exactly as designed.

But the environment around the system does not remain stable.

Local practices reshape usage. Informal expectations influence behaviour. Institutional habits modify workflow. Over time, the system begins reflecting not just what it was designed to do, but how it is being interpreted.

This is the moment when scale reveals its real complexity.

Scale as Coexistence

After enough years working across implementations, scale stops meaning growth. It starts meaning coexistence.

How well does a system survive being used differently by people who all believe they are using it correctly?

That question defines real scalability.

A system that can process ten times more transactions is scalable in a technical sense. A system that can accommodate ten different operational interpretations without breaking trust, clarity, or reliability is scalable in an institutional sense.

The second is far harder to achieve.

Why Technical Strength Is Only the Beginning

Engineering discipline remains essential. Performance matters. Reliability matters. Security matters. Without these, nothing else holds.

But technical strength alone does not guarantee sustainable scale.

True scale requires tolerance for variation without loss of structure. It requires flexibility without ambiguity. It requires standardisation that does not erase context but still preserves consistency.

That balance is not purely technical. It is socio-technical. It sits at the intersection of system design, governance, administrative behaviour, and organisational culture.

Which means it cannot be solved by architecture alone.

What Experience Changes

Anyone who has worked across multiple implementations eventually notices this shift.

In the beginning, scale is something you engineer. Later, scale is something you observe. Eventually, scale is something you negotiate.

You stop asking whether the system can handle growth. You start asking whether the system can remain coherent while being interpreted differently across environments.

That is when scale stops being a performance metric and becomes a survival property.

And by that stage, the technical problem is only the beginning.

The Next Decade of Urban Governance

Dr. Om Mahajan — Wed, 04 Feb 2026 04:43:36 +0000

Working inside digital urban governance quietly changes how you think about the future.

You stop getting excited about dashboards and start worrying about decisions. You stop asking what technology can do and start asking what institutions are actually ready to absorb.

That perspective matters, because the next decade of urban governance will not be defined by smarter apps, larger command centers, or more screens on the wall. It will be defined by something far less visible and far more difficult: how effectively cities use data to anticipate, not merely react.

From Reaction to Anticipation
Most urban systems today are designed to explain what already happened.

Reports are generated after the fact. Reviews look backward. Meetings ask why something failed rather than what signals were missed earlier. This reactive posture is deeply embedded in administrative culture.

What’s coming is a shift away from reporting toward prediction.

Administrative systems will increasingly surface patterns, trajectories, and early warnings rather than static summaries. The real value will not be in knowing last month’s numbers, but in understanding where stress is building, which indicators are drifting, and what risks are emerging quietly across departments.

Prediction does not mean certainty. It means preparedness.

Rethinking Reviews and Accountability
As data matures, review mechanisms must evolve with it.

Traditional performance reviews are episodic. They focus on targets achieved or missed, files cleared, and outputs delivered. That approach works when systems are stable and slow-moving. Cities today are neither.

Future reviews will need to center on trends, correlations, and risk exposure. They will ask different questions:

Are certain complaints clustering geographically?
Are service delays becoming systemic rather than incidental?
Are policy interventions producing second-order effects elsewhere?

This is not about being softer on accountability. It’s about being smarter with it.

AI as an Assistant, Not an Authority
There is understandable anxiety around AI in government. Much of it comes from a false framing: replacement versus resistance.

What is far more realistic, and far more powerful, is augmentation.

AI will increasingly assist officers by simulating scenarios, surfacing trade-offs, and highlighting unintended consequences. It can help explore “what if” questions at a scale no human team can manage alone.

But judgment will remain human.

Context, ethics, political realities, and public trust cannot be automated. The role of AI in governance is to expand the decision space, not close it.

From Episodic Decisions to Continuous Feedback
One of the most underappreciated shifts ahead is temporal.

Governance today operates in bursts: inspections, reviews, audits, monthly meetings. Data flows continuously, but decisions do not.

That gap will narrow.
As systems integrate real-time and near-real-time feedback, governance will move toward continuous calibration. Policies will be adjusted incrementally. Interventions will be tested, observed, refined, and sometimes rolled back quickly.

This requires humility as much as technology. It also requires institutions that are comfortable learning in public.

The Real Constraint: Institutional Capacity
Technology will mature rapidly. That part is inevitable.

Institutional capacity will not, unless it is built deliberately.

Data quality, governance frameworks, cross-departmental trust, and human capability take years to develop. They cannot be purchased off the shelf. Cities that focus only on tools will find themselves with impressive platforms and fragile outcomes.

Those that invest early in foundations, standards, skills, and culture will compound their advantage over time.

Augmented, Not Automated
The future of urban governance is not automated.

It is augmented.

Augmented with better foresight.
Augmented with deeper situational awareness.
Augmented with tools that support judgment rather than substitute it.

That distinction matters, because cities are not machines to be optimized. They are living systems to be stewarded.

The next decade will reward administrations that understand this early and act on it deliberately.