TEPR
Technical Problem Resolution
Linked Knowledge Nuggets:
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.
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.
# PROCESS PURPOSE
The purpose is to ensure that technical problems are recorded, analyzed, and tracked to closure.
# PROCESS OUTCOMES
-
O1
Technical problems are recorded, analyzed, categorized, and assessed to identify an appropriate solution
-
O2
Technical problem resolution is initiated
-
O3
Technical problems are consistently tracked to closure
-
O4
The status of problems and their trend are known
# BASE PRACTICES
BP1
Record technical problem, determine its cause and impact.
(
O1 )
Investigate the technical problem and determine its cause and impact to categorize the technical problem and to determine appropriate actions.
Note 1: Problem categorization may be based on severity, criticality (e.g., high, mid, low), or other criteria.
Linked Knowledge Nuggets:
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.
BP2
Initiate technical problem resolution.
(
O2 )
Initiate appropriate actions to technically resolve the problem and include review of those actions.
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.
BP3
Track problems consistently to closure.
(
O3 )
Ensure the solution by tracking the status of problems to closure.
Note 2: The controlled resolution of problems may involve authorization of action(s), relationships, and dependencies (parent/child) and the adherence to schedule.
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.
BP4
Analyze problem trends.
(
O4 )
Collect and analyze technical problem resolution management data and identify trends.
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 )
- 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:
- POPM Potential Project Management
- TEPR Technical Problem Resolution
15-55
Problem analysis evidence (
O1 )
- 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:
- TEPR Technical Problem Resolution
15-12
Problem status (
O3, O4 )
- Indicates progress of problem resolution
- Status of problem e.g.,
- by problem categories/classification
- by problem resolution stage
Used by these processes:
- POPM Potential Project Management
- TEPR Technical Problem Resolution
