Detailed Project Report for PM-SETU Monitoring System

AbbreviationsPDF p.4

The abbreviations used throughout this Detailed Project Report are listed below in alphabetical order.

1. OverviewPDF p.5

PM-SETU will be delivered through multiple systems and implementation entities, but programme leadership needs one consistent view of progress across SPVs. This DPR defines the Monitoring System that will provide that view. It is designed as the quarterly non-financial reporting and review layer for PM- SETU, bringing DLI/KPI progress, implementation status, risks, audit actions, resource gaps and employment outcomes into one structured monitoring cycle.

The design follows a simple principle: reuse data before asking for data again. Information already available in LMS/LOMS, FMS/UC/Audit, SIDH/NCVT MIS, tracer and survey records, and approved programme records will be pre-filled. SPVs complete only the gaps, explanations and evidence that are not available elsewhere. The State reviews the submission, while Centre users and Analytics consume the same validated quarterly position. This reduces duplicate reporting and creates a reliable basis for programme review and action.

1.1. ScopePDF p.5

This DPR covers the business and system requirements required to run the quarterly monitoring cycle from form creation through SPV submission, State review and Centre oversight. The scope is deliberately focused on monitoring, validation and exception management; the underlying source systems remain responsible for creating and maintaining their own records.

• •Quarterly monitoring form covering DLI/KPI progress, project delivery, audit actions, resource gaps, risks and employment outcomes.
• •Auto-population from approved PM-SETU systems, with the source and last refresh date visible for each pre-filled value.
• •SPV input limited to missing information, variance explanations, corrective actions and supporting evidence.
• •State review and field-level return for correction, followed by Centre-level consolidation, exception monitoring and escalation.
• •Validated quarterly snapshots feeding Analytics and alerts, with Q4 submission completed before the next AOP is submitted.

1.2. Key AssumptionsPDF p.5

• •Financial transactions and detailed budget records remain in FMS. Monitoring only reads the status or references needed for programme oversight.
• •Quarterly capture is a PM-SETU operating cadence. Formal DLI reporting and independent verification continue at the frequency defined for each indicator.
• •Auto-filled fields are read-only unless a controlled exception is approved. The source system remains authoritative.
• •SPV, State and Centre users access the module through approved SSO and role/entity mapping.
• •DLI 4-6 are mainly State/Centre responsibilities. SPVs provide supporting cluster-level inputs only where specifically requested.

2. Business RequirementsPDF p.5

The Monitoring System is designed around one quarterly reporting cycle: the system pre-populates available information, the SPV completes only the gaps, the State reviews exceptions, and the Centre monitors the validated programme position. This section defines the business requirements needed to run that cycle consistently across all SPVs.

The requirements therefore follow the operating flow of the module: access and form creation, information capture, SPV submission, State review, and Centre monitoring. Detailed DLI-linked fields and system rules are defined in Section 3.

2.1. Quarterly Monitoring CyclePDF p.6

At the start of each quarter, the system opens a reporting for every active SPV/HSIC and notifies the relevant SPV and State users. The SPV accesses the current-quarter form through SSO. The form is pre- filled from approved source systems before any manual input is requested.

The SPV completes the remaining fields and submits the form after system validation. The State reviews the submission and may return only the fields that need clarification. Once reviewed, the same record becomes available for Centre monitoring, Analytics and alerts. For Q4, the monitoring form must be submitted before the next AOP can be initiated.

Architecture / overviewPDF p.6

Tap to enlarge

3. User JourneysPDF p.6

3.1. Overall User JourneyPDF p.6

• •Quarter initiation: The system opens the reporting quarter,

creates one monitoring form for each active SPV and sends the due-date notification to SPV and State users.

• •Auto-population: Approved source systems populate

available fields first. Each pre-filled value carries its source and last-updated reference.

• •SPV completion: The SPV reviews pre-filled values,

completes only missing fields, explains deviations and attaches evidence where required.

• •Validation and State review: The system checks mandatory

fields and consistency. The State reviews exceptions and returns only the affected fields where clarification is needed.

• •Centre monitoring: Once the review position is available,

the same record feeds Centre monitoring, Analytics and alerts. No second data entry is required.

User journeyPDF p.7

Tap to enlarge

