ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

problem solved

Updated on April 16, 2013

fig. 1:AND truth table

in 1
in 2
out
 
0
0
0
false
0
1
0
false
1
0
0
false
1
1
1
true

It's all over but the shouting, right? Well, first we have to decide what kind of shouting we're going to do; we have to measure the outcome to decide whether we've succeeded, failed, or (and this is the most likely outcome) something in between.

Why We're Measuring The Outcome

There's a saying in business that goes something like, "If you want more of something, measure it." The implication is that if you measure (monitor) something, you'll be thinking about it, you'll see what produces more of what you're monitoring (and what produces less), and you'll start doing those actions that produce more.

That may not sound intuitive, but it's true. The very act of monitoring an outcome will help focus our minds on it. Another way that monitoring affects us is the area of performance evaluations. Think about what happens when you learn that your boss will monitor your performance based on <whatever>. You'll start paying more attention to <whatever>, won't you?

These are just two reasons why we monitor outcomes. Some other, related reasons are: maintaining focus, performance evaluation, course corrections, maintaining standards, standards development, and feedback.

Maintaining Focus and Performance Evaluation

As we've already seen, the simple act of monitoring a process tends to focus us a little better on that process. If you sit down to study one of your class texts, set a time limit and number of pages that you want to cover. The mind tends to want to complete things; we get a sense of accomplishment. Setting a limit on time and pages is an act of monitoring.

The field of performance evaluation is huge, and is tied in with motivation and morale, workplace management, and other areas. One school of thought holds that it's impossible to evaluate a person's performance without first having standards to measure against. The same thing goes for problem-solving.

Course Corrections

Realize that we don't implement the decision, then make a one-time, end-of-action measurement (unless the implementation and the effects are small and short-lived). Rather, be prepared to monitor outcomes throughout the entire implementation. Set up milestones along the way. For example, if you have a six-month implementation schedule, you might have some major checkpoints every month, and smaller ones every week. The major ones might involve everyone (or at least the major players), while the weekly ones might involve just the people affected. These checkpoints are indispensable.

We use such checkpoints daily. What do you do when you get in the car to get to work (or hit the pavement to walk to work, or get on the train)? Well, you start the car, click the seatbelt, and start to drive. I'll usually look at the clock to note the time. I'll get to the quarter point and I'll see how long it took me in traffic. "Hmmm; only five minutes; I'll make it to work a little early today." Or, "Uh-oh; this is taking too long. I'll turn off here and take the back route." Your checkpoint measurement told you that you needed to modify your implementation (the route you’re taking to work) if you wanted to succeed (by getting to work on time).

What you measure for a checkpoint might be different from your final measurements. For checkpoints you might measure the amount of money spent so far, whereas the final measurement for success might be the total amount of money saved.

Another important point to remember is that you don't want to abandon ship too soon. You might measure at a checkpoint and think, "Uh-oh! We're way off course, and we're about to walk off a cliff. Let's do a 180!" Don't. Stop and think about where you are and what you're trying to do. Don't reject a solution or implementation too soon. When you originally determine what you're going to measure, make sure you don't fall into the trap of expecting the final result too early on. Think about how long effects take. It might be that you implement a solution, the effects of which you won't see for another three months. If that's the case, make sure you explicitly state that in your problem solution documentation.

Maintaining Standards

Monitoring helps us maintain standards. When you determine what you're measuring, check to see if your department has standards you need to abide by. For example, suppose part of your implementation involves performing tape backups. Is there a standard for what media you are to use, or where they must be stored? If so, make that part of the measurement.

Sometimes that sounds so silly. "Of course we know we must do the backups on TR5 tapes. I'll just specify that in my procedures, and it will get done." That statement is the statement of a rookie (and a rookie about to take a fall, at that!). Simply telling someone (in writing or orally) what to do or how to do it is insufficient. But don't harp; don't tell them over and over. Rather, tell them once (or twice) and then measure that outcome.

Standards Development

Where did these standards come from in the first place? Part seat-of-the-pants and part experience—the experience gained through monitoring. Perhaps you thought that your solution to disaster recovery was great (you implemented a series of tape backups—the first time your unit has done backups!), until you realized that when the fire sprinklers went off, they not only soaked the servers, but also the backup tapes that were stored...on top of the servers. "Ah-hah! I'll update the standards so that now tapes will be stored away from the servers."

Feedback

In some meetings the facilitator would ask the teams how they think things went. What happened when you answered those questions? For some of you, it was the first time you thought about those outcomes. "Hmmm; did we have a leader? Did someone ask a question that I didn't answer?" That's okay. Part of the purpose of the questions is to get you to start thinking about them (and to make course corrections, etc.).

On a larger scale, you could ask yourself (or the team!), "Did the decision-making technique we used help us make the decision? What went right with mind-mapping (or whatever technique you used)? What went wrong? Is mind-mapping still useful? How can I make it give me better results?" Try out several decision-making
techniques, and monitor the outcomes based on the technique. How else will you know which ones to use when?

Plato or Socrates (the experts disagree) said, "The unexamined life is not worth living for man." Part of the feedback you need is on yourself! "How well did I function in all that decision-making and implementation? Did I help the group or hinder? How did I react when Fred told me I didn't know what I was talking about? How come I snapped at Mary; she was just trying to help." I'm not asking you to psychoanalyze yourself, but simply to examine your performance.

Most times it's good to get that sort of feedback from your peers, your bosses, and your subordinates. Your peers may think you're great, while your bosses and subordinates could point out a few areas for, let's say, improvement.

Unexpected or Unintended Consequences

Great! Sales are up 35% over last year, all because of your implementation. Then your boss says, "Say, Fred. Have you noticed that sales returns went up 2% last week, and 8% this week?" Part of what you should measure are those things that you expect to stay the same. When you think of those things, you may need to go back to your implementation plan and ensure that those things are addressed (and, certainly, measured).

