Slinger's Thoughts

January 17, 2011

How to Solve Problems

Filed under: SharePoint — slingeronline @ 2:02 pm

I was upgrading my computer’s operating system over the weekend and while doing so, I was also checking all of my files for what to keep and what to let go. I came across something I had thrown together several years back about how to solve problems.  In the company where I worked at the time, the solution to any issues that arose was to let someone go, because they were the problem.  It  frustrated me that the management at this company couldn’t see that the problem was usually not a person, but a bad practice. I have worked at an ISO9001 company before, and even then, problems were still abundant, and the solutions didn’t seem to make sense. In my attempt to alleviate the issues, I wrote down the following guidelines for problem resolution. I’m not a Project Manager, and I am not relaying something I learned in a certification class. This is from my own experience, and should work in any situation where a problem has arisen.

I will present the whole process in Outline form, and then break down each individual component for clarification.

  1. Identify the problem
    1. What is the problem?
    2. Why is it a problem?
    3. How does it affect the project, performance, etc.?
    4. Where does the problem manifest. At which stage does the problem become apparent?
    5. When was the problem first discovered?  Was it addressed then?
  2. Organize Solutions to the problem
    1. What ideas could prevent the problem from re-occurring?
    2. What can be done to rectify the problem as it exists?
    3. What is going to be done to solve the current problem retroactively? Fixing the cause of a problem doesn’t fix the problem currently in progress.
    4. Who will be held accountable for the problem? Realize that this is usually not an individual, it may be a group, a procedure, or an ideal held by an individual or a group of individuals.
  3. Plan Solutions to the problem
    1. One individual should be assigned the task of resolving the issue.
      1. Additional resources may be required.
    2. Ensure that solving one problem does not cascade.  Often a solution to one problem creates 10 more problems.  This should be addressed, preferably before the additional potential problems develop into additional actual problems.
  4. Follow up
    1. Analyze what worked to solve the problem.
    2. Analyze what didn’t work.
      1. Some solutions don’t solve the problem.  If this occurs, it may be time to re-evaluate the identity of the problem.
      2. Some individuals may not recognize that the issue is a problem, or may not be accountable for resolving the problem.
    3. If another problem has arisen, a different solution to the current problem may be more appropriate than treating the new problem as unique.  It doesn’t help to use one cap to close two ends of a hose. (The see-saw effect.)

Okay, let’s break this down a little bit and I will explain what I mean in each step. I will use an example of an issue that I remember happening at a company where I used to work to help clarify some of the points.

  • Identify the Problem

First there needs to be recognition that there actually is a problem that needs to be addressed. Often times many issues are overlooked simply because an individual doesn’t realize that a problem exists.  In order for any resolution to a problem to be effective, you need to understand all of the aspects of an issue that needs resolution. To that end we need to get some details about what the issue is…

  • What is the Problem?

Any issue needs an identity, even if it is only so that individuals have a name to reference. All this needs to be is a basic description of what the issue is, and doesn’t need any intricate detail. Granted naming your problem “Issue #5049” is about as useful as naming your problem “Buick Skylark.” The name of your problem needs to be the name of your problem. “Database Primary Key collision issue” is a lot more useful.

  • Why is it a Problem?

I know it may seem kind of redundant, but there are people out there, who will simply reply “So?” when you point out an issue to them. A good start is knowing what a problem is. A little harder to nail down, but infinitely more important, is to describe in detail why the problem is a problem. The main idea is to change that “So?” response into an “Oh!” response. If your users understand why an issue could be a genuine disaster, they will be more inclined to act upon it. In our example, the company had expanded into another location. Users needed to be able to access files on the network from either location, so the decision was made that a file server would be located at each location and DFS used to synchronize files between each location. The unfortunate side effect of this was that a particular program was set up to use an Access database that was located in one of the replicated network shares. This created a problem with duplicate Primary Keys in the database when the file was replicated between the two servers at each location.

  • How does it affect the Project, Performance, etc.

This is really part of the “Why is it a problem” step, but lets users know what other things the issue could potentially impact. Users at both locations were using the Same database, and files between servers at the two buildings were synchronized using DFS. The problem of colliding Primary keys in the database created a real large issue that meant that any project could only be worked from one location, or the other, but not both. If left unchecked, the files that depended on this database would end up corrupted. This in turn meant that each file had to be worked on again, delaying productivity, creating duplicate work for the employees, not to mention the abject frustration that the employees had that the hours of work they poured into a project would be lost in mere minutes as soon as the file replicated between the servers.

  • Where does the problem manifest? (At which stage does the problem become apparent.)

This is very simple, and is really just a way to demonstrate the problem to those who are having trouble understanding why it is an issue.  For this there just needs to be some clear documentation about how to reproduce the issue, and to help identify where the issue first appears and is recognized. Although it seems trivial, this could be very useful when it comes time to find resolutions to the issue, or if the issue happens to arise again, to verify whether the issue is the same or just similar.

  • When was the problem first discovered? Was it addressed then?

This is the first step in accountability in resolving our problem.  In many instances individuals are afraid to report an issue for fear that they are going to be viewed as the one to blame for the issue occurring. Because of this many issues don’t get reported as soon as they manifest, but users wait until the issue has become a genuine catastrophe before saying anything. Please keep in mind that the object of this step is not to point fingers or assign blame, but to give credit to the individual who pointed out that an issue exists. (Don’t shoot the messenger, basically.)

  • Organize Solutions to the Problem

We aren’t actually fixing anything yet. This is just to brainstorm some ideas to solve the issue.

  • What ideas could prevent the problem from re-occurring?

All we are doing so far is documenting what some of the ideas for solving the issue. We don’t need to act on any of these issues yet, because we have yet to choose what is the best approach to solving the problem.

  • What can be done to rectify the problem as it exists?

