Problem-solving should be in every property investors and business owner’s toolkit, invariably things will go wrong, and you need to know how to get to the root cause so that you can put it right, so it does not happen again. However, problem-solving is not just for when things go wrong as it can also be used to look at deals that have gone well and find ways to make improvements so that it is even better next time.
To become proficient at problem-solving a simple nine-step process should be followed. Although it may seem complicated at first glance, with a little bit of practice it will become second nature.
The Process
1. Problem Statement
The first step is defining the problem statement, this is where a lot of people go wrong including professionals who should know better. All too often people want to dive into corrective action and put things right believing that they already know what the problem is, and invariably the problem raises its head again at some point in the future, or the problem has become worse. So you need to be patient and do not pass this first step until the problem is defined.
Guidelines to a good problem statement are as follows:
- What has been seen?
This should include factual information, measurements, photographs, what specification is being deviated from, who found the problem, is it a repeat concern? If it is possible, the originator must physically observe the issue and go to the place where it was found or created to gain clarification.
- Where was it found?
It is important to identify where the problem was discovered, as this is relevant to later stages of the investigation. At this stage, no attempt should be made to predict where the problem was caused.
- When was it found?
The date and time a problem was discovered, it may be relevant to the investigation.
- How was the problem found?
Understanding how the problem was found will assist in later stages of the investigation.
- How many?
It is important to record the details of the scope of the problem at the time of discovery; this will assist in containment action. Specific details should be recorded to prevent duplication and assist later stages of the investigation.
The following are examples of poor and good problem statements:
a) Poor Statement – The bathroom in the HMO is flooded
b) Good Statement – The bathroom in room 10, became flooded at ten last night, the ballcock valve in the toilet cistern was broken. The water has not only flooded number 10 but has also seeped through to the room below at number 5 causing the electrics in that room to short out.
As can be seen, the first statement just tells you that a bathroom has been flooded, it gives no indication of which room or the extent of the damage. So, armed with this information you would be looking at sending a plumber to fix the problem. Whereas with the second statement you know which two rooms have been affected, you know that not only is a plumber required to fix the problem but that you also need an electrician, and because of the water damage you may also require a builder. In the meantime, you also need to try and find an alternative accommodation for your tenants as they now have rooms that they cannot use.
2. Form your Team
The second step is to form your team, this can be one person or a team of people depending on the complexity of the problem. Each problem is assigned a leader and the responsibilities of the leader are:
- To control the actions.
- To clarify the problem description (in consultation with the originator).
- Confirm the need for the Root Cause Analysis (RCA) to be carried out.
- To track the investigation through all stages to a conclusion and ensure that the RCA process is followed.
- Determine the problem-solving team considering the nature and complexity of the problem.
- To escalate any obstacles and blockages through the management hierarchy, which could be just you
- To report on progress on the RCA activity.
- Present the RCA for closure upon completion.
3. Containment
Containment action is the next stage it is the initial actions taken to protect the customer from further occurrences of the stated problem.
The scope of the problem should be determined, and appropriate action was taken on all items suspected or found to be non-conforming. For example, leaflets with the wrong contact number are ready for distribution, how many do you have in stock, how many have been delivered to houses. Upon the completion of containment activity, no further defects should reach the customer.
Typical types of containment actions are as follows:
- Identifying and locating all suspect material through in-house process check.
- Check material to requirements, quarantine all defect material.
- Review any material that may have been generated with the same process.
- Obtain all escaped suspect material, or quarantine and notify customers.
- Implement temporary fix and take appropriate action to ensure no further defects of the same nature reach the customer.
- Upon completion of the containment activity, the problem leader must confirm that the problem has been contained via all appropriate actions having been completed and enforced.
4. Root Cause of the Escape
It should be determined at which stage of the process the defect or problem should have been detected, and the reasons why the issue was undetected. This activity may identify more than one process stage where the defect was not detected, and each should be considered.
Review of working practices, procedural documents and instructions should be supplemented by the use of appropriate tools, e.g. brainstorming, 5 whys, Ishikawa diagrams, process mapping, etc.
5. Prevent Further Escapes
Action should be taken to ensure that future occurrences of the problem are detected at the correct process stages. These may be permanent or temporary activities for example:
- Use of mistake-proofing methods e.g. smoke detectors are designed so they cannot be mounted until a battery is installed.
- Additional inspection instructions
- Updates to procedures/work instructions/process plans
6. Root Cause of the Issue
Where possible this analysis should involve individuals with knowledge of the processes and should also involve a review of the process as it occurs in reality Use of the approach of “go, look, see and understand” is recommended.
Appropriate tools should be used to support the analysis and investigation e.g. process mapping and 5 whys, Ishikawa diagrams etc. It may be the case that a number of contributory causes are identified and any that cannot be dismissed need to be included for correction. When defining the root cause the following type should be avoided:
- Repeating the original problem description.
- “People error”
- “Lack of resource”
- ” Issues beyond physical control”
These are not root causes and show the process has not been applied effectively/ rigorously.
7. Permanent Corrective Action
Actions must be taken to permanently eliminate the cause(s) of the problem. As a general rule, to correct a problem requires a change, for example, process changes, procedural changes. Changes should be implemented following the appropriate change process.
When introducing a change, the following should be considered:
- The impact of changes on training
- The impact of changes to work in progress
- Risks associated with the change
- Procedural requirements for making a change e.g. is a joint venture approval required?
8. Preventive Action
Preventive actions are those actions taken to prevent a similar problem occurring in other areas of the business. At this stage, it is important to consider if any other areas of the business could benefit from the changes made as a result of the problem resolution. If there are other areas of application, the corrective actions should be applied in those areas too.
9. Verify
Each problem or issue subjected to the root cause analysis process should be subject to final verification activity to ensure that the issue has been satisfactorily resolved. This should be carried out by the problem owners/manager.
Topics to be considered are:
- Has sufficient containment action been taken?
- Do the identified root causes relate to the original problem?
- Are the root causes identified true root causes and not symptoms of a deeper cause?
- Have all identified corrective actions been implemented?
- Have corrective actions been effective in eliminating the original problem?
- Have corrective actions been applied to appropriate processes?
- Have any temporary containment and protection actions now been removed?
- Are the preventive actions robust e.g. is mistake proofing used?
Good practice in verification should, as a minimum, involve a “go, look, see” activity where physical inspection of the corrective action etc. takes place.
Recent Comments