But if you do that, then such consequences aren't unexpected. What happens when you see a true unexpected consequence? Well, you go through the problem-solving process again. The good news is that you probably have a lot of information on some of the parts that surround the problem.

In fact, you do that even if you've achieved success! Your boss may say, "Jane, great job!” Now that sales are up 35%, we see that the [boss proceeds to describe a problem that was masked by the problem you just solved]. Take a look at that and handle it, ok?" In short, you'll never solve "the last problem," because...there is no "last problem."

Ambiguity and Perception

Ambiguity is important for you to integrate into your decision-making process. McCall and Kaplan say that consequences require interpretations!

"What!!?? I thought consequences were just that! I mean consequences are obvious to everyone. How could two people possibly interpret outcomes differentl?.

In reality, we actively get involved in shepherding different perceptions. If we don't, then who knows where they'll end up?

If this sounds a little like drawing the bulls-eye around the arrow you've already shot...good. Don't lie; don't present your failure as a success. Rather, make others realize what was intended, and what actually happened. They may not have the experience with the problem to interpret the results; give them some help.

Measurement Summary

Measuring outcomes will be an eye-opener—for you and your customer. What you measure will be what you focus on. The measurements will help you determine whether you've succeeded; they will help you maintain standards and come up with new ones; they will help you make mid-course corrections; and they'll give you important feedback.

Computer Logic

All of the above involved heuristics – intuitive thinking and imagination. Could a computer possibly assist in problem solving?

"Computer logic" is not, as we sometimes think, an oxymoron. Computers are dumb, and don't do very much. But what they do they do very fast. Assumptions are not allowed in computer programming – unless specifically stated and defined. The ability to separate the wheat from the chaff is the basis of Systems/Business Analysis. Of course, programs (and the computers themselves) function on a strictly logical basis.

We learn; we build upon our experience; we become smarter. Likewise, we build computers so that it seems as if they learn; we build them up based on our experience; we have them store things so they seem to be smarter.

Let's examine what a computer does "at the base."

Binary

The central processing unit (CPU) of a computer, the guts, so to speak, understands binary signals, or information. Binary means "composed of two parts." The two parts the computer understands are 0 and 1. “gates” are open or closed; a statement is true or false. Information is stored in memory, and the memory is organized around bits (some say that comes from "binary digit"). Each bit takes on one of two values—0 or 1. Some researchers have played with computers based on more than two values, but that hasn't borne as much fruit as they thought it would.

The CPU is composed of a huge number (millions!) of binary switches (implemented using transistors, mainly) and other associated "glue" components. Each of the switches takes values and produces an output value (again, a 0 or 1). For example, a very simple switch can take in two input values and output one value, based upon the inputs.

Suppose a switch in the CPU acted according to the table in figure 1 above.

The switch returns a 0 unless both inputs are 1, in which case it returns a 1. Entire computers are built on this basic principle. Programming languages standardize the interpretation of the 0's and 1's. Usually, languages abide by the rule that a 0 (or a string of 0's) represents a value of FALSE, while a 1 (or string of 1's) represents a TRUE value.

Other parts of the CPU perform arithmetic—adding, subtracting, dividing, and multiplying. But that's not technically computer logic, although it's certainly one of the main functions of the CPU. Some of you may remember when this was done by a separate “mathematical processor”.

Memory is likewise composed of a huge number of binary switches, but memory is used for storage. Memory is usually organized into 8-bit bytes, and then usually into 2-byte, 4-byte, or 8-byte words.

Limited Comparisons

The CPU is likewise pretty uncomplicated when it comes to comparisons. The CPU can decide whether two bytes are equal (that is, whether they have the same bit pattern), or whether one byte (or word) is greater than or less than another byte (or word). The rules for deciding "less than" and "greater than" depend on how one interprets the byte (or word).

Boolean Logic

George Boole was a 19th century English mathematician who developed a system for expressing logical statements about sets. Along with the system was a notation that allowed one to algebraically manipulate logical statements. This system is known as Boolean Algebra.

Have you ever performed a search on Google? For a simple query, you might say:

denver broncos

Google interprets this to mean that you want to find documents that contain the word "denver" or the word "broncos" (or both). If you're familiar with some of Google's tricks (it's not really Google's tricks; Google and other search engines use a more or less common natural language query algebra made popular by Akamai (I think)), you may want to say:

+denver +broncos

which tells Google that you want to find documents that contain both the word "denver" and the word "broncos" (not necessarily next to each other, but at least in the same document).

Using Boolean algebra, you could express the first query as:

denver OR broncos

and the second as:

denver AND broncos

In fact, Google lets you express the two forms either way. The "AND" operator says that a statement is TRUE if (and only if) its two operands (denver, broncos) are also TRUE.

Notice that what Google shows you are all documents that satisfy the statement. The Google search engine works according to the truth table listed in Fig. 1, which is the truth table for the AND operator. A statement using AND is true if, and only if, both the operands (the values on either side of the AND operator) are TRUE.

Below are the truth tables for OR and NOT. Note that the NOT operator takes only one operand.

By applying Boolean logic to a problem, it is possible to reach a solution by computer. One would need to ensure that s/he includes preferences and prejudices to the evaluation, and avoids ambiguities. There is an entire branch of computing devoted to analyzing language-based problems and translating them into computer language, coming up with a “heuristic” solution.

fig 2: OR truth table

in 1
in 2
out
0
0
0
0
1
1
1
0
1
1
1
1

fig. 3: NOT truth table

in
out
 
0
1
 
1
0
 
 
 
 

Comments

    0 of 8192 characters used
    Post Comment

    No comments yet.

    Click to Rate This Article