DGG Demand Tracker — User Guide

1. Purpose & scope

The SOP defines the end-to-end lifecycle for change requests to UNV systems — from intake and prioritization through development, acceptance testing, and delivery — so that every demand is treated through the same governance mechanism, with visibility into how digital budget is consumed.

In scope

• Enhancements to systems developed/managed by ICTS: UVP, Salesforce (Service Desk, CRM, VMF, Procure-to-Pay, Digital Admin, uCos Exception, Open Items), SharePoint, Data/BI, UNV Website, VRA, eCampus, SWVR, Partners Toolkit, Integrations
• UNV-specific change requests in Quantum
• New digital tools or functionality
• Platform / Cloud / Cybersecurity requirements

Out of scope

• Systems owned by UNDP/ITM (DocuSign, Zoom, Microsoft 365, UNALL, Apama) — follow UNDP's own change process
• Production bugs / incidents — report via the service desk (support@unv.org), not the Digital Demand form

2. Status pipeline — what each stage means

This is how the statuses shown in the Kanban board map to the SOP's process steps:

3. Submitting a demand

All requests must go through the Digital Demand form in Salesforce — ICTS will not assess, estimate, refine, prioritize, develop, or schedule anything submitted through another channel. The form captures:

• Requester information, Department/Pillar, and a named Focal Point (accountable for UAT sign-off)
• Problem statement & proposed solution
• Business impact & strategic alignment
• Business Sponsor / Budget owner

Requests missing mandatory fields cannot be submitted. Bug reports are not submitted this way — email support@unv.org instead.

4. Effort sizing (T-shirt sizes)

ICTS estimates every request on a rough garment-size scale during Req Assessment:

*Assumes developer day rates of $300–$650. ICTS owns the estimate and may revise it after requirement refinement.

5. DGG prioritization

The DGG prioritizes based on the business case and a high-level effort estimate — not detailed specifications, which would waste effort on requests that might never be built. Evaluation criteria:

• Strategic Alignment — which UNV goal does this support?
• Business Value / Impact — problem statement and estimated reach
• Legal / Security Compliance — is this required for compliance?
• Urgency — justification for why it cannot wait
• Dependencies — on external systems or other features
• Budget Availability — as identified at intake
• Operational Efficiency / Productivity Gain

If rejected, DGG must record a reason; rejection automatically closes the request. If requirement refinement later changes cost, complexity, value or scope materially, the request returns to DGG for reconfirmation before development begins. Every DGG decision is recorded in the Decision Log, right in the Tracker — click the clipboard icon on a demand's row (or "Decision Log" in its Details popup) to view its history or, for admins, log a new decision.

DGG membership: ICTS, VSS, VSC, ROs. The detailed decision-making process is defined in the DGG Prioritization Group ToR ↗ (see also §10 Related artifacts).

6. Definition of Ready (DoR) & requirement refinement

Once cleared by DGG, the requester and ICTS jointly produce the Definition of Ready — the binding agreement on what will be built. It includes:

• Business Objective & Functional Specifications (incl. UI/UX mock-ups where relevant)
• Out-of-scope items & Acceptance Criteria
• UAT assignment & testing strategy
• Documentation & training responsibilities
• Updated effort estimate based on detailed requirements

No delivery slot is reserved until the DoR is complete and signed off by the requester. If the refined effort estimate jumps a size category (e.g. M → L), the request goes back to DGG for re-approval.

7. Delivery: development, UAT, deployment

• Development & QA — ICTS builds the agreed scope; requesters can clarify but not expand scope.
• User Acceptance Testing — named UAT testers execute test cases and approve ("Approved for Production" / "Approved with Conditions") or reject/defer. Silence ≠ approval.
• Stabilization — ICTS fixes critical blockers and high-severity UAT issues only; a release readiness checklist covers documentation, training, support model and rollout confirmation.
• Production Deployment — code promoted, stability validated, and a standard communication plan notifies affected users with release notes and updated documentation.

8. Roles & responsibilities

9. Emergency exceptions

A highly restrictive emergency process exists for truly critical, unforeseen issues that pose an immediate severe risk (e.g. a security vulnerability, a legal/compliance deadline, a critical outage, data corruption) and cannot wait for the next release cycle.

• Requires written approval from the Section Chief, the DGG Chair(s), and the ICTS Chief
• A rapid impact assessment is completed within 48 hours
• All stakeholders and DGG are informed within 24 hours of approval
• A retrospective is completed within 14 days of deployment

Leadership preference, a missed internal deadline, or convenience do not qualify — those follow the standard process above.

10. Related artifacts