3.2. SPV User JourneyPDF p.7

• •Notification and access: The SPV receives the quarter-

open notification, signs in through approved SSO and opens the current monitoring form.

• •Review pre-filled data: The SPV checks data already

received from LMS/LOMS, FMS references, SIDH/NCVT MIS, surveys and other approved programme sources.

• •Complete gaps: Only fields that are not available from

source systems are opened for entry. The SPV adds the value, explanation and evidence as applicable.

• •Validate and submit: The system checks completeness and

basic consistency before allowing submission to the State review queue.

• •Return and resubmission: If the State returns specific

fields, the SPV updates only those fields and resubmits. In Q4, the form must be complete before the next AOP can be submitted.

3.3. State User JourneyPDF p.7

• •Review queue: The State sees all SPV submissions within

User journeyPDF p.7

Tap to enlarge

its scope, including pending, submitted, returned and reviewed status.

• •Data review: The reviewer checks source-populated values,

SPV-entered fields, evidence, DLI/KPI position and material exceptions.

• •Clarification: Where information is incomplete or

inconsistent, only the affected fields are returned with comments; the full form is not reopened.

• •Review completion: Once satisfactory, the State marks the

review complete. The updated position becomes available for State dashboards and Centre monitoring.

User journeyPDF p.8

Tap to enlarge

3.4. Central User JourneyPDF p.8

• •National monitoring view: Centre/NPMU users see

submission coverage, State/SPV status and DLI/KPI exceptions across the programme.

• •Drill-down: Users can move from the national view to a

State, SPV or indicator to understand the underlying exception and supporting record.

• •Action and alerts: Where intervention is required, the

system issues an alert or action request to the responsible State/SPV and tracks closure.

• •Analytics and reporting: Reviewed monitoring data is

reused in Analytics and programme reporting, giving Centre a current scheme-level position without additional data collection.

4. Functional System RequirementsPDF p.8

The functional requirements translate the business requirements above into DLI-linked fields, source ownership, SPV action, capture frequency and review responsibility. The quarterly view supports programme management; formal DLI verification continues under the approved verification arrangements.

4.1. Monitoring Form Functional AreasPDF p.8

The quarterly form captures the minimum information required to understand implementation progress, exceptions and outcomes. Wherever a trusted source exists, the system should pre-populate the field; the SPV should provide only missing information, explanations, actions or evidence.

4.2. Detailed DLI Capture RequirementsPDF p.9

The quarterly form mirrors the programme DLIs but does not change their formal verification frequency. The system captures a quarterly management position, while formal annual or semi-annual verification remains separate.

DLI 1 — Employment outcomes of graduates from supported ITIs improved

DLI 2 — Access to better-quality training programs of supported ITIs increased

Sub- componen t

Formal target / reference

DLI 3 — Governance and management of supported ITIs strengthened

DLI 4 — State governance and leadership for an enabling environment for ITI ecosystem strengthened

DLI 5 — Quality of training at NSTIs increased

DLI 6 — National governance and leadership strengthened

4.3. KPI Monitoring and Calculation RequirementsPDF p.14

All KPIs defined under the PM-SETU KPI framework form part of the Monitoring System and are monitored alongside the DLIs above. The complete KPI definitions, weightages and year-wise targets are set out in Annexure A. For operational monitoring, the table below records the evaluation or calculation rule and the information the system is expected to present.

4.4. KPI Scoring and Calculation MethodPDF p.17

For funding-linked KPIs, the system applies only the KPIs relevant to the reporting year. The calculation follows the method used in the KPI framework sample calculations: achievement is compared with the applicable target, fulfilment is capped at 100% for scoring, and the result is multiplied by the KPI weightage. The overall score is normalised against the weightage applicable in that year.

5. Solution ArchitecturePDF p.18

The Monitoring System will bring together the information required for quarterly PM-SETU monitoring. Data already available in connected systems will be pulled into the monitoring form automatically. The SPV will complete only the information that is unavailable, after which the State will review the submission. Reviewed information will feed the Analytics module and Centre-level monitoring.

Architecture / overviewPDF p.18

Tap to enlarge

5.1. Data LayerPDF p.19

The data layer identifies what Monitoring receives from each source and why it is required. Source systems remain responsible for maintaining their own records.

