Incident Management Process Requires Urgent Standardisation to Address Severe Delays and Rework
The current Incident Management process is characterised by operational instability and significant inefficiency. Analysis reveals an extremely fragmented workflow with 164 unique process variants for every 1,000 incidents, indicating a lack of standardisation. This is compounded by a high rework rate of 40.0% and a critical administrative bottleneck, where incidents wait an average of 168.9 hours between completion and final closure. These factors result in a long average duration of 256.3h and low value-add time. While foundational data is well-populated, the underlying process requires urgent intervention to establish a stable, predictable, and efficient workflow.
Process Health 3.4 / 10
Major Improvement Needed
Confidence: High
The assessment is driven by clear evidence of systemic inefficiency. The key issues are an extreme level of process fragmentation (164 variants), a high rework rate affecting 40.0% of incidents, and a critical 7-day administrative delay between work completion and case closure. These factors create significant waste and make performance unpredictable.
1.Process Health Summary
This summary provides the overall assessment score, confidence, key drivers, and supporting process metrics.
3.4 / 10
Process Health Score
Confidence: High
Incident Management Process is Unstable and Inefficient, Hindered by Extreme Fragmentation and Excessive Delays The Incident Management process.
Work items
1,044
Variants
164
Activities
6
Transitions
24
Avg transitions
4.8
Avg duration (hrs)
256.3
Rework rate
40.0%
Top bottleneck
Completed - Closed · 168.87h
Largest rework loop
Work in Progress - Completed · 792 items
Process Health AI summary: is in a weak state, characterized by a lack of standardization, significant rework, and severe delays. With 164 unique process variants for just over 1,000 incidents, there is no consistent workflow. A 40.0% rework rate indicates substantial wasted effort. The most significant delay is a 169-hour (7-day) administrative gap between work completion and final closure. While foundational data quality is strong, the operational chaos makes the process unpredictable and inefficient. Leadership must prioritize standardizing the workflow and automating the closure process to restore stability and reduce waste. The score is driven by a combination of critical issues: an extremely fragmented process (164 variants), a severe rework rate (40%), and very low flow efficiency (13%). A massive 169-hour administrative delay after resolution artificially inflates cycle times.
2.Headline Signals
Extreme Process Fragmentation
Variants
164 Variants
An exceptionally high number of process variations for the volume of work indicates a lack of a standard process, making the workflow unpredictable, difficult to manage, and challenging to automate.
High Rework Rate
Process
40.0%
Two in every five incidents require some form of rework, pointing to systemic issues with first-time resolution, information quality, or handoffs, which creates significant wasted effort and extends resolution times.
Major Administrative Bottleneck
Transitions
168.9 hours
A 7-day average delay to formally close an incident after it has been resolved artificially inflates performance metrics and represents the single largest period of non-value-add time in the process.
Low Flow Efficiency
Process
13.0%
Only 13% of the total incident lifecycle is spent in active 'touch' states. The vast majority of time is consumed by waiting in queues or administrative delays, highlighting major opportunities for streamlining.
Ineffective Work Prioritisation
Attributes
54.7% of Incidents are '5 - Planning'
The consistent overuse of the lowest priority level devalues the field, hindering the ability to triage urgent work effectively and allocate resources based on business impact.
3.Curated Findings
The following findings represent the highest-priority improvement areas identified from the assessment evidence.
Process Health 13.0% flow efficiency, meaning most elapsed time is not active work.; Administrative delay after work completion is called out as the largest bottleneck, averaging about 160 hours.; Average resolution performance is materially affected by post-resolution handling rather than technical resolution alone.
Recommended response: Separate technical resolution from closure administration and redesign the post-resolution states so completed incidents do not sit idle.
2
Incident workflow is highly fragmented
HighStrongNeeds ReviewGovernance
Evidence
Process Health identifies 164 different process paths for the incident sample.; The same assessment reports a 40.0% rework rate.; High path variation makes root-cause analysis, SLA management and automation targeting harder.
Recommended response: Define a smaller set of standard incident pathways and remove avoidable status loops.
3
Rework is creating avoidable effort and inconsistent outcomes
HighStrongNeeds ReviewPerformance
Evidence
Process Health reports a 40.0% rework rate for incidents.; The workflow has 164 process variants, suggesting repeated detours and non-standard handling.; Rework increases lead time and reduces predictability for operational teams.
Recommended response: Identify the activities and segments with the highest rework signal, then address the underlying routing or closure-quality causes.
4
Classification and closure data should be improved before automation
MediumModerateNeeds ReviewData Quality
Evidence
Process Health highlights the need to improve work classification before meaningful automation.; Segments such as close code, contact type and priority can be used to identify where resolution behaviour differs.; Poor classification reduces the reliability of AI recommendations and automation rules.
Recommended response: Use classification fields as a governance control, not just reporting metadata.
4.Curated Improvement Actions
Consultant-curated actions from the assessment workbench, translating the findings above into practical improvement work for client follow-up. AI-generated priority recommendations appear later in this report.
1. Map current resolved/closed states and owners. 2. Remove redundant closure queues. 3. Add auto-close rules where customer feedback is not required. 4. Track admin delay weekly.
Evidence basis
Administrative delay and low flow efficiency are the dominant signals.
Target / Success Measure: Reduce average admin delay by 30% and improve flow efficiency above 15%.
2
Standardise the top incident paths
Priority: HighValue: HighEffort: MediumProposed
Action / implementation
1. Review top variants by volume. 2. Identify required vs avoidable detours. 3. Define target standard paths. 4. Update guidance and workflow controls.
Evidence basis
164 process variants indicate weak workflow standardisation.
Target / Success Measure: Top 10 variants account for a higher share of work and total variants reduce by 25%.
3
Create a rework reduction backlog
Priority: HighValue: HighEffort: LowProposed
Action / implementation
1. Segment rework by close code, contact type and priority. 2. Identify recurring loopbacks. 3. Assign improvement owners. 4. Track rework by segment.
Evidence basis
40.0% rework rate indicates repeated loopback or unresolved handoff issues.
Target / Success Measure: Reduce incident rework rate from 40% to below 25%.
4
Clean up incident classification governance
Priority: MediumValue: MediumEffort: LowProposed
Action / implementation
1. Review active values for priority, close code and contact type. 2. Remove duplicates or ambiguous values. 3. Add mandatory rules where needed. 4. Publish field usage guidance.
Evidence basis
Classification quality affects segmentation, AI recommendations and automation targeting.
The process has 164 unique variants for 1,044 work items, and the single most common path is followed by only 28% of incidents.
Interpretation
There is no consistently followed standard operating procedure for handling incidents. Teams appear to be following numerous ad-hoc paths, leading to process chaos and unpredictability.
Business Effect
This results in inconsistent service levels, an inability to forecast resolution times reliably, and significant barriers to implementing effective training, automation, or process improvements.
2
Systemic Post-Resolution Latency
Evidence
The transition from the 'Completed' status to 'Closed' takes an average of 168.9 hours (approximately 7 days), which is the single longest delay in the process.
Interpretation
A severe, systemic bottleneck exists after all practical work on an incident is finished. This is likely due to manual closure procedures, batch jobs, or a lack of automated closure rules in the system.
Business Effect
This latency artificially inflates key resolution metrics, delays accurate reporting, and consumes administrative resources on a zero-value-add activity, masking the true performance of the active resolution process.
3
Ineffective First-Time Resolution
Evidence
40.0% of all incidents undergo rework, with common process loops observed between 'Work in Progress', 'Pending', and 'Open' statuses.
Interpretation
Frequent regressions to earlier lifecycle stages suggest that incidents are not being diagnosed or resolved correctly on the first attempt. This could stem from poor initial data capture, incorrect routing, or incomplete information.
Business Effect
This leads to significant wasted effort, increased resolution times, and a frustrating experience for both support agents and end-users, directly undermining team productivity and service quality.
4
Weak Data Governance Impedes Prioritisation
Evidence
Over half (54.7%) of all incidents are logged with the lowest priority, '5 - Planning'. Additionally, the 'Category' field contains only a single value ('Incident'), offering no analytical value.
Interpretation
Key classification fields are not being used as intended for effective workload management. They function as simple metadata rather than active governance controls for routing and prioritisation.
Business Effect
This undermines the ability to prioritise critical work, creates a risk of missing service level targets for high-priority issues, and provides unreliable data for strategic decision-making and trend analysis.
6.Priority Recommendations
Rec
1
Automate the Administrative Closure Delay
CriticalAutomation
Action
Modify the system business rule governing the transition from 'Completed' to 'Closed' status. Reduce the current multi-day delay to a maximum of 4-8 hours to reflect a reasonable confirmation window.
Strategic Driver
This 7-day delay is the largest single source of waste in the process, affecting 93% of incidents and severely distorting all performance metrics. It is the fastest, highest-impact change to make.
Target / Success Measure
Achieve accurate end-to-end resolution time reporting, leading to a 30-40% reduction in the reported average ticket duration and focusing improvement efforts on true operational bottlenecks.
Owner
Platform Engineering / ITSM Admin
Rec
2
Standardise the Core Incident Workflow
HighGovernance
Action
Analyse the top 10 process variants to define a standard 'happy path' and a small number of acceptable deviations. Update workflow rules, automation, and team guidance to eliminate chaotic paths, particularly the 'Work in Progress' to 'Open' regression.
Strategic Driver
The current lack of standardisation, evidenced by 164 variants, makes the process unmanageable and prevents any meaningful improvement. Stabilising the workflow is a prerequisite for effective automation and performance management.
Target / Success Measure
Reduce process variants by over 50% and decrease the volume of the 'WIP -> Open' transition by 80%, leading to more predictable resolution times and a stable foundation for continuous improvement.
Owner
Incident Process Owner
Rec
3
Establish Clear Governance for the 'Pending' State
HighOperating Practice
Action
Define and publish strict, mandatory entry and exit criteria for using the 'Pending' status. Implement automated reminders and escalations for tickets that remain in 'Pending' for more than 48 hours without an update.
Strategic Driver
Ambiguous use of the 'Pending' state is a major driver of the 40.0% rework rate and introduces significant, uncontrolled delays into the process. Clarifying its use is key to reducing process churn.
Target / Success Measure
Reduce ticket 'ping-pong' between statuses, shorten active resolution times, and create clearer accountability for ticket progression, contributing to a lower overall rework rate.
Owner
Incident Process Owner / Service Desk Lead
Rec
4
Remediate Incident Classification and Priority Fields
MediumGovernance
Action
Review and rationalise the values for 'Priority' and 'Subcategory' to ensure they are meaningful and actionable. Provide clear guidance and training on correct usage, and consider making key fields mandatory with better default values to improve data quality at the source.
Strategic Driver
Poor classification, especially the chronic overuse of 'Priority 5 - Planning', hinders effective workload management, SLA tracking, and reporting. Improving data discipline is essential for data-driven service management.
Target / Success Measure
Improve the ability to prioritise critical work, leading to more accurate SLA measurement and a reduction in the use of the '5 - Planning' classification to below 10% of total volume.
Owner
Head of Service Management
7.AI & Automation Opportunities
Targeted Automation to Eliminate Waste and Accelerate Flow
The automation strategy focuses on immediate, high-impact opportunities to remove process friction. The primary target is the automated closure of resolved incidents to eliminate the 7-day administrative delay. Secondary automations will include time-based reminders and escalations for incidents in a 'Pending' state to prevent them from becoming stalled, ensuring timely progression.
AI Opportunities
Automate Incident Closure and Govern 'Pending' State Transitions
Evidence basis: The 168.9-hour delay from 'Completed' to 'Closed' and the high volume of rework loops involving the 'Pending' state, which affects over 38% of incidents and adds an average of 47 hours of delay.
How to implement: Automated Incident Closure Rule
Assessment relevance: These are the two most significant opportunities to reduce waste and improve flow. Automating closure provides a quick win with a massive impact on metrics, while governing the 'Pending' state with automated reminders tackles a root cause of rework and delay.
8.Future State Summary
A Standardised, Efficient, and Data-Driven Incident Management Process
The future state will operate on a highly standardised workflow where the vast majority of incidents follow a predictable and efficient path. Administrative delays will be eliminated through automation, providing a true and timely picture of performance. Rework will be significantly reduced through clear state definitions and improved first-time resolution, freeing up capacity for value-adding work. Robust data governance will ensure incidents are correctly prioritised and routed, enabling proactive management and continuous improvement.
Design Principles
Standardise Before Optimising
Automate All Non-Value-Add Activities
Enforce Data-Driven Prioritisation
Measure and Improve First-Time Resolution
9.Implementation Roadmap Summary
A Phased Approach to Restore Stability and Drive Efficiency
The implementation roadmap prioritises foundational fixes to stabilise the process before moving to optimisation. The initial phase will focus on the critical closure delay and the most damaging rework loops. Subsequent phases will address broader process standardisation, data governance, and the establishment of performance measurement dashboards to drive continuous improvement.
Phases
1
Month 1
Foundational Stability (Fix Closure Delay & Critical Rework) — Prioritise the closure-delay fix, rework controls, ownership, and baseline KPI reporting so improvement is measurable from week one.
2
Months 2-3
Process Standardisation & Data Governance — Pilot intelligent triage and routing against high-quality classification data, then measure first-time assignment accuracy and triage elapsed time.
3
Months 4-6
Performance Measurement & Continuous Improvement — Lock in standard paths, transition controls, SOPs, and governance routines so teams operate from a stable process baseline.
10.Expected Outcomes
↓ Reduce
Reduced End-to-End Resolution Time
Provides a faster, more consistent service to end-users and improves the accuracy of performance reporting by eliminating artificial administrative delays.
↓ Reduce
Decreased Process Rework
Increases team capacity by eliminating wasted effort, improves process predictability, and leads to a better end-user experience.
↑ Increase
Increased Process Standardisation
Lowers operational complexity, simplifies onboarding and training, and creates a stable baseline required for future automation and improvement initiatives.
↗ Improve
Improved Data-Driven Prioritisation
Ensures that the most critical incidents receive attention first, improving alignment with business needs and adherence to service level agreements.
11.Governance Guardrails
Standard Path Adherence Monitoring
Continuously monitor the percentage of incidents following the defined standard workflow. Investigate significant deviations to understand if they represent genuine exceptions or non-compliance with the new process.
State Transition Discipline
Enforce strict entry and exit criteria for all lifecycle statuses, particularly 'Pending' and 'Work in Progress', to prevent misuse and reduce the likelihood of rework.
Classification Field Integrity
Regularly audit the usage of key fields like 'Priority' and 'Subcategory' to ensure they are being used consistently and correctly for routing, prioritisation, and reporting.
Benefit Realisation Tracking
Establish a performance dashboard to continuously measure key metrics (e.g., rework rate, closure delay, flow efficiency) to validate that process changes are delivering the expected benefits and to identify new opportunities.
12.Workflow Evidence
This view translates the transition evidence into the operating story of the workflow: the likely core path, administrative delay points, and the main rework loops that should be investigated.
Core path evidence
Start
→
Work in Progress
→
Completed
→
Closed
Start → Work in Progress 592 items · 0.00h avg
Work in Progress → Completed 792 items · 28.10h avg
The largest delay appears after the work is already marked completed. This can make operational performance look much worse than technical resolution performance and is a strong candidate for auto-close rules, customer confirmation policy, or closure governance.
Waiting loop: Work in Progress ↔ Pending
Work moves from active handling into waiting and back again. Evidence: WIP → Pending 289 items · 12.06h avg; Pending → WIP 399 items · 47.32h avg. This usually points to missing information, dependency waits, or unclear handoff criteria.
Regressive cycle: Work in Progress ↔ Open
Work returns from active handling to the intake/open queue. Evidence: WIP → Open 182 items · 16.65h avg; Open → WIP 179 items · 62.99h avg. This is a stronger rework signal because it suggests triage, routing, or qualification failure.
Highest-volume transition evidence8 shown
Completed → Closed
976 items · 168.87h average
Work in Progress → Completed
792 items · 28.10h average · rework / loop signal
Start → Work in Progress
592 items · 0.00h average
Pending → Work in Progress
399 items · 47.32h average · rework / loop signal
Work in Progress → Pending
289 items · 12.06h average · rework / loop signal
Start → Pending
214 items · 0.00h average
Work in Progress → Open
182 items · 16.65h average · rework / loop signal
Open → Work in Progress
179 items · 62.99h average · rework / loop signal
13.Detailed Process Evidence
The following evidence highlights the process patterns, bottlenecks, rework signals, and attribute patterns supporting the assessment.
Top variants by work item volumeTop 10
Shows the dominant paths and how concentrated or fragmented the process is. Low coverage by the top path usually indicates exception handling, inconsistent practice, or uncontrolled variation.
#
Evidence item
Metric
Signal
1
Work in Progress -> Completed -> Closed
291 work items · 182.6h avg duration
291
Common pathway
2
Completed -> Closed
156 work items · 168.6h avg duration
156
Common pathway
3
Pending -> Work in Progress -> Completed -> Closed
83 work items · 229.6h avg duration
83
Common pathway
4
Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
58 work items · 272.3h avg duration
58
Contains rework or loop behaviour
5
Work in Progress -> Open -> Work in Progress -> Completed -> Closed
52 work items · 350.6h avg duration
52
Contains rework or loop behaviour
6
Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
38 work items · 228.7h avg duration
38
Contains rework or loop behaviour
7
Closed
38 work items · 0h avg duration
38
Common pathway
8
Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
20 work items · 440.8h avg duration
20
Contains rework or loop behaviour
9
Pending -> Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
14 work items · 362.5h avg duration
14
Contains rework or loop behaviour
10
Completed
14 work items · 0h avg duration
14
Common pathway
Slowest transitions by average hoursTop 10
Ranks the transitions creating the greatest elapsed-time drag. These are high-value candidates for bottleneck review, automation, SLA tuning, or process redesign.
#
Evidence item
Metric
Signal
1
Completed - Closed
Completed → Closed · 976 work items · 168.87h avg
168.9h
Bottleneck candidate (168.9h avg)
2
Open - Completed
Open → Completed · 9 work items · 128.12h avg
128.1h
Bottleneck candidate (128.1h avg)
3
Pending - Completed
Pending → Completed · 46 work items · 122.92h avg
122.9h
Bottleneck candidate (122.9h avg) · loop signal
4
Open - Work in Progress
Open → Work in Progress · 179 work items · 62.99h avg
63.0h
Bottleneck candidate (63.0h avg) · loop signal
5
Pending - Work in Progress
Pending → Work in Progress · 399 work items · 47.32h avg
47.3h
Bottleneck candidate (47.3h avg) · loop signal
6
Open - Pending
Open → Pending · 80 work items · 44.56h avg
44.6h
Bottleneck candidate (44.6h avg) · loop signal
7
Pending - Open
Pending → Open · 62 work items · 39.60h avg
39.6h
Bottleneck candidate (39.6h avg) · loop signal
8
Completed - Work in Progress
Completed → Work in Progress · 28 work items · 36.10h avg
36.1h
Bottleneck candidate (36.1h avg) · loop signal
9
Completed - Pending
Completed → Pending · 21 work items · 31.14h avg
31.1h
Bottleneck candidate (31.1h avg) · loop signal
10
Work in Progress - Completed
Work in Progress → Completed · 792 work items · 28.10h avg
28.1h
Bottleneck candidate (28.1h avg) · loop signal
Highest-volume transitionsTop 10
Highlights the paths where small improvements can have broad operational impact because they touch the highest number of work items.
#
Evidence item
Metric
Signal
1
Completed - Closed
Completed → Closed · 976 work items · 168.87h avg
168.9h
Bottleneck candidate (168.9h avg)
2
Work in Progress - Completed
Work in Progress → Completed · 792 work items · 28.10h avg
28.1h
Bottleneck candidate (28.1h avg) · loop signal
3
Start - Work in Progress
Start → Work in Progress · 592 work items · 0.00h avg
0h
High-volume improvement lever
4
Pending - Work in Progress
Pending → Work in Progress · 399 work items · 47.32h avg
47.3h
Bottleneck candidate (47.3h avg) · loop signal
5
Work in Progress - Pending
Work in Progress → Pending · 289 work items · 12.06h avg
12.1h
Loop / regressive signal
6
Start - Pending
Start → Pending · 214 work items · 0.00h avg
0h
High-volume improvement lever
7
Work in Progress - Open
Work in Progress → Open · 182 work items · 16.65h avg
16.7h
Loop / regressive signal
8
Open - Work in Progress
Open → Work in Progress · 179 work items · 62.99h avg
63.0h
Bottleneck candidate (63.0h avg) · loop signal
9
Start - Completed
Start → Completed · 173 work items · 0.00h avg
0h
High-volume improvement lever
10
Open - Pending
Open → Pending · 80 work items · 44.56h avg
44.6h
Bottleneck candidate (44.6h avg) · loop signal
Rework / loop transitions12 shown
Rework and loop transitions identify where work moves backwards or cycles between activities. These are strong signals for triage defects, unclear ownership, poor handoffs, or missing information.
Transition
From Activity
To Activity
Work Items
Avg Deviation (Hrs)
Is Rework?
Work in Progress - Completed
Work in Progress
Completed
792
28.10
true
Pending - Work in Progress
Pending
Work in Progress
399
47.32
true
Work in Progress - Pending
Work in Progress
Pending
289
12.06
true
Work in Progress - Open
Work in Progress
Open
182
16.65
true
Open - Work in Progress
Open
Work in Progress
179
62.99
true
Open - Pending
Open
Pending
80
44.56
true
Pending - Open
Pending
Open
62
39.60
true
Pending - Completed
Pending
Completed
46
122.92
true
Completed - Work in Progress
Completed
Work in Progress
28
36.10
true
Completed - Pending
Completed
Pending
21
31.14
true
Closed - Closed
Closed
Closed
21
0.00
true
Work in Progress - Work in Progress
Work in Progress
Work in Progress
3
0.19
true
Metrics detail1 shown
Baseline metrics provide the numerical context for the assessment and should be used to validate the narrative recommendations.
Work Items
Variants
Activities
Steps
Avg Transitions
Avg Duration
Std Deviation
1044
164
6
24
4.8
256.27
269.23
Field / attribute evidence7 shown
Attribute evidence shows whether segmentation, routing, classification and automation recommendations are supported by reliable data. Top values are formatted from the source distribution rather than raw objects.
Field
Type
TotalTasks
TopValues
Assignment Group
Work Item
1044
Computer/Accessories306Application Services217Mobile / Cell Phones78Finland Business Applications64ERP Solutions53Email47Engineering Software46Shared files and folders45
Category
Work Item
1044
Incident1044
Close Code
Work Item
1044
Solved (Permanently)649Solved Remotely (Permanently)315Closed/Completed by Caller22No feedback from user18Solved (Work Around)14Not Solved (Request Denied)11Solved Remotely (Work Around)11Request created2
Company
Work Item
1044
Merck India Private Limited203Merck Danmark A/S201Merck Finland Oy146Merck Norge AS98Merck US Corporation66Merck UK Ltd60ServiceNow57Merck Sweden AB51
Access94I have a Question92PC66Software Installation59Password Reset52N/A40Mobile Device34Access to File Share (Internal)33
14.Consultant Note
The primary challenge in this process is a fundamental lack of discipline, which manifests as extreme fragmentation, high rework, and a severe administrative bottleneck. The proposed recommendations are highly interdependent: standardising the workflow is essential to reducing rework, and fixing the closure delay is crucial for accurate performance measurement. Addressing these foundational stability issues must be the immediate priority before any more advanced optimisation is attempted.
15.Evidence Appendix
Appendix — top variants15 shown
Variant
ID
Work Items
Is Rework
Loops
Avg Duration (Hrs)
Work in Progress -> Completed -> Closed
0
291
false
0
182.64
Completed -> Closed
7
156
false
0
168.57
Pending -> Work in Progress -> Completed -> Closed
4
83
false
0
229.63
Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
9
58
true
1
272.31
Work in Progress -> Open -> Work in Progress -> Completed -> Closed
10
52
true
1
350.56
Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
8
38
true
2
228.72
Closed
22
38
false
0
0.00
Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
17
20
true
3
440.80
Pending -> Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
24
14
true
4
362.52
Completed
99
14
false
0
0.00
Work in Progress -> Open -> Pending -> Work in Progress -> Completed -> Closed
5
12
true
1
309.12
Pending -> Completed -> Closed
13
12
false
0
386.07
Work in Progress -> Open -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed
30
12
true
2
281.49
Work in Progress -> Completed
69
9
false
0
5.32
Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Pending -> Work in Progress -> Completed -> Closed