Roadmap & Release Plan

The phased delivery and release plan for the Sindh IT Portal — Facilitation Desk (SITP): how a Public-Private Partnership builds, launches, sustains, and ultimately hands over the platform, sequenced by MoSCoW priority even though the entire scope is V1.

1. Purpose & How to Read This Document

This document defines what gets built when, by whom, against which gate, and how the Government of Sindh retains continuity regardless of the operator. It is written to be RFP- and tender-ready and is the authoritative source for the S&ITD program office, the MAAHIR delivery team, Server4Sale (host), and the departmental and ecosystem stakeholders.

It aligns with three locked facts in _context.md:

1. All features are V1 scope. The MoSCoW tag ([M] Must, [S] Should, [C] Could, [W] Won't) controls sequencing, not inclusion (see /specs/en/01-prd/ §1.2, §3).
2. Delivery is phased into Phase 0 → Phase 4 (see _context.md §9).
3. Delivery model is a Public-Private Partnership (PPP). Owner: S&ITD. Operator: MAAHIR. Host: Server4Sale. Canonical URL: https://sindhitportal.maahir.io. Footer: "Operated by MAAHIR · Powered by Server4Sale."

This roadmap cross-references: requirements /specs/en/02-functional-reqs/, NFRs /specs/en/03-non-functional-reqs/, ticket workflow /specs/en/06-ticket-workflow/, AI/OCR /specs/en/07-ai-ocr-spec/, integrations /specs/en/08-integrations-spec/, security /specs/en/11-security-compliance/, test strategy /specs/en/13-test-strategy/, architecture /specs/en/15-tech-architecture/, analytics/KPIs /specs/en/17-analytics-kpis/, governance/legal /specs/en/22-governance-legal/, PPP/exit /specs/en/23-ppp-vendor-exit/, and trust/safety /specs/en/24-trust-safety/.

2. Delivery Model — Public-Private Partnership (PPP)

2.1 Roles in the PPP

2.2 PPP safeguards (binding)

The PPP contract MUST embed the safeguards detailed in /specs/en/23-ppp-vendor-exit/. The five non-negotiables, mapped to their milestone in §7, are:

1. Service-Level Agreements (SLAs) — operational, availability, and resolution SLAs with penalties and remedies.
2. Source-code escrow — deposit at every release, release to S&ITD on trigger events (M07).
3. Intellectual Property (IP) ownership — IP vests in S&ITD (M08, rolling).
4. Knowledge transfer (KT) — per phase and at contract milestones (M09).
5. Exit / handover plan — a tested, executable transition so continuity is never operator-dependent (M10, M11).

2.3 Why PPP (and not in-house or pure-outsourced)

A PPP gives S&ITD speed and specialist capability (MAAHIR's product/AI engineering; Server4Sale's infra) while retaining public ownership, accountability, and continuity through the safeguards above. It also matches the SIFC-style "single window" ambition: a private-operator cadence inside a government mandate.

3. Phasing Principle

Although the entire scope is V1, delivery is sequenced by MoSCoW so that value lands early, risk retires progressively, and adoption builds before the platform is publicly generalized.

Key reconciliation (read this before the phase tables):

• Phase 1 ships the Must-tier core as a controlled pilot / soft launch with a limited cohort of departments and companies. This is the end-to-end Must journey: register → file → route → resolve → close → track, in EN/UR/SD with basic AI.
• Phase 2 completes the Must set to General Availability (GA): full Must-quality Sindhi linguistic QA and RTL polish; the full SLA engine (configurable tiers, pause-on-await, Sindh holiday calendar, complete escalation ladder to the SACM); the Must-tier TRI meetings + MoM; and the remaining Must modules (officials CMS, full dashboards). Phase 2 exit = V1.0 public GA.
• Phase 3 delivers the Should-tier (advanced ticket operations, PKI e-sign + QR letters, exam-gated certification, multi-channel intake, NITB e-Office, public API, security hardening + penetration test) and deepens appeal adjudication.
• Phase 4 delivers the Could-tier and mobile/advanced capabilities.

Where a Must capability spans phases (e.g., Must AI routing ships in Phase 1; the richer Should-tier AI lands in Phase 2/3), the MoSCoW→Phase table in §6 makes the split explicit. No requirement tagged [W] (Won't) is in any V1 phase; deferred items live in §11.

4. Phase Plan Overview (Gantt)

The five phases run sequentially with short stabilization overlaps. Durations are indicative planning bands for a single cross-functional MAAHIR team plus S&ITD product/QA; they assume the critical-path dependencies in §8 are met on time.

Written description. Phase 0 (Discovery) runs 2–3 weeks and produces the baselined specs, provisioned environment, and lodged applications. Phase 1 (MVP Core) runs 8–10 weeks and culminates in a controlled soft launch (MVP pilot). Phase 2 (AI + Sindhi + SLA) runs 6–8 weeks and ends at public GA (V1.0). Phase 3 (Appeal + Integrations + Security) runs 6–8 weeks and ends at V1.1. Phase 4 (Mobile + Advanced) runs 6–8 weeks and ends at V1.2. Sustainment runs continuously from GA onward under the ADP-funded managed-services arrangement (§10).

5. Phase Detail

Each phase below states scope (epics/modules/features with MoSCoW), entry criteria, exit criteria, key deliverables, dependencies, and risks.

5.1 Phase 0 — Discovery (2–3 weeks)

Goal. Convert the approved documentation set into a baselined, build-ready program; provision the environment; and lodge every external dependency that has long lead-times (legal mandate, department MoUs, API access, escrow).

Scope.

Entry criteria. (1) PPP contract in force (M01); (2) Statement of Work signed; (3) S&ITD product owner and MAAHIR delivery lead named; (4) Server4Sale environment accessible.

Exit criteria (= Milestone M02). (1) Baseline specs approved by S&ITD; (2) environments (dev/staging) live; (3) escrow agent appointed and escrow agreement signed; (4) all API access requests lodged with receipts; (5) at least 3 founding department MoUs in draft; (6) risk register baselined; (7) change-management & adoption plan drafted (§9).

Key deliverables. Baselined PRD/FR/NFR/RBAC/data model/workflow/AI/integrations/API/test docs; design system v0; provisioned environments; CI/CD pipelines; initial risk register; adoption & training plan v0; escrow agreement; API-access request tracker.

Dependencies. PPP contract execution (M01); department willingness to nominate officers; ecosystem bodies' responsiveness; availability of native Sindhi reviewers.

Top risks. (R-legal) Slow legal notification; (R-api) API access delays from NADRA/SECP/FBR/SRB; (R-dept) Departments slow to engage; (R-brand) Brand approvals iterate. Mitigations in §12.

5.2 Phase 1 — MVP Core (8–10 weeks) — [Must]

Goal. Deliver the end-to-end Must-tier journey as a controlled pilot / soft launch: an IT company registers (file-first, provisional), files a ticket with attachments, the ticket is AI-routed and tracked by ID, the concerned department resolves it with the proof-of-resolution gate, the company rates it (CSAT), and leadership sees core dashboards — in EN/UR/SD.

Scope (Must stories from the relevant epics).

Entry criteria. Phase 0 exit (M02) met; environments ready; at least the first department MoU signed.

Exit criteria (= Milestone M03 — MVP pilot live). (1) All Phase 1 Must stories pass acceptance per /specs/en/13-test-strategy/; (2) end-to-end UAT green on the register→file→route→resolve→close→track journey; (3) security baseline (2FA, ClamAV, encryption, rate-limiting) verified; (4) trilingual (EN/UR/SD) rendering verified including RTL; (5) soft launch operational with a limited cohort (e.g., S&ITD + 2–3 founding departments + a closed group of ~20–50 IT companies); (6) escrow deposit for this release made (M07); (7) KT session delivered (M09).

Key deliverables. Working MVP (soft launch); UAT report; security baseline report; trilingual QA report; initial SOPs for officers; source-code escrow deposit (release 1); runbooks v0; pilot metrics baseline.

Dependencies. Phase 0 dependencies continuing (API access must be live for verify-in-parallel; department officers onboarded and trained); holiday calendar data for SLA.

Top risks. (R-integ) Verification API latency/downtime; (R-ux) Onboarding friction in real cohort; (R-i18n) Sindhi rendering edge cases; (R-sec) Early security findings. Mitigations in §12.

5.3 Phase 2 — AI + Sindhi + SLA (6–8 weeks) — [Must] completion → GA

Goal. Complete the Must set to public General Availability (V1.0): full-quality Sindhi and RTL; the complete, configurable SLA engine with the full escalation ladder; the Must-tier TRI meetings + MoM upload; the remaining Must modules (officials CMS historical accuracy, full analytics); and the richer Should-tier AI capabilities that elevate the experience.

Scope.

Entry criteria. Phase 1 exit (M03); pilot operating without severity-1 defects; API access stable; at least one TRI-worthy stalled ticket or realistic simulation available.

Exit criteria (= Milestone M04 — V1.0 Public GA). (1) All remaining Must stories pass acceptance; (2) Go/No-Go launch checklist (§9.4) is GREEN; (3) public transparency dashboard live; (4) full SLA engine verified end-to-end incl. escalation to SACM; (5) Sindhi WCAG 2.1 AA verified; (6) TRI + MoM flow demonstrated end-to-end; (7) escrow deposit (release 2) made; (8) KT delivered; (9) change-management & adoption plan executing (roadshows scheduled).

Key deliverables. V1.0 GA release; analytics suite; KB/SOP library seeded; TRI capability; full SLA engine; Sindhi QA sign-off; department scorecards; escrow deposit (release 2); GA runbooks.

Dependencies. Sindh holiday calendar data; department participation in TRI pilots; AI provider provisioning (cloud or self-hosted per data sensitivity); PSEB/P@SHA outreach active.

Top risks. (R-ai) AI quality/hallucination; (R-sla) Departments resist published scorecards; (R-tri) Departments decline TRI participation; (R-sd) Sindhi quality gaps surface late. Mitigations in §12.

5.4 Phase 3 — Appeal + Integrations + Security (6–8 weeks) — [Should] → V1.1

Goal. Deliver the Should-tier: advanced ticket operations, PKI e-sign + QR-verifiable letters, exam-gated staff certification, multi-channel intake, the remaining integrations (NITB e-Office, public REST API, webhooks), deepened appeal adjudication, and security hardening including penetration testing.

Scope.

Entry criteria. Phase 2 exit (M04, V1.0 GA); platform stable in production; security engagement scoped.

Exit criteria (= Milestone M05 — V1.1). (1) Should-tier stories pass acceptance; (2) penetration test remediated to agreed severity threshold; (3) CII registration submitted; (4) exam-gate enforced (no uncertified staff on live tickets); (5) e-signed QR-verifiable letters in production; (6) NITB e-Office integration live (where technically available); (7) escrow deposit (release 3) made; (8) KT delivered.

Key deliverables. V1.1 release; penetration-test report + remediation evidence; CII registration; certification program live; e-sign capability; public API; multi-channel intake; escrow deposit (release 3).

Dependencies. NITB e-Office technical availability (A8); PKI/certificate authority arrangement; IVR/voice provider; security firm engaged; training content authored.

Top risks. (R-nitb) NITB e-Office not ready; (R-pki) PKI CA delays; (R-pentest) Material security findings; (R-exam) Low exam pass-rate stalls staff onboarding. Mitigations in §12.

5.5 Phase 4 — Mobile + Advanced (6–8 weeks) — [Could] → V1.2

Goal. Deliver the Could-tier and the native mobile experience, taking the platform from "fully functional web V1" to "best-in-class, mobile-first, advanced".

Scope.

Entry criteria. Phase 3 exit (M05); V1.1 stable; app-store/developer accounts provisioned.

Exit criteria (= Milestone M06 — V1.2). (1) Mobile apps pass store review and acceptance; (2) Could-tier stories pass acceptance; (3) escrow deposit (release 4) made; (4) KT delivered; (5) sustainment transition confirmed (§10).

Key deliverables. V1.2 release; Android + iOS apps; channel-based chat; advanced BI; suggestion portal; escrow deposit (release 4).

Dependencies. App-store accounts; push-notification provider; Metabase embedding finalized.

Top risks. (R-mobile) Store review cycles; (R-channel) Adoption of internal chat vs existing tools; (R-scope) Scope creep from Could→Must pressure. Mitigations in §12.

6. MoSCoW → Phase Mapping

This is the single mapping that reconciles the PRD's MoSCoW tags (/specs/en/01-prd/) with the phase themes. "P1" = MVP core; "P2" = AI+Sindhi+SLA; "P3" = Appeal/Integrations/Security; "P4" = Mobile/Advanced. — = not in that phase.

Reading the table. Every [M] story completes by the end of Phase 2 (V1.0 GA) at the latest; most Must ships in Phase 1. [S] completes by end of Phase 3 (V1.1). [C] lands in Phase 4 (V1.2). [W] (Won't) items — native mobile before P4, e-payments, auto-assignment before P4, detailed DR runbooks, non-IT sectors — are explicitly deferred (§11) and not in any V1 phase gate.

7. Milestone Register

Twelve program milestones govern planning, billing, and acceptance. PPP handover milestones (M07–M11) are cross-referenced to /specs/en/23-ppp-vendor-exit/.

8. Critical-Path Dependencies

These dependencies are on the critical path: slippage on any one delays the corresponding phase gate. They are tracked weekly by the program office.

9. Change-Management & Adoption Plan

Government portals often succeed technically but fail on adoption. This program treats adoption as a first-class workstream with its own plan, owners, and KPIs (§9.5), running from Phase 0 through sustainment. It is the single most important non-technical risk (R1, R2).

9.1 Adoption thesis

The Portal only delivers value when (a) IT companies register and file, and (b) departments respond within SLA. Both are behavioral changes. The plan therefore invests in partnerships, presence, and pull — not just push communications — and uses the public transparency dashboard as the structural incentive for departments to perform.

9.2 Partnerships

9.3 Roadshows, onboarding drives, and training

• Roadshows (Phase 1 exit onward): quarterly multi-city events (Karachi, Hyderabad, Sukkur, Larkana, Mirpurkhas) jointly with PSEB/P@SHA — live demos, on-the-spot registration help, FAQ sessions in EN/UR/SD.
• Onboarding drives: time-bound campaigns (e.g., "First 500 verified entities") with the onboarding wizard (US-PUB-005) guiding each of the 5 entity types.
• Department training & certification (Phase 3): the exam-gated certification (US-ORG-007, /specs/en/20-training-certification/) ensures every officer handling live tickets is trained and certified. Pre-GA, founding departments get intensive enablement.
• Leadership dashboards as adoption leverage: the CM/SACM and Secretary dashboards make department performance visible, creating top-down pull.
• Multilingual, accessible comms: all adoption material in EN/UR/SD, WCAG 2.1 AA, Ajrak-branded, with the public transparency dashboard as the "proof of responsiveness" story.

9.4 Go/No-Go launch checklist (M12 / M04)

The checklist below is reviewed at the Go/No-Go gate before V1.0 Public GA. A lighter subset applies at the MVP soft-launch gate (M03). Status: ✓ required-pass; ◐ required-acceptable-with-plan.

9.5 Adoption KPIs

Tracked in /specs/en/17-analytics-kpis/: registered entities by type (target ≥1,500 verified in 12 months); active departments with certified officers (≥40); filing-to-resolution funnel; deflection rate (≥30%); CSAT; department SLA compliance (public scorecard).

10. Post-Launch Sustainment & Funding

10.1 Operating model after GA

From V1.0 GA onward, MAAHIR operates the platform under the PPP managed-services arrangement, with Server4Sale hosting. Sustainment covers: managed services (L2/L3), incident response, security operations, trilingual content maintenance, AI model upkeep, KB/SOP curation, analytics/reporting, and continuous improvement against the KPIs in §11.

10.2 Funding

• Primary: ADP (Annual Development Programme) budget line. S&ITD establishes a dedicated ADP line for the Portal covering build (Phase 0–4) and initial sustainment. The ADP line is the locked funding source and is reflected in the PPP contract.
• Path to self-sustaining. As adoption matures, the model evolves toward cost-recovery / self-sustaining options (e.g., tiered value-added services for companies, sponsored KB content, integration fees) — only where they do not compromise free core facilitation for the IT industry. Any monetization is subject to S&ITD and government approval and must preserve free filing for all 5 entity types.
• Renewal/exit funding is pre-negotiated in the PPP so that a transition (M10/M11) is fundable without disruption.

10.3 Continuous improvement

Each release after GA follows the release cadence (§13). The product backlog is fed by: analytics insights, CSAT/appeal trends, department feedback, AI draft-acceptance metrics, and the suggestion portal (Phase 4).

11. KPIs Per Phase

KPI definitions, formulas, thresholds, and cadences are owned by /specs/en/17-analytics-kpis/. The roadmap's per-phase KPI focus is:

12. Risk Register & Mitigations

Risks are inherited/extended from /specs/en/00-vision-scope/ §12 and made phase-aware. Likelihood (L) and Impact (I): L/M/H.

13. Release Cadence & Versioning

13.1 Versioning

Semantic versioning at the platform level (the deployed product), independent of internal module versions:

13.2 Cadence after GA

• Patch releases (bug fixes, security patches, hotfixes): as needed, target ≤72h for Sev-1.
• Minor releases (features, improvements): every 4–6 weeks, behind feature flags, with escrow deposit + KT note per release.
• Major releases: aligned to ADP/fiscal planning cycles and the PPP contract review points.

13.3 Release governance

Every release passes: automated CI (lint/type/test), security scan, trilingual QA on touched surfaces, UAT for changed journeys, release notes (EN/UR/SD), escrow deposit (M07), IP assignment note (M08), and a KT note (M09). Rollback is tested before each release. The Super Admin feature-flag console (Module Q) controls per-department/env exposure.

14. References

14.1 Internal documentation

• Project context (locked decisions): ../_context.md
• Documentation conventions: ../_conventions.md
• Vision & scope: /specs/en/00-vision-scope/
• PRD (MoSCoW per story): /specs/en/01-prd/
• Functional requirements: /specs/en/02-functional-reqs/
• Non-functional requirements: /specs/en/03-non-functional-reqs/
• Roles & permissions: /specs/en/04-roles-permissions/
• Ticket workflow: /specs/en/06-ticket-workflow/
• AI/OCR spec: /specs/en/07-ai-ocr-spec/
• Integrations spec: /specs/en/08-integrations-spec/
• UX/sitemap/flows: /specs/en/10-ux-sitemap-flows/
• Security & compliance: /specs/en/11-security-compliance/
• API contract: /specs/en/12-api-contract/
• Test strategy: /specs/en/13-test-strategy/
• Tech architecture: /specs/en/15-tech-architecture/
• Branding & design system: /specs/en/16-branding-design-system/
• Analytics & KPIs: /specs/en/17-analytics-kpis/
• Knowledge base & SOPs: /specs/en/18-knowledge-base-sop/
• Multi-channel intake: /specs/en/19-multichannel-intake/
• Training & certification: /specs/en/20-training-certification/
• MoM & meetings: /specs/en/21-mom-meetings/
• Governance & legal: /specs/en/22-governance-legal/
• PPP vendor & exit: /specs/en/23-ppp-vendor-exit/
• Trust & safety: /specs/en/24-trust-safety/

14.2 External benchmarks

• India CPGRAMS (pgportal.gov.in) — phased adoption of appeal, feedback, mobile apps, AI chatbot, Urdu+Sindhi support.
• Pakistan Citizens Portal (PCP) — mobile-first routing and ministerial dashboards.
• SIFC "One Window" — investor single-window model provincialized for IT.

End of document. Urdu and Sindhi parallel translations (ur.md, sd.md) follow this master structure exactly.