• •LMS: provides learner enrolment, attendance, course completion and trainer-training information required to track training delivery. Placement or employment records may also be used where maintained in the LMS.
• •FMS / UC / Audit: provides SIP/AOP references, utilization-certificate status, audit status and compliance flags needed to track implementation and open actions. Detailed financial transactions remain in FMS.
• •SIDH / NCVT MIS: provides available learner, course, institution and certification records so that approved information is not requested again from the SPV.
• •Survey / tracer records: provide graduate employment outcomes, female employment outcomes and employer, faculty and trainee feedback used for outcome monitoring.
• •Official programme records: provide governance orders, leadership and board evidence, annual reports, programme decisions and NSTI records required for DLI/KPI monitoring.

5.2. Platform LayerPDF p.19

The platform layer turns source data and SPV inputs into one reviewed quarterly monitoring record.

• •Bring data into Monitoring: use APIs where systems support them and controlled batch exchange where they do not.
• •Check incoming information: verify the reporting quarter, common identifiers, duplicate records, source freshness and mandatory evidence before the data is used.
• •Prepare the quarterly form: pre-fill available information, keep source-populated values read-only and open only the fields that require SPV input, explanation or evidence.
• •Create the quarterly record: lock the submitted version so the programme has one traceable position for that quarter; later source updates remain separately identifiable.
• •Manage follow-up: send reminders for quarter opening, overdue submissions, returned fields, stale source data and material DLI/KPI exceptions.
• •Feed Analytics: send reviewed monitoring records with their source, reporting period and data-quality status for dashboards, alerts and programme review.

5.3. User Access LayerPDF p.19

Access is role-based. Each user sees only the forms, review actions and dashboards required for their PM-SETU responsibility.

6. Nonfunctional RequirementsPDF p.20

The Monitoring System should remain reliable through each quarterly reporting cycle, protect programme information and work consistently with the other PM-SETU modules. The requirements below define the minimum service, security and usability conditions for the platform.

6.1. Performance and Data FreshnessPDF p.20

• •Display the latest successful refresh time for source-populated information so users can see how current the data is.
• •Load the latest available values without making the SPV wait for a new source-system refresh.
• •If a source is temporarily unavailable, retain the last available value and clearly mark it as stale or provisional until the next successful refresh.
• •Quarterly form generation, validation, submission and review should continue without being blocked by a slow external source.

6.2. Security and Role-based AccessPDF p.20

• •Provide role-based access for SPV/HSIC, State, Centre and authorised monitoring or verification users. Each user should see only the records and actions relevant to their role and entity.
• •Source-populated fields should remain read-only. Any permitted correction should capture the reason, supporting evidence and user making the change.
• •Lock submitted quarterly records. Corrections should follow a controlled return-and-resubmit or amendment process.
• •Apply the same access controls to forms, dashboards, exports and system integrations.

6.3. Audit Trail and Data QualityPDF p.20

• •Maintain a complete history of source refreshes, SPV entries, evidence uploads, validations, State review, returns, resubmissions and final status.
• •Use common programme identifiers for SPV/HSIC, institution, learner, course and reporting period to reduce duplicate or mismatched records.
• •Validate mandatory fields, reporting period, source freshness and required evidence before submission.
• •Pass source, reporting period, validation status and provisional-data flags with monitoring data sent to Analytics.

6.4. Availability, Backup and RecoveryPDF p.20

• •Keep the Monitoring System available during quarterly reporting and review windows, with planned maintenance communicated in advance.
• •Back up submitted forms, evidence and audit records so an application or integration failure does not result in loss of monitoring information.
• •Restore the latest verified monitoring record after a failure and retain the audit history of subsequent corrections.

6.5. Integration and InteroperabilityPDF p.20

• •Use standard APIs for connected PM-SETU systems where available; use controlled batch exchange where an API is not available.
• •Integration failure in one source should not stop the complete monitoring form. Affected fields should be flagged for follow-up.
• •Use agreed common identifiers and reporting-period definitions across Monitoring, LMS, FMS/UC/Audit and Analytics so records can be reconciled consistently.

6.6. Usability and AccessibilityPDF p.21

