IT problem solving methods

[surferdude949]

What methods do you use when tackling a challenging IT problem?

I'm referring to resolving complex issues.

I found these four principles

1. First, you have to understand the problem.
2. After understanding, then make a plan.
3. Carry out the plan and test.
4. Look back on your work. How could it be better?

 

[surferdude949]

I want to elaborate on this

1. First, you have to understand the problem.
Ask the right questions to help pin point the problem.

2. After understanding, then make a plan.
Utilize all available resources from online to vendors.

3. Carry out the plan and test.
write up a plan of action and testing procedure.

4. Look back on your work. How could it be better?

 

[edfair]

Used to drive my IT customers crazy with questions. A good tech could find many items needing fixing on the machines but only by asking the right questions couly you figure out what needed fixing to satisfy the customer. Not to say the other things didn't get fixed, just that the priority was to fix what the customer needed.

The alternative was one employee that PM'd the machine. He was afraid to ask questions so would spend the day fixing what he could find and had less than a 50% fix rate for the customer problems. Used to drive the customers up the wall. He found greener pastures. Great guy, just not a good field service tech. Would have been great in a recon center.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[gbaughma]

Yes... understanding the problem is half the battle.

For example.... I got an email yesterday... (paraphrased)

User: "The project imports aren't working."

Me: Responded to the email by giving them yet another copy of the procedure, complete with screen shots and click by click instructions.

User: "I don't have permissions to the program to do that..."

Me: (Thinking UGH! That's NOT how you described the problem!)



Just my 2¢

"What the captain doesn't realize is that we've secretly replaced his Dilithium Crystals with new Folger's Crystals."

--Greg

http://parallel.tzo.com

 

[stackdump]

For something really complex, I find mindmaps helpful. I usually draw on a flipchart (using a normal pen) because a map can get quite large. There's a freeware utility for that called freemind, but I actually prefer a large sheet of paper because its more portable and the scribbling of ideas and thoughts easier.

My day can be a jumble of different issues and if I have to go away from a problem and come back to it later, my train of thought is usually lost and I have to start over. What a mindmap does is capture the train of thought. It documents ideas, what I need to try to prove or dismiss each potential cause. More importantly for me is that it records the reasoning for doing a certain experiment, what happened when I did it and why I gave up down a certain track. When I come back to a problem, I can look at the map and instantly see where I got with it. Where there is some kind of delay or dependency on moving forward I have also had several maps active at the same time.

On an equally important note, it allows you to share the problem with others more easily and also acts as a mechanism to show people that you really are trying to fix it! When I get to the end, I keep the page for a while, just in case the same thing happens a short time later.

So take a look at mindmaps, they're a great way to create "focus" and "discipline" when solving problems.

 

[CajunCenturion]

There is no question that understanding the problem is the first hurdle; however, that is not always as simple as it sounds. The reason that different people will have different understanding of the problem. The clerk may see the problem as one thing, but the manager sees the problem as something entirely different. The key is that they are both right, and it's our job to solutions to both problems.

The first part of formulating the plan is to devise a solution: a solution that meets both the clerk's needs and the manager's needs. To do that requires a good understanding of their respective needs.

I've found that a good approach is not to ask them NOT about the problems or shortcomings in the current system, but rather, ask them what they would like to see in the desired system. Don't think of the goal as to fix the current system, but rather, think of the goal as to deliver the optimal system. If you get bogged down with identifying problems with the current system, you will lose site of the objectives of the desired system. Focus on the desired system.

Start with the output.

Ask them what they want out of the system. For example, ask the manager what reports they need from the system and what data needs to be on the report. In other words, get the manager to tell you the question that the report is designed to answer. From the clerk's perspective, don't ask what is wrong with the current screen, ask them what would be the best order of fields; what would provide the most natural flow for how they do their job.

That not only makes it easy to identify their needs, it makes them part of the system because they're providing real input into the design. It makes that part of the team if you will, and that goes a long way towards the delivery of a good solution.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Welshbird]

CC - you're in danger there of provided users what they want!

Fee

"The cure for anything is salt water – sweat, tears, or the sea." Isak Dinesen

 

[CajunCenturion]

:-D

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Thargy]

