SUP.9
Problem Resolution Management
Linked Knowledge Nuggets:
arrow_forward
"Problem Resolution Management"
person
Author: Process Fellows
SUP.9 – Problem Resolution Management ensures that technical and non-technical problems are captured, analyzed, and resolved in a traceable manner. It provides a structured approach from identification to trend analysis and closure.
-
school
PF_SUP.9_Problem Resolution Management_Extract.pdf
Short Overview of the SUP.9 Problem Resolution Management Process covering base practices, some examples and a comparion between Automotive SPICE® version 3.1 and 4.0
arrow_forward
"What is meant by the term “problem” in the context of SUP.9?"
person
Author: Process Fellows
Bugs aren’t the only problems. Unclear responsibilities, miscommunications, tool breakdowns – they all count. ASPICE expects you to log, analyze, and follow up on all kind of issues systematically.
arrow_forward
"When and How to use supporting processes"
person
Author: Process Fellows
Supporting processes like SUP.9 (Problem Resolution) or SUP.10 (Change Request Management) are often misunderstood as “back-office.” But they’re vital for delivering quality. Make sure your teams know when to invoke them — and how to record their outcomes. A 2-minute log of a problem review can save hours of debugging.
# PROCESS PURPOSE
The purpose of the Problem Resolution Management Process is to ensure that problems are identified, recorded, analyzed, and their resolution is managed and controlled.
# PROCESS OUTCOMES
-
O1
Problems are uniquely identified, recorded and classified.
-
O2
Problems are analyzed and assessed to determine an appropriate solution.
-
O3
Problem resolution is initiated.
-
O4
Problems are tracked to closure.
-
O5
The status of problems including trends identified are reported to stakeholders.
# BASE PRACTICES
intacs® Certified Provisional Assessor (Automotive SPICE®)
Sponsored
The official intacs® certified training to become an Automotive SPICE® Provisional Assessor.
Click for more details!
BP1
Identify and record the problem. (
O1, O4 )
Each problem is uniquely identified, described and recorded. A status is assigned to each problem to facilitate tracking. Supporting information is provided to reproduce and diagnose the problem.
NOTE 1: Problems may relate to e.g., product, resources, or methods.
NOTE 2: Example values for the problem status are “new”, “solved”, “closed”, etc.
NOTE 3: Supporting information may include e.g, the origin of the problem, how it can be reproduced, environmental information, by whom it has been detected.
NOTE 4: Unique identification supports traceability to changes made as needed by the change request management process (SUP.10).
BP2
Determine the cause and the impact of the problem.
(
O1, O2 )
Analyze the problem, determine its cause, including common causes if existing, and impact. Involve relevant parties. Categorize the problem.
NOTE 5: Problem categorization (e.g., light, medium, severe) may be based on severity, criticality, urgency, etc.
Linked Knowledge Nuggets:
arrow_forward
"Consistency vs. Traceability – What’s the Difference?"
person
Author: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward
"Root cause analysis in problem resolution"
person
Author: Process Fellows
Don’t just patch bugs. You should understand why the problem occurred. You may use 5 Whys, Ishikawa, or similar methods - when this is beneficial. It is not neccessary to always employ these methods, but: Implement systematic root cause analysis. Identify systemic issues – not just symptoms.
arrow_forward
"The role of traceability in risk control"
person
Author: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward
"The true benefit of traceability
"
person
Author: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP3
Authorize urgent resolution action.
(
O3 )
Obtain authorization for immediate action if a problem requires an urgent resolution according to the categorization.
Linked Knowledge Nuggets:
arrow_forward
"Example of an urgent resolution action process flow"
person
Author: Process Fellows
In case of critical issues, an urgent resolution action may be required, such as the implementation of a workaround or hotfix. It must be ensured that the underlying problem is subsequently addressed in a systematic and sustainable manner.
- Stakeholder Notification:
All relevant stakeholders are promptly informed about the issue and the proposed urgent action.
- Decision and Authorization:
The urgent resolution action is evaluated, decided upon, and formally authorized.
The decision is documented in the designated problem management tool.
- Initiation of Problem Resolution:
The process to resolve the root cause of the issue is initiated immediately.
Temporary vs. Permanent Solution:
If the urgent action only provides a temporary fix, a change request for a permanent solution must be created and tracked accordingly. The change request should include a trace link to the originating problem to ensure full traceability.
BP4
Raise alert notifications.
(
O3 )
If according to the categorization the problem has a high impact on other systems or other affected parties, an alert notification needs to be raised accordingly.
Linked Knowledge Nuggets:
arrow_forward
"When to raise an alert – practical examples"
person
Author: Process Fellows
There could be many scenarios where a notification about a problem should be send to relevant stakeholders (typically outside of the project, where the problem was identified). Do not mix this up with the need for urgent resolution or escalation. First of all we are talking about a notification only. But of course, depending on the impact of the problem, the notified stakeholders could ask for an urgent action.
- Example Scenario 1 – Cross-Project Component Dependency
- Context:
Project A is reusing a component or platform that was originally delivered and is currently maintained by another project, Project B.
- Situation:
Project A identifies a problem, and the root cause is traced back to the reused component from Project B. In this case, Project A must inform Project B about the issue.
- Urgency and Impact:
Depending on the severity and impact of the problem, this may require an urgent resolution action from Project B.
In addition, project B must assess whether the affected component is also being used by other projects (e.g., project C).
If so, project B is responsible for informing all dependent projects to ensure coordinated communication and risk mitigation.
- Example Scenario 2 - Cross-Generational Product Issue Escalation
- Context:
Project B is developing a "next-generation" version of a product that was originally created by Project A as the "first-generation" version.
- Situation:
During development, Project B identifies a problem. A root cause analysis reveals that the same issue also affects the first-generation product. Despite thorough qualification during its initial development, the problem was not detected earlier. The first-generation product is already in mass production and has been released to the market.
- Urgency and Impact:
Depending on the severity of the issue, corrective actions may include a product recall. Additionally, customers who have purchased the first-generation product may need to be proactively informed and warned about potential risks associated with continued use.
BP5
Initiate problem resolution. (
O3 )
Initiate appropriate actions according to the categorization to resolve the problem long-term, including review of those actions or initiate a change request. This includes synchronization and consistency with short-term urgent resolution actions, if applicable.
BP6
Track problems to closure.
(
O4, O5 )
Track the status of problems to closure including all related change requests. The closure of problems is accepted by relevant stakeholders.
Linked Knowledge Nuggets:
arrow_forward
"Problem monitoring and reporting – Leveraging ALM tools for effective tracking"
person
Author: Process Fellows
Problem status reports are often generated automatically by Application Lifecycle Management (ALM) tools. These reports are produced on a regular basis to support consistent tracking and reporting of open issues. They serve as a basis for initiating corrective actions—especially when problem trends show no improvement over time.
Recommended use of reports:
Reports should not only reflect the current status but also trigger action. For example, if the number of unresolved issues remains high or increases, this should prompt further analysis and corrective action.
Exemplary key metrics to monitor:
- Current problem status distribution:
Number of problems per status (e.g., open, in progress, resolved, closed).
- Overdue and aging issues:
Identification of problems that exceed their expected resolution time, including age analysis.
- Problem categorization:
Source of problem reports (e.g., internal vs. customer-reported).
Distribution by component or subsystem.
- Inflow vs. outflow trends:
Number of new problems reported per calendar week.
Number of problems resolved in the same period.
- Severity-based breakdown:
Reports should differentiate by severity level.
For instance, a backlog of minor issues may be acceptable, whereas unresolved critical or showstopper issues require immediate attention.
BP7
Report the status of problem resolution activities.
(
O5 )
Collect and analyze problem resolution management data, identify trends, and initiate related actions. Regularly report the results of data analysis, the identified trends and the status of problem resolution activities to relevant stakeholders.
NOTE 6: Collected data may contain information about where the problems occurred, how and when they were found, what their impacts were, etc.
Linked Knowledge Nuggets:
arrow_forward
"Problem monitoring and reporting – Leveraging ALM tools for effective tracking"
person
Author: Process Fellows
Problem status reports are often generated automatically by Application Lifecycle Management (ALM) tools. These reports are produced on a regular basis to support consistent tracking and reporting of open issues. They serve as a basis for initiating corrective actions—especially when problem trends show no improvement over time.
Recommended use of reports:
Reports should not only reflect the current status but also trigger action. For example, if the number of unresolved issues remains high or increases, this should prompt further analysis and corrective action.
Exemplary key metrics to monitor:
- Current problem status distribution:
Number of problems per status (e.g., open, in progress, resolved, closed).
- Overdue and aging issues:
Identification of problems that exceed their expected resolution time, including age analysis.
- Problem categorization:
Source of problem reports (e.g., internal vs. customer-reported).
Distribution by component or subsystem.
- Inflow vs. outflow trends:
Number of new problems reported per calendar week.
Number of problems resolved in the same period.
- Severity-based breakdown:
Reports should differentiate by severity level.
For instance, a backlog of minor issues may be acceptable, whereas unresolved critical or showstopper issues require immediate attention.
# OUTPUT INFORMATION ITEMS
13-07
Problem (
O1, O2, O3, O4 )
- Identifies the submitter of the problem
- Identifies the group/person(s) responsible for providing problem resolution
- Includes a description of the problem
- Identifies classification of the problem (criticality, urgency, relevance etc.)
- Identifies the status of the problem
- States such as “open”, “in review”, “in implementation”, “closed”, “rejected”, “cancelled”, …
- Transitions between states with conditions and authorities
- Identifies the expected closure date
Used by these processes:
- SUP.9 Problem Resolution Management
15-55
Problem analysis evidence (
O2 )
- Author and involved parties
- Date of the analysis
- Context and root cause of the problem
- Analysis result may include
- Impact
- Potential negative impact
- Affected parties
- Potential solution (if known)
Used by these processes:
- SUP.9 Problem Resolution Management
15-12
Problem status (
O5 )
- Indicates progress of problem resolution
- Status of problem e.g.,
- by problem categories/classification
- by problem resolution stage
Used by these processes:
- SUP.9 Problem Resolution Management
