Introduction
In a typical project, problems usually arise. For example, the customer reported a serious malfunction in the software that was delivered last week. You need someone to check what the cause is, fix it and then deliver a corrected version. This sequence involves many people and many different steps, which can lead to errors and disappointed customers.
This is why you need problem management.You need to reliably manage this process so all work steps are completed on time and that the solution is ready at the desired time.
I regard the following as the most important aspects of Problem Resolution Management in Automotive SPICE:
- Establish a problem resolution management strategy. Solving a problem requires dozens of people in different teams and locations. It is essential to coordinate these people and track the status of problems as they flow through the different steps, or the resolution will not be managed effectively. A good strategy makes it clear to all involved how the workflow is, how progress is controlled and who is responsible for what.
- Focus on urgent resolution actions. Let’s say you have a customer that performs integration tests in the field, but your device does not interact correctly with other devices, blocking the entire test process. The customers calls someone in your company and wants a solution. The problem is that your problem resolution process involves many steps and takes much more time than the customerexpects. Well, how do you deal with it?
Within your strategy, you have a definition of how to deal with such situations. This includes an accelerated process, for example, skipping some of the tests normally required. This, of course, involves some risks. Therefore, you also need to define who can authorize these types of shortcuts. Finally, you must specify how the process steps you have skipped are to be made up after the end of the urgent resolution case. With these simple steps, you can save valuable time, make customers happy, and still do everything your processes require. Make sure to train the people involved properly.
Here are some problems that might come up:
- Problem management is out of control because nobody is in charge.
- Problems get lost or stuck or are solved far too late.
- Developers don't have enough time to solve problems when a large number of problems come in.
In the strategy you should have a status model of the problems.
For example: New, in evaluation, in implementation, implementation completed, released, delivered, approved by customer. When developers perform the problem resolution process, they switch the status in their task management tool to the next status. Also, make sure you have someone who actively monitors the flow of the problems. This person should regularly create status reports or dashboards. These reports are evaluated in weekly technical sessions, where issues are discussed
and solutions agreed upon. Make sure that developers are not 100% busy developing new features and have enough time to resolve problems. Therefore, if you know when a large number of new issues will come up, make sure the developers have enough time left.
That is problem resolution management in short.
By following these points, you can better:
- Implement powerful problem management functionality.
- Troubleshoot problems.
- Avoid disappointed customers.
The purpose of the Problem Resolution Management process is to verify that problems are identified, analyzed, managed and controlled to resolution.
Best practice (BP1): Develop a problem resolution management strategy, including problem resolution activities, a status model for the problems, alert notifications, responsibilities for performing these activities and an urgent resolution strategy. Interfaces to affected parties are defined and definitions are maintained.
- Note 1: Problem resolution activities can be different during the product life cycle, e.g., during prototype construction and series development.
BP2: Identify and record the problem. Each problem is uniquely identified, described and recorded. Supporting information should be provided to reproduce and diagnose the problem.
- Note 2: Supporting information typically includes the origin of the problem, how it can be reproduced, environmental information, by whom it has been detected, etc.
- Note 3: Unique identification supports traceability to changes made.
BP3: Record the status of problems. A status according to the status model is assigned to each problem to facilitate tracking.
BP4: Diagnose the cause and determine the impact of the problem. Investigate the problem and determine its cause and impact in order to categorize the problem and to determine appropriate actions.
- Note 4: Problem categorization (e.g., A, B, C, light, medium, severe) may be based on severity, impact, criticality, urgency, relevance for the change process, etc.
BP5: Authorize urgent resolution action. If according to the strategy a problem requires an urgent resolution, authorization shall be obtained for immediate action also according to the strategy.
BP6: Raise alert notifications. If according to the strategy the problem has a high impact on other systems or other affected parties, an alert notification needs to be raised also according to the strategy.
BP7: Initiate problem resolution. Initiate appropriate actions according to the strategy to resolve the problem including review of those actions, or initiate a change request.
- Note 5: Appropriate actions may include the initiating of a change request. See SUP.10 for managing of change requests.
- Note 6: The implementation of process improvements (to prevent problems) is done in the process improvement process. (PIM.3) The implementation of generic project management improvements (e.g. lessons learned) are part of the project management process (MAN.3). The implementation of generic work product related improvements are part of the quality assurance process (SUP.1).
BP8: Track the status of problems to closure, including all related change requests. A formal acceptance has to be authorized before closing the problem.
BP9: Analyze problem trends. Collect and analyze problem resolution management data, identify trends, and initiate project related actions, according to the strategy.
- Note 7: Collected data typically contains information about where the problems occurred, how and when they were found, what were their impacts, etc.
Output work products
- Problem management plan
- Problem record
- Analysis report
- Evaluation report
- Problem status report
What is the benefit of Problem Resolution Management?
A systematic problem resolution management process helps resolveproblems effectively and reliably. Periodic analysis of the identified problems enables the organization to learn from these problems and failures, resulting in improved processes and outcomes.
What is the content of the problem resolution management process?
- A problem resolution management strategy is developed and implemented (BP1). It contains the activities, responsibilities, resources required and a life cycle model for the possible states of the problems.
- Each problem is identified, recorded (BP2) and the appropriate status is assigned (BP3). The status of the problem is updated as it follows thru the defined life-cycle.
- Its cause and impact are determined and a problem category is assigned (BP4).
- Resolution of the problem is initiated (BP7) and tracked to closure (BP8).
- Emergency measures or alarm messages are triggered for particularly urgent problems or serious effects on other systems (BP5, BP6).
- Problem data are collected and analyzed to determine trends and opportunities for improvement. These improvements are rolled back into the project and potentially the organization (BP9).
Considerations for typical challenges
- Problems need to be managed at all levels (customer, hardware, software etc.), not just software.
- Problems and change requests are often managed in a common tool, in which accepted problems flow smoothly into a change.
- Problems often occur with BP9 ”Analyze problem trends”. It is not enough to create charts, but actual analysis of the problems and trends need to take place.
- Analysis results can lead to corrective actions.
- Problems to be managed within this process are not just technical issues. For example: Customer problems, different interpretations of requirements, process problems, availability of resources, etc.
- When analyzing problems it is useful to determine causes (categories), affected components where the problem was found, where it was resolved, the effort required to resolve and record this data.
- The difference between BP5 and BP6 is often not well understood. BP5 deals with problems which need urgent action (like the customer performs field tests and wants a urgent fix). The point here is that this requires overruling normal procedures (e.g., reduced testing) which needs special approval. Therefore a clear procedure is needed including authorities for approvals. BP6 deals with the aspect that problems may impact others (like prototype cars need to be fixed or other projects that use the same software need to be notified). This may or may not trigger an urgent action according to BP5.
- Obviously, there is a relationship between SUP.9 and Risk Management (MAN.5) as risks which become problems are handled by this process.
Learn more about Automotive SPICE
If you want to learn more about Automotive SPICE®, check out our ASPICE Training.
About the author
Dr. Klaus Hoermann started working with SPICE back in 1998. Since then he has done hundreds of assessments and trainings. It is his passion to bring hard-to-understand models to life so that everyone can understand them.
To access the rest of this engaging content, please fill out the form below:
Please wait…