Nah, he isn't.

He's made the ridiculous assumption that it's ok to change faulty software.

As we all know (and as so elegantly elucidated by Edsger Djikstra) software never fails, it's just that we don't know when it succeeds.

Also, on a slightly less philosophical note, I have to question the OP. First of all you do NOT have to understand the problem, you have to establish what it really is, not what you think it is, not what the person reporting it thinks it is, and definitely not what their manager thinks it is. There's no point understanding a problem if it's not the one being experienced.

Going straight to the horse's mouth is the only way to deal with a problem. Discuss with and interview (if necessary) the person who is experiencing the problem. Only they know what they're experiencing, their manager is an interfering irrelevance.

It sort of reminds me of the junior officer on the radio to the commander in chief, requesting assistance. The general in his nice comfy bunker say "Our charts show no enemy activity near you, what are you moaning about?" The very junior officer says "General, I don't give a **** about your charts, listen to this" and then holds the mouthpiece up. The whine of bullets, the shouts of wounded and the whistle (and subsequent crump) of artillery shells are heard. The officer tells the general to send help because regardless of charts, they're being slaughtered.

The second item, making a plan seems equally daft to me. Suppose you believe that you've correctly determined the real problem, and not what you (or anyone else) thought it was. You then carry out a test, to determine whether or not the fix you have devised solves the problem. If it doesn't you try something else. Planning stuff, when reality can bite you one the bum at any instant is just daft. You don't plan how to put out a conflagration, you first of all get as many tenders to the fire as possible to contain it. Then and only then can you plan how best to extinguish it.

If the problem is that a thermonuclear device will detonate in 10 minutes, planning is just idiotic. Stop the countdown timer, and stop it now! Until that's done, any and all plans are irrelevant.

Ooh, do I sound like someone in IT who's been shafted so often now, that he's a bit hypersensitive to faults being reported, now let me see, how did that happen.....

Regards

T

 

[CajunCenturion]

==>software never fails, it's just that we don't know when it succeeds.
Could you source that statement please, or at least the work from which you draw that paraphrasing?

==> Ooh, do I sound like someone in IT who's been shafted so often now, that he's a bit hypersensitive to faults being reported, now let me see, how did that happen.....
Probably because you spend too much trying to explain to the users why the software wasn't failing, rather than paying attention to what the users actually need.


--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[stackdump]

Hmmm... I would never work without a plan. The plan may be simple, shut down the system, patch XYZ and reboot, but it's still a plan.

It also depends on the environment, I dont have the freedom to unilateraly decide to shut the system down for two hours. My CEO would demand a plan, I can hear him now yelling something like "you're not shutting the company down until you tell me exactly what you're going to do, the downtime and when we're guaranteed to be back online".

At the end of the day, it does depend on the problem, is it a single user, a specific network, the whole system etc. What is the Seriousness, Urgency and Growth. Even if the system is totally dead, you would certainly need to throw all hands to the pumps as you say, to try to bring back the essential services one at a time (but that is still a plan).

In a less frantic scenario, 8D problem solving has become a standard approach

http://www.national.com/analog/quality/8d

 

[Thargy]

CC,

I quoted from the book Oracle Insights (Tales of the Oak Table) from chapter 9 by David Ruthven entitled "Testing and Risk Management". The quotation is at the top of page 301.

The ISBN is 1-59059-387-1

It's a killer read, absolutely fantastic, distilled wisdom from some of the world's greatest exponents of the art. The sort of thing I read to assist with insomnia.

Regards

T

 

[CajunCenturion]

Unfortunately, I don't have that book, but it does sound interesting. That being said, I am interested in the quote because it's not one that I'm familiar with. Could you please post the actual quote?

