Call us Today +44 (0)1536 711 999

Marval logo
Blog

Practical Problem Solving Tips

What is a problem? A discrepancy between what is and what should be, with the solution being known as 'the solved state'.

The primary objective of problem management is to identify and manage the underlying cause of service incidents whilst minimising disruption to customers. To get the best possible results you need a structured ‘framework’ for problem analysis and expectation management. Not all problems are caused, not all causes can be corrected. Focus directly on the heart of the matter – getting to the root cause with the aim of solving the problem permanently. Be clear about the end results and the means of achieving them is the essence of problem solving.

Trouble shooting the problem

Do not be afraid to ‘slow’ the communication process down, talk to customers in their business language try not confuse with technical jargon. Do not expect the customer (or support person) to be an ‘expert’ in IT. Remember the ‘customer’ is an expert in their field. Ensure you ‘understand’ their issue; ask again if you don't understand something they say. Always re-state the ‘problem’ for clarification to ensure you fully understand what they are saying. Do it more than once if you are unsure.

Before you get too far into the process have you asked "Why?" five times*

  • Ask "Why" a problem is occurring and then ask "Why" four more times eg.
  • Why has the machine stopped? - A fuse blew because of an overload
  • Why was there an overload? -There wasn't enough lubrication for the bearings
  • Why wasn't there enough lubrication? -The pump wasn't pumping enough
  • Why wasn't lubricant being pumped? -The pump shaft was vibrating as a result of abrasion
  • Why was there abrasion? -There was no filter, allowing chips of material into the pump
  • Installation of a filter solves the above problem.

*From "What a Great Idea" by Chic Thompson

This may determine the cause of the problem. If not you may need to delve further with Marval’s 12 step problem solving process.

Always consider the impact on the company, department and customer perception if a problem is not solved.

All problems cannot be treated the same. You need a business impact, urgency and priority assignment approach that ensures business critical problems are handled first. Consider having major incident process and procedure in place to ensure a structured approach is taken when you are under pressure.

Marval’s 12 Step Problem Solving Process

These 12 steps can apply to any problem type (hardware, software, network, application etc). Quickly identify and eliminate irrelevant questions in each step, Summarise each question response. Write a separate list to identify/actions inputs and outputs that may require input/evidence/confirmation from other sources. Do not go off-track, focus on reading and answering the specific question. Keep to the time schedule and ensure you review and report on each step.

Step 1 - Define the problem e.g.

  • What has gone wrong? What isn't working properly? What is?
  • What should be happening that isn't? What shouldn't be happening that is?
  • What are the specific symptoms being seen? What and who is affected?
  • Where is it happening? Is it only in one place or several?
  • Is there a pattern (same time, same location, same people etc)?
  • What does it include? What does it exclude?
  • How urgent is it? When does it need to be fixed by? Can it wait?
  • Will it go away of its own accord?
  • What happens if we don't do anything?
  • What is the consequence if we do the wrong thing?
  • What is the financial/business/political impact?

Step 2 - Specify the solved state e.g.

  • What should be happening that isn't?
  • What are we trying to achieve?
  • What do we want to keep or preserve?
  • What are we trying to eliminate or avoid?
  • What is the identified Solved State?
  • Who says what the “Solved State” or “Should be” is? How will we know the problem is solved?

Step 3 - Build consensus and support with a defined communication plan e.g.

  • Who needs to know what's happening? When? How often?
  • Who needs to be involved? When? How?
  • Who might support or oppose our definition of the problem? Why?
  • Who might support or oppose our view of the solved state? Why?
  • Whose support do we need to make this ‘thing’ work?
  • Who has to commit to what, in order for this to succeed?

Step 4 – Troubleshoot the Problem e.g.

  • Do we think we know what the problem might be yet? Identify the most likely cause
  • Have we identified what is affected? Are we speaking to the right people and asking the right questions?
  • Should we look for causes? Were things okay before?
  • Did the problem suddenly appear or did it develop over time?
  • When exactly did things go wrong? Can we reproduce the condition?
  • Are there any external events which may contribute to the problem (e.g. telecoms, power, ISP)
  • Has anything been changed recently?
  • Are we speaking to the right people, are we asking the right questions?

Step 5 – Design a solution e.g.

  • Assess and agree level of risk, affected Services, Configuration Items /Business users
  • Define required approvals (including authority to back-out)
  • Assess possible service outage period and workload estimates
  • Agree scope of testing plan
  • What kind or class of problem is it (hardware, application, data, communication)?
  • What are we calling it? How shall we classify/document it?
  • Are we dealing with a people issue?
  • Are we dealing with some kind of production or ‘state-change’ process?
  • Which of these factors are truly driving the problem (e.g. a server, software, network device)?
  • Do we need to change peoples' behaviour, their procedures, the system they're using, or all of the above?

Step 6 – Identify the means of change e.g

  • Agree scope of any release change requests that need to be included
  • Identify any increase in resources required (e.g. hardware, disk space, access rights, CPU size, network bandwidth)
  • Implement a “workaround” or “quick fix"?
  • Training for people?
  • Process re-design?
  • A procedural or methods modification?
  • A configuration, hardware or software change?
  • Documentation change?
  • Staffing/supplier changes?
  • Resource allocation?

Step 7 – Settle on a course of action e.g.

  • Define planned fix date
  • Identify which staff and resources are required
  • Agree scope of communication plan
  • How do we decide? How long do we have to decide?
  • What are our options?
  • What are the risks?
  • Who do we need to keep informed?
  • What are the costs? What are their benefits?
  • What are the side effects?

Step 8 – Reconcile restraints and constraints e.g.

  • Identify who needs to be involved and when
  • Review change and release forward schedule for possible conflicts
  • What are our restraints and constraints (e.g. resources, time, approval, authority, access, money, skills)?
  • Can we influence any restraints and constraints?
  • What are the things we must do (e.g. take machine down, take a backup of data)?
  • What are the things we can't do? Who says? Are they real or imagined?
  • What are we assuming? What are we overlooking?
  • What has to give? people, time, money?

Step 9 – Prepare plans and schedules e.g

  • Create test, back-out, communication and continuity plans
  • What could go wrong?
  • How do we monitor progress?
  • How long will it take to implement?
  • When is it safe to implement the solution?
  • Have we confirmed the business impact and urgency?
  • Who owns/does what when?
  • Do we have the skills/checks to confirm success?
  • How will we know if things are going okay or fouled up?
  • How and when do we keep people up-to-date?

Step 10 – Take Action

  • Do it!

Step 11 – Assess Effects and Consequences e.g

  • Monitor effects of actions
  • Confirm success or failure of actions. Did it work according to plan?
  • Notify affected customers
  • Inform support desk to document and capture results of action
  • What did we spend? What did we gain (e.g. time, money, customer/business confidence)?
  • Was it worth it?
  • Have any new incidents resulted from the implemented solution? Do they offset the gains from solving the original one?
  • Are we better off or worse off than before?
  • What did we learn?
  • How was customer perception of our performance?

Step 12 – Adjust for future action e.g.

  • What did we learn? What did and didn't work? Why?
  • What could have been done better?
  • Were our continuity and communication plans effective?
  • What operational information should be revised/created (e.g. processes, procedures, plans, checklists, skills matrix, knowledge bases, known errors)?
  • What training needs to be done for who/by when?
  • Known barriers to effective decision-making preventing us from implementing and performing effective problem analysis and problem solving include:
  • Indecision - Avoid decisions to escape aspects of risk, political pressure, fear and anxiety
  • Stalling - Refusing to face the issue; accept responsibility, obsessive gathering of endless facts
  • Overreacting -Letting a situation spin out of control; letting emotions take control
  • Vacillating - Reversing decisions; half-heartedly committing to a course of action
  • Half measures - Making decisions to avoid controversy but not dealing with the whole problem
  • Making assumptions - Making decisions based on hear-say and assumptions rather than facts

With a well-defined problem analysis and problem solving process in place, you will realise major business benefits: repetitive problems solved permanently; reduction in the number of incidents and problems; minimised business impact; shared knowledge; reduced resolution time; improved productivity and greater confidence in IT services.

Try to search for multiple solutions. Quite often there is more than one acceptable solution. Suspend judgement and criticism in the collecting ideas stage. Try not to look for overly complex solutions when a much simpler one may be available and present itself – always select the best alternative for the problem in hand.

“Ensure you treat the problem not the symptom”

Contact Us View all Articles

Similar Articles

Endless possibilities with Marval...

Whatever your aspirations might be, we have the technology, the expertise and the people to make them happen.

We know you may have some questions...

I would like to opt in to receive marketing communications from Marval via:

  • Request a
    Demo

    Discover the benefits of implementing MSM software, designed to improve service quality, customer satisfaction and reduce costs

  • Download
    Resources

    Your central repository of interesting and useful information on IT Service Management

  • Customer
    Case Studies

    See how organisations all over the world use Marval MSM software to address their most critical IT Service Management challenges

  • Contact
    Marval

    Contact us to discuss your service improvement requirements