User Modules

Problem resolution process area is necessary part of all quality management systems. The problem management shall be managed both in the project and in general business. Sure, it is also part the quality control.

Problem logging refers to a wider group of events that often have a separate name in the business terminology. In AyMINE, it is possible to distinguish individual types by using a client-defined counter in accordance with the company methodology:

Disagreement – Deviation from the standard, typically identified by an internal audit. Disagreement may not result in a fault
Problem – Uncertainty about the solution e.g. during development, but also e.g. a problem in production (occurring faults)
Faulty – A bad output that does not meet any of the input requirements.
Initiative – A suggestion, comment or warning from anyone on the research team. Further analysis usually finds out how to classify it in more detail – e.g. as a problem, but also e.g. a suggestion for improvement.

Life cycle of a problem

Every problem should be recorded as soon as possible when it occurs. Of course, only if it is not solved immediately (then it is probably not a problem)

When a problem is recorded, it remains "active", i.e. solved until termination. In AyMINE, a problem has essentially the same life cycle as a task or a request. It is assumed that someone will take charge of the problem elimination, until then it can remain open without a solver.

Recording the problem

Most process methodologies require that all or most of the data below be recorded. Check your organisation's own methodology, what exactly is requires.

Creation of the problem

The documentation when setting up a problem record should include:

Description of how the problem manifests
Identification of who and when reported the problem (not necessarily the person who recorded it)
When the problem began to manifest, arose or was first discovered
Who is in charge of the problem

Solving the problem

Records should be created as part of the next analysis:

Problem cause – Its findings may require more detailed analysis, e.g. Root-cause, Fishbone, 8D report, etc. These analyses should be attached as they are an important documentation of the process. The cause is documented on a custom tab in detail.
Problem resolution procedure – What events and findings were performed in solving the problem:
Events: Documented in the form of an event (activity tab)
Discovery: Recorded in the solution procedure (below the actual description of the problem). When it comes to assumptions, things to discuss or suggestions, we recommend documenting in the discussion of the problem. Note: the discussion is archived in the same way as the object itself and is therefore a solution documentation that can be revised and audited afterwards.

Problem resolution states

New – after creation, the problem is still not being addressed
Free to resolve – The problem was marked by the "administrator" as waiting for someone to take charge of it
In resolution – The problem is being handled by someone
Solved – The problem has been resolved and is waiting for confirmation by the administrator. If the problem is directly resolved by the administrator, the problem does not get into this state at all
Finished – The problem has been completely resolved. The problem gets into the state either by resolving it by the administrator or by confirming that the problem is resolved (by the administrator when someone else has solved it)
Excluded – The problem has ceased to make sense to solve. The solver can manually convert it into this state with a command. The problem is discarded, for example, if it related to a job that was cancelled.

Problem documentation

Problems can remain open in general for however long. The system does not have a tool to evaluate the urgency of a problem and therefore does not generally provide a solution. However, the issue should indicate by when it is to be resolved, and issues that exceed that date are highlighted on the workspace.

But documenting the problem has other benefits as well:

Increased interchangeability of team members, who can more easily communicate the agenda to be addressed.
Passing the experience on to other and later projects that can gain experience of what to watch out for and what to expect that may occur
With good documentation of the solution to the problem, experience of how to deal with the problem can also be fed into other projects or activities in general.
Meeting the requirements of methodologies such as PMBOK, ISO9000, ASPICE, ISO26262 and many others that see problem documentation as a vital tool for ensuring that problems do not go unresolved.

Problem vs. task and time report

Problems are not tasks and even in a system they stand alone. They can be tracked and resolved without creating a task to resolve them, but if a task proves to be important, a task can be created for the problem. In particular, this can be useful if a group needs to be formed to collaborate on a solution to a problem. (For example, the task can be put on people's calendars and capacity can be planned for it.)

The need to create a task depends on the way how your team works. For example, if a colleague synchronises tasks to the mobile phone, creating a task will synchronise it and a colleague gets notice about the problem even if he/she doesn't look into the AyMINE.

Right next to the problem, it is possible to report the work done to solve it. There is no reason to create a special task to solve just because of the work report.

Correct description of the problem

In order for a problem to be solved, it must be documented from the beginning. Especially if the problem is to be solved by someone other than the person who identified and wrote down the problem, or if it is known that the solution is delayed and will not be immediate. The content of the problem description is usually also defined by the quality methodologies of the work and the internal quality system. The methodologies agree that the description should include, at a minimum:

Accurate identification of the environment in which the problem occurred (e.g., whether the problem is at an internal facility or at the customer's facility and at which facility)
Under what circumstances the problem occurred
What caused or may cause the problem
How severe the impact is
What steps were taken to bring it about (especially if it can be brought about again by the same steps)
What the correct behaviour should be

The following should also be included (if known and relevant):

Reference to documentation describing the correct condition (e.g. manual of the malfunctioning device)
Logs or other records of the malfunctioning behaviour

For many problems, of course, some of the above values are not relevant, or are only relevant in a figurative sense (a prime example for problem documentation is the occasional misbehaving device. In this case, the documentation is fully meaningful. In another example – lack of knowledge in a project team member, most of the description points will of course be unusable. Both examples are problems that should be noted at the time of creation.)

Documentation of the solution

The problem should state how it was solved. The description is included in the same description as the details of the problem, because in the course of solving, circumstances are often refined, and both are worked together.

Especially when solving more complex problems, it is common for the problem to be split into sub-problems, or for other sub-problems to become apparent. It is therefore possible to introduce sub-problems to a problem, or to link a problem to another problem by logical linkage.