Thanks.


--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Thargy]

This is typed verbatim from the book, any errors are mine, not David Ruthven's.

Edsger Dijkstra told us the truism that "software never fails"; I would add "the only problem is we don't know when it is working". When software is compiled and linked into a program it will execute with brutal pedantry. This is both its blessing and its curse: software never fails, so when the code is correct it never fails to succeed, and when it is incorrect it never fails to fail. It has an attractive predictability.

I gave you the paragraph for context.

Regards

T

 

[Welshbird]

CC and Tharg - I suspect you are both correct in subtly different ways.

It all depends on the type of problem - if this is a 'new' problem to solve or a problem in current software; if this is desktop support or issues arising from testing - in some cases the priority must be to solve a problem as quickly s possible; in some cases more information needs to be gathered first to build a more stable solution.

Just my thoughts..

Fee

"The cure for anything is salt water – sweat, tears, or the sea." Isak Dinesen

 

[CajunCenturion]

software never fails

What he meant by that is that software does exactly what the programmer told it to do. It never fails to explicitly follow the source code. And I agree, ED did not say we don't know when it's working, but ED did say,

Program testing can be used to show the presence of bugs, but never to show their absence!

And that is true. You cannot never prove there are no [more] bugs in any given piece of software. You can only say there are no more known bugs.

In any event, that's not the issue. The issue is not whether a program fails to follow the instructions; the issue is whether or not the instructions themselves are correct. And that is the first element of programming - get the instructions correct. That is, know what the software is supposed to do. The OP's question is how do we figure out what are the correct instructions to code, especially in more complex challenges.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Thargy]

CC,

actually I differ with the illustrious Mr Dijkstra on that one. It demonstrably is possible to prove that software is working correctly, by the use of automated unit test tools and the like.

For example, I believe that the 4 colour map problem was solved several years ago by computer. The protagonists (I believe) simply set a computer to explore every possible combination of maps and awaited the outcome. Obviously this must have relied upon some form of topology, but I am not mathematically competent to pass judgement.

So, if a program has a domain space of say 10 billion outcomes, one can set a test tool running to explore its performance under each and every circumstance which may ever arise. By such exhaustive examination, it is therefore (in my opinion) possible to prove that a program has no bugs within a restricted solution domain.

I believe that Mr. Dijkstra was speaking in general, and his statement is therefore self-evidently true, but I assert that it may be possible to demonstrate to the contrary in restricted answer domain problems.

What think ye Centurion?

Regards

T

 

[CajunCenturion]

In general terms, I agree with Mr. Dijkstra; however, because he used the work 'never', it would be impossible to prove it true.

I think this would be a great discussion, and I'm going to start another thread to kick it off. This thread belongs to suferdude949 and in this thread, we should focus the OP's questions.

And again to suferdude949 - start by determining the output. What do the users want out of the system. In your step one, you call for understanding the problem. I don't agree, at least not in defining quite that way. Step one should be to define the target. Where do we need to be? What do we need out of the system? That's where you need to be.

Step two - Where are we now? Here you need to fully understand where you are and what you have.

Step three - Now make your plan. How do we get from where we are to where we need to be?

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Welshbird]

When I have undertaken any project in any area I always include 4 steps.

Plan, Do, Check, Learn.

Now most places seem to do the first three, what they tend not to do is hold a 'finished' meeting to discuss what went well, and what they wish they had done differently. I hold this to be paramount as without it processes can never improve.

Just a quick thought.

Fee

"The cure for anything is salt water – sweat, tears, or the sea." Isak Dinesen

 

[gbaughma]

When I have undertaken any project in any area I always include 4 steps.

I thought it was:
o Do
o Swear
o Google
o Fix




Just my 2¢

"What the captain doesn't realize is that we've secretly replaced his Dilithium Crystals with new Folger's Crystals."

--Greg

http://parallel.tzo.com