There is a good chance that the current issue being addressed isn’t the first time the issue has occurred. You will need to go back and fix the aftermath of the problem before it was identified. This part is going to hurt, so be prepared for it. Deadlines are going to get pushed, costs are going to increase, and there isn’t anything that can be done to prevent this.

  • What is going to be done to solve the current problem retroactively? (Fixing the cause of a problem doesn’t fix the problem currently in progress.)

The downside to resolving problems is that while you were looking into viable solutions, your problem is still happening. It is very often that the current problem is never addressed. The aftermath of previous instances of the issue will be resolved, and it will be prevented from happening in the future, but right now, the issue is often left alone. You need to remember that this needs to be fixed as well, whether you interrupt what is happening, or you let the issue run it’s course and then fix it after the fact. Depending on what the issue is, you will need determine the best course of action here.

  • Who will be held accountable for the problem? (Realize that this is usually NOT an individual. It may be a group, a procedure, or an ideal held by an individual or group of individuals.)

I hear all to often, “That’s the way we’ve always done it.” Okay fine. But keep this in mind. Just because you’ve always done it that way, it doesn’t mean that it’s the right way. Technology, procedures, cultures and ideas are always improving.  This is not the time to point fingers, however.  Accountability for an issue does not mean “let’s find someone to blame so we can fire them!” Accountability means taking stock of why the issue arose in the first place, and using that as a starting point to implementing a valid solution. “That’s the way we’ve always done it” might be who you need to hold accountable, not as an individual, but as an idea. A Procedure may be too rigid, or too relaxed. There may be another issue that needs to be addressed, such as communication between groups, that needs to be highlighted here. In the case of our wayward database, the person in charge of the software application for a particular group did not consult with the IT department before implementing his own solution without understanding the consequences. The fault here was a lack of communication channels between the AutoCAD administrator’s group and the IT department.

  • Plan Solutions to the Problem

Once you gathered all of the information regarding the issue that you can, it’s time to start fixing it.

  • One individual should be assigned the task of resolving the issue.

One person needs to be ultimately responsible for getting the problem solved. They need to be the single point of contact for any questions that may arise from implementing a solution. Ideally this person also won’t be going on a 3 month vacation the next day. This person should also try to the best of their ability to implement the solution agreed upon.

  • Additional resources may be required.

This means that the one individual in charge may need to assemble a team of individuals with expertise in certain areas. He may need to hire outside consultants to implement a solution. Yes, this stage might also hurt because often times to solve an issue, funds and time need to be spent.

  • Ensure that solving one problem does not cascade. Often a solution to one problem creates 10 more problems. This should be addressed, preferably before the additional potential problems develop into additional actual problems.

Before any course of action is taken, you will need to assess the potential damage the solution might cause. In the case of our duplicate keys issue, before implementing a solution we needed to make sure that our duplicated keys weren’t duplicated again, thus perpetuating our issue all the way through our solution.

  • Follow up

After you have implemented your solution, you can’t just wash your hands of it and walk away. You need to diagnose how effective your solution was.

  • Analyze what worked to solve the problem

If your solution was effective, congratulations. You need to keep this solution in mind in case a similar issue arises in the future.

  • Analyze what didn’t work.

Sometimes your solution isn’t as good as you had hoped. There are often cases where a solution is only a temporary fix and is left at that instead of being a genuine solution to a problem. I personally call this the “band-aid on a bullet hole.” (Yes, a band-aid might solve the external problem of you’re bleeding, but it does nothing to address the issue of you’ve been shot.)

  • Some solutions don’t solve the problem. If this occurs, it may be time to re-evaluate the identity of the problem.

If you apply the solution and the problem still exists, there is a good chance that when you identified the source of the problem, you were mistaken. Not that you didn’t solve a problem, but it is possible that you didn’t solve the problem you were intending to solve.  It might be time to start over and try to get a clearer identity of what the issue actually is.

  • Some individuals may not recognize that the issue is a problem, or may not be accountable for resolving the problem.

Some people get defensive when you point out that a problem may be in their department. They may have an active interest in seeing that you don’t resolve the issue just to prove a point. There are occasions when you might have appointed the wrong individual to be in charge of an issue. Not that this was a mistake in judgment, but that individual may have other issues that you have not accounted for or may not be aware of. This needs to be accounted for when determining why a solution didn’t work as expected if it doesn’t. 

  • If another problem has arisen, a different solution to the current problem may be more appropriate than treating the new problem as unique. It doesn’t help to use one cap to close two ends of a hose.

There are occasions when a solution to an issue creates new issues that need to be addressed. Before addressing them, it should be determined whether the current solution is the cause to your new problem.  In the hose analogy, imagine a garden hose connected to a house.  There is a “Y” adapter and a hose connected to both sides.  You have one cap to stop the end of one hose. If the problem is that you need to stop the other end of the hose, you cannot take the cap off of one end and stick it on the other. You haven’t solved your problem, you have simply relocated it.  Be careful that your solution doesn’t simply move or hide your problem, instead of actually fixing it. If you start to feel like you are going in circles, and are fixing a similar issue repeatedly, the solutions applied may not be the correct ones.

Keep in mind that not every problem has a solution. Sometimes the solution to a problem is another problem waiting to happen. And even though managers would often like to think so, an issue is almost never a person’s fault, but rather the fault of an idea or belief that the person may have, or a procedure that is incorrect.  It also couldn’t hurt to make a simple form out of the outline to use for reference if you need to.

Advertisements

1 Comment »

  1. This is fabulous! I wish my employer would think this way…

    Thanks for posting this!

    Comment by Steph — January 18, 2011 @ 5:17 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: