Datasets for measuring conversion from demand for local workaround tools to…

Research Question

What public or internal datasets can validly measure the rate at which demand for local workaround tools, such as local apps, flows, lists, or spreadsheets, is converted into formal central Information Technology (IT) backlog items?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

No consulted public benchmark dataset directly measures the rate at which enterprise manual workaround demand becomes formal central Information Technology backlog work, so valid measurement depends on joining internal workaround-signal datasets to governed backlog datasets with durable origin links. The strongest workaround-side datasets in scope are Power Platform inventory, audit-log, and governance datasets because they record local apps and flows, ownership, usage, and business justification before central escalation. A centralized demand or backlog dataset, such as ServiceNow Demand Management or equivalent Jira or GitHub work-item datasets with enforced origin fields, is needed on the target side of the metric. The critical design choice is not tool brand but measurement grain: count distinct workaround signals for one service or workflow class, preserve the link table to formal backlog records, and retain history so closed or deleted records do not disappear from the rate.

Key Findings

1. No consulted public benchmark dataset directly publishes enterprise manual-workaround signals linked to formal central Information Technology backlog outcomes, so external sources in scope are mainly useful for metric design, field discovery, and method testing rather than for direct rate benchmarking.
2. Jira can support conversion measurement when organisations search the candidate issue set with Jira Query Language, preserve custom fields for workaround origin, and use bulk changelog histories instead of current issue status alone to reconstruct backlog entry and completion timing.
3. GitHub issue datasets can support the same measurement pattern through state, labels, milestones, timestamps, and timeline events, and public repositories make GitHub the strongest public surrogate dataset in scope for testing conversion logic before applying it to private enterprise data.
4. Power Platform governance datasets provide strong demand-side coverage because inventory records expose owners, environments, and timestamps, audit-log flows add launches and unique-user telemetry, and governance components capture business justification, impact, dependencies, and mitigation details for locally built solutions.
5. ServiceNow Demand Management is explicitly designed to capture, centralize, assess, and prioritize business and operational demands before promotion into formal delivery work, which makes it a credible target-side dataset when that module is implemented.
6. The defensible conversion denominator is distinct workaround signals within one application, service, environment, or workflow class, because both metric-design guidance and prior repository work show that mixed units and blended populations make comparison misleading.
7. Month-over-month conversion tracking is invalid without retained history or periodic snapshots, because current-state tables hide deleted, closed, merged, or reclassified records and therefore bias the numerator and denominator toward whatever records still survive later.
8. The highest-risk failure mode is weak origin linkage between local workaround artifacts and governed backlog records, because text-only matching and late manual linkage can make conversion appear stronger or weaker than it actually is without proving a true escalation pathway.

Assumptions

• Manual workaround demand is operationally proxied by local solutions and governance records that exist because the central path did not meet the need quickly enough.
• A conversion event should be counted only when the origin signal and target backlog record are linked in a durable system field, relationship, or link table rather than inferred only from text similarity.
• Starting at one service or workflow class is preferable to an enterprise-wide blended rate because the application-level measure is more likely to stay comparable and decision-useful.

Analysis

The core evidence pattern is asymmetrical: public sources tell us how to structure the metric, while internal operational systems provide the records needed to compute it. That asymmetry makes the workaround-side dataset choice especially important, because demand is usually hidden first in local apps, flows, lists, or issue queues rather than in central portfolio tools. Power Platform governance data is strong on that hidden-demand side, while ServiceNow Demand Management is strong on the formal-intake side; Jira and GitHub are flexible enough to play either role when organisations enforce origin fields and lifecycle conventions. The main trade-off is between faster implementation and stronger validity: text-matched joins are cheaper, but durable origin IDs and history retention are what make the rate auditable and defensible. A plausible rival interpretation is that public issue trackers alone are enough because they expose lifecycle fields and events, but those datasets only capture work that has already been raised in a tracked system and therefore cannot directly measure hidden enterprise workaround demand.

Risks, Gaps, and Uncertainties

• Public cross-organisational benchmark coverage remains thin, so external comparison of absolute conversion rates is weak even when internal measurement is good.
• The consulted ServiceNow evidence is sufficient to support centralized-intake claims, but it is thinner than the Microsoft, Atlassian, and GitHub evidence because this item relies mainly on one readable ServiceNow demand-intake source.
• Hidden local workarounds that never enter inventory, governance, or issue-tracking systems will still bias the denominator downward.
• The evidence base is stronger on schema and measurement design than on published empirical distributions of actual conversion performance.

Open Questions

• Which backlog-state transitions should count as "converted" in organisations that use multi-stage triage before formal prioritization?
• How should the metric treat one workaround signal that deliberately spawns several backlog items across integration, data, and user-interface teams?
• What sampling or survey method best estimates hidden workaround demand that never appears in any system-of-record dataset?

sources

• [ ] Google Cloud DevOps Research and Assessment overview - seeded page checked; not used for downstream claims
• [x] DevOps Research and Assessment (DORA) (2026) DORA's software delivery performance metrics - official metric definitions, scope cautions, and notes on data coming from multiple systems
• [x] Atlassian Jira Cloud REST issue search documentation - issue search fields and search result structure
• [x] Atlassian Jira Cloud REST issues documentation - bulk changelog fetch and issue-history extraction
• [x] Atlassian Jira Cloud REST issue fields documentation - system and custom field discovery
• [x] GitHub Docs REST issues documentation - issue state, timestamps, labels, milestones, and assignee fields
• [x] GitHub Docs REST timeline events documentation - timestamped lifecycle events for issues
• [x] GitHub Docs issue event types reference - semantics of labeled, assigned, closed, commented, and related timeline events
• [x] Microsoft Learn (2026) Power Platform Center of Excellence (CoE) Starter Kit - governance and telemetry positioning, plus the shift to native admin-center inventory
• [x] Microsoft Learn (2026) Set up inventory components - resource inventory synced into tables for apps, flows, and makers
• [x] Microsoft Learn (2026) Collect audit logs using Microsoft Graph Application Programming Interface (API) - app launches and unique-user telemetry
• [x] Microsoft Learn (2026) Use governance components - business justification, business impact, dependency, and mitigation-plan fields
• [x] Microsoft Learn (2026) Power Platform inventory - tenant-wide inventory, filtering, owner data, and export surface
• [x] Microsoft Learn (2026) Power Platform inventory schema reference - queryable fields such as owner, environment, created, and modified timestamps
• [x] Microsoft Learn (2026) Power Platform inventory Application Programming Interface (API) - query structure, joins, projections, and count queries
• [x] ServiceNow Community (2023) Quick start guide for Demand Management - centralized intake, demand assessment, and promotion framing
• [x] National Institute of Standards and Technology (NIST) Special Publication (SP) 800-55 Revision 1 landing page - official measurement-design reference used for repeatable, quantifiable, comparable, and decision-useful metric criteria
• [x] Mitchell (2026) Temporary Automation Demand Persistence and Core Capability Investment Displacement - prior completed item on persistent workaround demand and governance implications
• [x] Mitchell (2026) Control deficiencies from bypassing designated workforce record platforms - prior completed item on derivative-record and origin-link failures
• [x] Mitchell (2026) Empirical evidence on rollout of organisation-wide low-code and no-code programs - prior completed item on citizen-development governance and shadow demand
• [x] Mitchell (2026) Matched denominator for comparing post-pipeline release-based failures with production live-runtime incidents - prior completed item on denominator discipline and comparable measurement units