Live in about a month, against a date set by statute
The 8th Pay Commission was handling demands from ministries and staff associations in an Excel sheet. A working portal replaced it in about a month, with four organisations coordinating and none reporting to the others.
- Client
- 8th Central Pay CommissionDelivered through NeGD, MeitY
- Role
- Project ManagerBDO India
- Team
- 8 peopleFour organisations coordinating
- Timeline
- Jul to Aug 2026Live on 24 August 2026
The challenge
The 8th Central Pay Commission reviews pay and pensions for about 70 lakh central government employees and pensioners. Ministries, staff associations and federations send it demands. When the project started, those demands were being handled in an Excel sheet, with no clear record of who was working on which demand or what had been decided.
The Commission's term is fixed by law, so the date could not move. The portal had to be live in about a month. It had to run on open-source tools and government cloud, use the government's single sign-on and pass an external security audit. Four organisations had to work together, and none of them reports to the others.
What was done
1. Build the modules side by side.
A delay in any one module would have pushed the whole date. So the plan was cut from five sprints to two and the modules were built in parallel. It meant more coordination and a heavier load on the project manager in the middle of the project. In return, no single module could put the date at risk.
2. Replace the spreadsheet with a proper workflow.
Each demand now moves through clear stages: created, examined, sent to a ministry if needed, reviewed by a senior officer, and then placed before the Commission. Every step has a named officer and is recorded, and the record cannot be edited afterwards. It is slower than editing a spreadsheet, and officers had to learn a process instead of a file. In return, anyone can see who holds a demand and what happened to it.
3. Size it for the volume that was coming.
Demand volumes were expected to grow many times within months. Building only for launch day would have meant a rebuild inside the Commission's term, when there was no room for one.
My role
What I owned
The delivery plan and the move to parallel streams, the workflow and its rules, coordination across four bodies, reporting, and the scope of the AI layer.
What the team delivered
Build and testing of 11 modules, and the one-time data load. A team of eight, including me.
What the client decided
The Commission's rules and approvals, the hosting, network and identity arrangements run by other bodies, and the external security audit.
The result
The portal went live on 24 August 2026, about a month after kick-off, and passed an external security audit (19 to 21 August). About 21,000 demands are on it today and around 200 people use it. Demand entry went from about 50 a day to about 1,000. Officers sign in through the government's single sign-on, and the data from 14 offices that shared no common format now sits in one place.
Where AI fits
AI layer · scoped, next stage
The next stage adds AI to help officers spot duplicate demands and find the evidence a demand refers to. It only advises. A named officer makes every decision.
The lesson
When a date cannot move, decide early which other thing will take the strain. Here it was coordination effort. Naming that on the first day made the rest of the plan realistic.
The best first requirement was the spreadsheet officers already used. Each of its columns became a proper field in the portal.
View the numbers as a table
| Step | Who moves it |
|---|---|
| Memorandum intake and assignment | Admin |
| Demand creation | Processing Officer |
| Examination | The officer who created it |
| Ministry referral (optional, offline; reply logged) | Creator |
| Referred-officer observation (optional) | Referred Officer |
| Review and priority | Reviewing Officer |
| Placed for consideration of the Commission | Terminal; later edits logged |
View the numbers as a table
| Measure | Value (approximate) |
|---|---|
| Demands created per day, earlier | ~50 |
| Demands created per day, now | ~1,000 |
| Demands held today | ~21,000 |
| Designed for | ~200,000 |
Read the detailsTimeline, requirements, workflow rules, decisions, architecture, delivery, how AI was used and the AI layer plan
A statutory commission still running on a spreadsheet
The 8th Central Pay Commission receives memoranda and demands from staff associations, ministries and federations, examines them, and places its recommendations. When I picked up the engagement, that process ran on an Excel workbook, and the Commission works against a tenure fixed in statute.
The platform had to give officers a governed workflow, take in the Commission's existing Excel data, migrated from 14 offices that shared no common data structure, and go live while coordinating four separate bodies.
The date could not move, so something else had to give
On most programmes, when requirements churn or a dependency slips, the date moves. Here it could not. So every other variable had to take the strain: the shape of the scope, the sequencing, the team structure and how coordination was run.
- A statutory tenure fixing the delivery date
- An Excel workbook to replace with an accountable workflow
- Volumes expected to rise by an order of magnitude within months of launch
- Four coordinating bodies with no reporting line between them
- Government of India requirements for open-source technology and government-cloud hosting
Deliver it, define it, then add the AI layer
I joined on 23 July 2026 as Project Manager, leading a team of eight. I owned delivery, product and workflow definition, and stakeholder coordination. After launch, I led the move from the first operational platform towards an AI-assisted examination layer, and I wrote its scope.
From a first meeting to a live portal in about a month
| Date (2026) | What happened |
|---|---|
| 17 to 20 Jul | Business rules worked out in a client session and consolidated into one document: roles, flow, rules and open actions |
| 23 Jul | I joined; the Commission reviewed the proposal at Additional Secretary level |
| 25 Jul | The Phase 1 proposal was submitted, and the first HTML prototype was built |
| 27 Jul | Prototype walked through to the CEO of NeGD, whose feedback shortened the deck |
| 28 Jul | Meeting with the Commission's Member Secretary, with a structured prototype walkthrough |
| Late Jul to Aug | Sprint plan cut from five sprints to two; BRD revised after client feedback; environments set up |
| 13 Aug | Database schema documented, after 34 migrations |
| 19 to 21 Aug | External security audit |
| 24 Aug | Go-live |
| 9 Sep | As-built functional specification issued: 143 requirements |
Starting from the workbook the officers already used
The Commission's own review workbook was the first requirement document. Its main sheet had 24 columns, and its reference sheets held 74 ministries, 269 demand titles, 47 sub-concerns, 38 pay levels, 6 evidence types and 7 standard remarks. Each of those became a structured field, not a free-text cell.
| Artefact | What it held |
|---|---|
| Proposal v1.0 | Scope, plan, sizing, risks and deliverables |
| Consolidated MRMS document | Roles, flow, the rules agreed on 17 July, open actions and a glossary |
| BRD v0.1 to v0.2 | Revised after client feedback; a client query document and a forwarding note went with it |
| Functional specification v1.0 | As built, dated 9 September: 143 requirements across 11 modules, with 10 documented differences from BRD v0.1 |
| Schema document | 29 tables and one view, after migration 034 |
| Sprint plan | 41 stories across two sprints, 12 milestones, 7 client dependencies, 8 risks and 13 Definition-of-Done criteria |
Every demand moves through clear stages
A memorandum is a submission. A demand is a single point the Commission has to decide on, and it is the only unit anything is measured in. Five roles use the platform: Processing Officer, Reviewing Officer, Concerned Ministry Officer, a Dashboard and Reports user, and Admin.
The user-facing modules are Memoranda Home, Demand Creation, Examination, Referred by Other Officer, Review, Demand Management, Dashboard, and Reports and Analytics. The as-built specification groups the whole system into 11 modules.
Rules settled, and the reason for each
| Rule | Why |
|---|---|
| Demand is the sole unit of measurement | The Commission acts on demands, not on submissions |
| Only the Reviewing Officer can place a demand before the Commission | A control point before anything reaches the Commission |
| Refer-back returns to the last officer who held the demand | Work returns to the sender |
| Three closure reasons at every stage: out of scope, duplicate, no rationale | Any officer must be able to close an invalid item |
| A duplicate closure must link to the demand it duplicates | Traceability |
| Archived demands reinstate at Examination, not at the old stage | A reinstated demand is reassessed |
| Observation notes are visible to their creator only | Protects the author's working note |
| The action history and audit log are append-only, enforced in the database | Audit integrity |
| Missing data is shown as "Not Specified" | Make gaps visible, not hidden |
| The closed-without-processing bucket is labelled "Non-Actionable Demands" | The client's own wording |
Three calls, each with its cost
Decision 1. Parallelise the delivery rather than sequence it.
WhySequencing the modules would have put every slip straight onto the statutory date. Running them as parallel streams across two sprints moved schedule risk into coordination, which I could manage, and away from the deadline, which I could not. The original plan had five sprints, and I cut it to two.
Trade-off acceptedParallel streams cost more coordination and more of my own time in the middle of the programme, and with a team of eight that was real. It bought a delivery shape where no single module could sink the date.
Decision 2. Turn the spreadsheet into a proper workflow, not a nicer spreadsheet.
WhyA shared file has no state, no owner and no audit trail, so work stalls invisibly. I specified the demand as a state machine, from creation through examination, ministry reply, peer referral and reviewing officer to placement before the Commission, with role-based access for each officer.
Trade-off acceptedIt is slower than a spreadsheet for a single quick edit, and it asked officers to learn a process rather than a file. That is the price of being able to say who holds a demand and what happened to it.
Decision 3. Build for month six, not launch day.
WhyThe known trajectory was tens of thousands of demands within months, and about 200,000 within six. Designing for launch-day volume would have meant rebuilding inside the same statutory window.
Trade-off acceptedDesigning for roughly ten times the live volume spent effort on load the platform did not yet carry, which is hard to justify against a four-week clock. It avoided a re-architecture during the Commission's tenure, when there would have been no room for one.
Other decisions on the record
| Decision | Choice | What it cost |
|---|---|---|
| Duplicate detection in Phase 1 | Exact match only, by a content hash; fuzzy matching waits for Phase 2 | Near-duplicates get through until then |
| Evidence | Officers describe evidence; they do not upload it | No evidence store in Phase 1 |
| Minimum supporting documents | Relaxed from three to none after feedback | Less enforcement |
| Priority on a demand | Removed at the client's direction | Less ranking at intake; priority is set at review |
| Ministry loop | Offline, with the reply recorded in the portal | Ministries have no login |
| Creation form | One scrollable page instead of a wizard | A longer form |
| Referral | Two modes: comments only, or transfer of ownership | More states to explain |
| Data load | Scripted imports run by an engineer, not an upload screen | Needs an engineer for each load |
| Phase 2 AI | A separate, advisory-only layer, kept out of Phase 1 | Efficiency gain deferred |
A plain system, loaded from a workbook
View the numbers as a table
| Step | Component | What it does |
|---|---|---|
| 1 | Officers | Reach the platform by browser over HTTPS |
| 2 | Firewall and load balancer | Front the government cloud |
| 3 | React web application | The officer interface |
| 4 | Node.js API | Parichay SSO, roles, tokens and workflow rules |
| 5 | PostgreSQL | 29 tables, with an append-only audit log |
| 6 | Document store | Documents behind opaque references |
| 7 | Import scripts | Load the Excel data in, hashed, with contacts encrypted |
The front end is React, the API is Node.js with Express, and the database is PostgreSQL. Officers sign in through Parichay SSO, which is live. Sessions use signed tokens bound to the device, and access is by role. The schema has 29 tables and a view. The action history and audit log cannot be changed after the fact, because the database revokes the permission and a trigger blocks it. The platform is hosted in a government cloud behind a firewall.
Loading the data
- Excel dumpmemoranda and demands
- Import scriptsfive, run by an engineer
- Exact-duplicate hashidentical items flagged
- Contacts encryptedemail and mobile
- PostgreSQL~21,000 demands
There was no legacy system to migrate from, so this was a one-time load of the Commission's existing Excel data, which came in from 14 offices with no common structure. Gaps in the data were surfaced as "Not Specified" instead of being filled in or hidden.
Four bodies, no reporting line, one date
Across four bodies that do not report to each other, the only levers are institutional, not managerial. Coordination ran through the proper channels rather than through requests, and the Excel data load ran as its own stream so it could not block module delivery.
View the numbers as a table
| Week | What happened |
|---|---|
| 1 | Requirements and scope freeze; single sign-on and environments |
| 2 to 3 | Core build of the modules in two parallel streams |
| 4 | Integration testing, UAT, training, security audit, data load, go-live |
| 1 to 4 | Excel data load, as its own stream |
Reporting ran on a fixed pattern: a weekly steering committee, and status reports to the Commission's director listing every dependency with its owner, current status and next step. I presented a progress review at Additional Secretary level. An external security audit ran from 19 to 21 August, and the platform has 748 automated checks on its dashboard.
The programme ran as an AI-assisted lifecycle: AI support in requirements, review, delivery, discovery and documentation, with a person accountable for every output. The lifecycle is set out on the How I work.
Where Claude helped, and where it was wrong
In use for deliveryAI examination layer: scoped, next stage
| Stage | What Claude produced | What stayed a person's call |
|---|---|---|
| Discovery | Analyses of the Excel workbook and survey data | Which questions to ask |
| Requirements | BRD v0.2, the client query document, the forwarding note, the consolidated document | Content, approvals and the client's wording |
| Design | Single-file HTML prototypes: five portal versions, eight dashboard versions and a Phase 2 prototype | Direction and feedback |
| Planning | The sprint plan in Excel, with stories, milestones, dependencies, risks and a definition of done | The shape of the plan and what to cut |
| Deployment | The infrastructure timeline and dependency tracker | Escalations |
| Reporting | Status, expenditure and meeting reports | Which figures to publish |
| Training | The induction deck | Content |
| Phase 2 | The Phase 2 BRD and an AI delivery report | Scope |
Where it was wrong
| What went wrong | How it was caught | The lesson |
|---|---|---|
| It produced numbers that were not in the source files | I checked every figure against the files | Ground every figure in a source |
| It proposed duplicate detection as a new AI feature when exact-match detection already existed | I read the as-built specification | Read what exists before proposing what is new |
| A sprint plan assumed a different database from the one built | The specification showed PostgreSQL | Keep the stack documents aligned |
Live on 24 August, with the AI layer next
The platform is designed for much larger volumes than it holds today, while staying aligned to Government of India requirements for open-source technology and government-cloud hosting. Demand creation went from about 50 a day to about 1,000.
The AI layer, and what it is not allowed to do
Scoped, not builtNot part of the live platform
I wrote the scope for the AI examination layer: duplicate detection, so that the same demand arriving through several associations is recognised as one; anomaly detection; evidence matching against the memoranda a demand cites; and retrieval of the referenced sources. The objective is that officers stop reading every page to find the one that matters. It is not to automate the examination.
View the numbers as a table
| Capability | What it does |
|---|---|
| Duplicate detection | Clusters exact, near and contextual matches across memoranda and demands |
| Anomaly detection | Flags items that do not fit the pattern |
| Evidence matching | Matches a demand to the memoranda it cites |
| Source retrieval | Surfaces the referenced source passage |
Duplicates are graded by similarity: identical at 0.99 and above, near between 0.60 and 0.99, and related between 0.40 and 0.60. The use cases grew from seven to nine to eleven as the work was scoped. The layer is advisory only and separate from Phase 1, and the delivery is planned as a two-month split.
The division of labour is deliberate. Power BI gives analytical visualisation and the AI gives examination support. Neither is asked to do the other's job, and neither makes the decision.
Decide early what gives when the date will not
Where a date is genuinely immovable, the useful question is not how to go faster but which variable is allowed to absorb the risk. Naming that early, here coordination overhead, is what makes the rest of the plan honest.
Escalation and diagnosis are parallel tracks, not a sequence. Raising an issue through the right channel does not mean waiting for it.
Read what is already built before proposing what is new. Several of the places AI was wrong here were places where the as-built specification already had the answer.