• •Keep the quarterly monitoring form as a single, guided interface with clear separation between auto - filled information, SPV inputs and fields returned for correction.
• •Show validation messages against the relevant field and state the action required in simple language.
• •Support standard accessibility practices for keyboard use, readable labels and screen-reader compatible form controls.
• •Allow users to save progress before final submission where manual information or evidence is still being compiled.

6.7. Notifications and AlertsPDF p.21

• •Notify relevant users when a quarterly form opens, approaches its due date, becomes overdue, is returned for correction or is accepted.
• •Generate alerts for material DLI/KPI exceptions and stale source information without creating duplicate alerts for the same unresolved issue.
• •Keep notification status linked to the underlying monitoring record so follow-up can be tracked.

7. Process Designs and MockupsPDF p.21

The process designs below use the same swimlane/BPMN treatment as the other PM-SETU DPRs. The mockups illustrate screen structure and workflow intent; values are illustrative only.

7.1. Quarterly Monitoring ProcessPDF p.21

The quarterly process begins with notification and source pre-fill. The SPV works only on missing information and exceptions. The State can return selected fields rather than the complete form. Accepted quarterly snapshots feed Centre monitoring and Analytics.

BPMN / process flowPDF p.22

Tap to enlarge

7.2. Backend Information FlowPDF p.22

Source systems feed a common integration and validation layer. Monitoring combines validated source data with SPV-entered gaps, creates an auditable quarter snapshot, and passes qualified information to State/Centre review, Analytics and alerts.

Figure 3 — Process design: source-system capture to Monitoring, review, Analytics and alerts.

7.3. Q4 AOP GatePDF p.22

The Q4 control is intentionally simple: the next AOP entry is enabled after the SPV submits the Q4 monitoring form. State/Centre review may continue independently so the gate improves data discipline without creating an unnecessary approval bottleneck.

Architecture / overviewPDF p.22

Tap to enlarge

BPMN / process flowPDF p.23

Tap to enlarge

7.4. SPV Monitoring Form MockupPDF p.23

The SPV sees one consolidated page with reporting context, auto-filled DLI/KPI values, only the actions that require SPV input, risk/corrective-action fields, evidence and a final validation/submission control.

Wireframe / screenPDF p.24

Tap to enlarge

7.5. State Review MockupPDF p.24

State users see the quarterly submission queue, DLI exceptions and evidence gaps. Review is field-level: the State can return only the information requiring correction and accept the rest of the submission.

Wireframe / screenPDF p.25

Tap to enlarge

7.6. Centre Monitoring MockupPDF p.25

Centre users receive a programme-wide monitoring view focused on submission completeness, DLI/KPI position, data quality and exceptions requiring decision or escalation. Detailed operational records remain in the source systems.

Wireframe / screenPDF p.26

Tap to enlarge

8. Implementation ApproachPDF p.26

8.1. Recommended First ReleasePDF p.26

• •Single quarterly form with SSO, role/entity mapping, source tags, State review and submission history.
• •Priority pre-fill from LMS, FMS status/UC/Audit, SIDH/NCVT MIS, tracer/survey and official programme records.
• •DLI 1-6 monitoring structure, project/resource/risk tracking, evidence upload, validation and alerts.
• •Field-level return/resubmission so SPVs do not repeat the full submission.
• •Q4 submission gate before the next AOP can be entered.
• •Analytics feed containing qualified quarterly records with source and data-quality flags.

8.2. Subsequent EnhancementsPDF p.26

• •Increase API/event integrations and reduce batch/manual source updates.
• •Automate evidence checks where authoritative systems expose reliable document/status APIs.
• •Use operating data to refine exception rules, risk scoring and targeted reminders after the first implementation cycles.

9. Annexure: PM-SETU KPI FrameworkPDF p.27

The tables below provide the complete KPI framework used by the Monitoring System. They retain the KPI categories, weightages, annual applicability and targets from the approved KPI document. The operational calculations in Section 3 use these definitions and do not create a separate set of indicators.

9.1. Cluster Level KPI - Funding LinkedPDF p.27

2 CTS Enrolment 10

8 Female Placement 5

9.2. Cluster Level KPIs - Monitoring KPIsPDF p.28

- - 70% 80% 90%

9.3. National Level KPIsPDF p.29

9.4. State Level KPIsPDF p.29