Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 4 Issue 8, August 2000
Do the Easy Ones First
Copyright (C) 2000 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


Editors Desk

By Steve Litt

When I opened Steve's Stereo Repair out of my apartment in 1982, an easiest first policy enabled me to make good money in a physical environment with room to store only 10 units. Interesting considering the typical audio repair facility has 500 square feet stocked floor to ceiling with units awaiting repair, partially completed units, and units awaiting pickup. I had one tech (myself), and like the Santa Monica Pacific Stereo (who were now my toughest competitor), my customers left their repairs in the morning and picked them up that evening, and were extremely satisfied with my service.

Over the years, my career changed to programming, tech writing, book authoring, webmastering and Troubleshooting training. I have usually prioritized easiest first, and it's paid off handsomely. The few times I failed to prioritize easiest first, I've gotten the standard problems of messiness, dissatisfied customers, decreased profits and tasks "falling through the cracks".

The fact that you're reading this magazine probably means you make your living solving problems in one form or another. You know that the difficulty of solution typically varies two or three orders of magnitude, and that every problem, no matter how trivial, carries a finite "fixed cost" hassle as long as it's open. You've seen easy fixes become time consuming messes when left too long, and you've seen tough problems turn into non-issues.

This issue of Troubleshooting Professional explores the theory, practice, benefits and limitations of adopting an easiest first prioritization system, and discusses how to personally adopt that prioritization system in environments where the official policy is "first in, first out" or "squeakiest wheel gets the grease". And remember this is your magazine. Enjoy!.

Steve Litt can be reached at Steve Litt's email address.


By Steve Litt
It's a sign of the times. If I give any advice that could possibly lead to problems, I need to disclaim all responsibility so those who make their living through litigation won't sue me. So here it goes:

All information contained in this issue of Troubleshooting Professional Magazine is AS IS, with ABSOLUTELY NO WARRANTEE. Use this information at your own risk. The author, website owner, ISP and all others ARE NOT RESPONSIBLE for any damages, of any kind, resulting from your use of this information, even if the damages are caused by errors in the information. If this is not acceptable to you, please do not read this material.

In several parts of this magazine I discuss, and in certain cases advocate, going against company policy, quitting your job, and the like. These represent what I would do in such circumstances, based on my belief that over the long term my career would be enhanced by these actions. Your career may be different. Following such advice could get you disciplined, fired, blacklisted, or possibly sued. Evaluate the advice within this magazine in terms of your own career, situation, and tolerance for risk.

To the 99% of you who make honest livings and don't litigate every time you meet misfortune, I apologize for the necessity of including this disclaimer.

Steve Litt can be reached at Steve Litt's email address.

Response Time Avalanche

By Steve Litt
"There's nothing harder than maintaining a five day repair cycle." This was spoken by the Pacific Stereo regional service manager during my training. He explained that once the repair cycle exceeds 3 days, time spent on phone calls, excuse sessions, paperwork and rework increases. Therefore repair cycle slows further, exacerbating the previously mentioned problems, further slowing repair cycle...

Where does it all end? What stops the response time from becoming infinite? A decrease in customers. They pick up their repairs unfinished. Word gets out. They don't call. Cash flow slows to a trickle.

You're toast!

Critical repair times are different in different industries. In stereo repair it's 3 days. In software support it's often more like 3 hours. It's the amount of time you can wait before the delayed repair begins to generate nuisance phone calls and paper work. Once you pass that point, if you didn't have the time to lower the repair time before, you certainly won't now. Response time avalanche brings big problems.

Preventing response time avalanche is a matter of improving productivity. Assuming you're already a ninja Troubleshooter, that improvement can come from refusing extremely difficult assignments, especially if they're not "worth it". It takes some guts to tell your boss that there are certain activities you cannot do, and in fact telling him or her that could get you fired. But if you fall into a response time avalanche condition, you'll probably be fired soon anyway.

A second method of increasing productivity is easiest first prioritization. Once again, it's often contrary to company policy, thereby risking discipline or termination, but if the alternative is response time avalanche... Easiest first prioritization works because every problem and task, no matter how trivial, carries a significant fixed cost overhead. Quickly addressing the easy problems greatly reduces that overhead.

Recovering from an avalanche condition requires quick and massive intervention. Refusal of unprofitable repairs or tasks, easiest first prioritization, and typically temporarily throwing bodies at the problem. Once the repair time is back within efficient limits, remove the bodies but continue easiest-first and selectivity in tasks undertaken.

But Be Careful of Local Optimization

Local optimization is a huge mistake. It's typically a mistake made by management, but the individual can make the mistake too. Local optimization is a condition in which a person or department puts out huge production, but its timing or product mix is such that it doesn't help the organization as a whole. In other words, if nobody can build products until you finish a fix, you'd better do that fix right now and put off other fixes, even the easy ones, until that problem is solved.

The preceding paragraph describes something very different from "squeeky wheel", in which one manager gets a bee in his bonnet and expedites. That manager is just doing local optimization himself.

In my personal opinion, the people setting your priorities owe you an explanation of why those priorities are "hot", and you are owed the assurance that honoring their request will not negatively impact your performance measurements, performance review, or future salary. Requests that don't "smell right" are often best confirmed in writing.

WARNING: Arguing on the job can get you disciplined or fired. If you follow the preceding advice, you do it at your own risk. I am not responsible. I have just related the way I handle most of these situations. Of course, I'm an independent contractor, so it's easier for me.

In evaluating your situation, consider whether or not you'll be disciplined, fired or passed over *because* you follow the orders. Contrast that with the likelihood of problems for refusing widowmaker tasks. Then do what you think is best.

Steve Litt can be reached at Steve Litt's email address.

Why "Easiest First" Boosts Productivity

By Steve Litt
Why is "easiest first" prioritization the most productive? It's not rocket science. Consider these three facts:

Fixed Per Day Costs

Let's start the discussion with fixed costs. Every item on your issue list, repair log or todo list is something you're doing for a boss, co-worker or customer. Every one of those people has a strong interest in his or her pet task. Enough of an interest to generate phonecalls and emails. Enough interest that you need to answer time consuming questions and issue time consuming progress reports. All that stuff takes away from your Troubleshooting time.

Imagine for a second that you have eight fixes requiring an hour apiece, and one fix requring eight hours. Two 8 hour days, assuming all time is spent Troubleshooting. But it isn't. Let's oversimplify and say that every open item generates four eight minute calls per day, and for further simplification let's say it comes in steadily at 4 minutes per hour, and let's temporarily forget that each interruption costs much more productivity than its duration.

The following is a spreadsheet showing the progress with easiest-first, assuming each outstanding problem requires 4 minutes per hour overhead, and handling everythings as fractions:
hour unfinished total min phone min work min units completed
this hour
0 9 60 36 24 0.4 1 repair every
60 work minutes
1 8.6 60 34.4 25.6 0.426667  
2 8.173333 60 32.69333 27.30667 0.455111  
3 7.718222 60 30.87289 29.12711 0.485452  
4 7.23277 60 28.93108 31.06892 0.517815  
5 6.714955 60 26.85982 33.14018 0.552336  
6 6.162619 60 24.65047 35.34953 0.589159  
7 5.57346 60 22.29384 37.70616 0.628436  
8 4.945024 60 19.7801 40.2199 0.670332  
9 4.274692 60 17.09877 42.90123 0.715021  
10 3.559672 60 14.23869 45.76131 0.762689  
11 2.796983 60 11.18793 48.81207 0.813534  
12 1.983449 60 7.933795 52.06621 0.86777  
13 1.115679 60 4.462715 55.53729 0.925621  
14 1 60 4 56 0.116667 1 repair every
480 work minutes
15 0.883333 60 3.533333 56.46667 0.117639  
16 0.765694 60 3.062778 56.93722 0.118619  
17 0.647075 60 2.588301 57.4117 0.119608  
18 0.527468 60 2.10987 57.89013 0.120604  
19 0.406863 60 1.627452 58.37255 0.121609  
20 0.285254 60 1.141014 58.85899 0.122623  
21 0.162631 60 0.650523 59.34948 0.123645  
22 0.038986 60 0.155944 59.84406 0.124675  
23 -0.08569 60 -0.34276 60.34276 0.125714  

In the preceding, the easy units are done at a rate of 1 unit every 60 working minutes, with working minutes per hour rapidly increasing as easy units are completed. When it comes time to do the difficult unit, 56 out of 60 minutes per hour are working minutes, so the difficult repair is done speedily.

Compare that to hardest first, as shown below this paragraph. The difficult unit is attempted with overhead from eight easy units consuming over half the time. The tough unit is finally completed in hour 19, just 4 hours earlier than it would have been completed with easiest-first. The easy units, which begin in hour 19, take the same 13 hours they did in easiest-first, because the only difference is the single hard unit that's been completed. The hardest-first prioritization takes 31 hours -- 8 more than the 23 for easiest-first. Easiest-first improved productivity by approximately 30%.
hour unfinished total min phone min work min units completed
this hour
0 9 60 36 24 0.05 1 repair every
480 work minutes
1 8.95 60 35.8 24.2 0.050417  
2 8.899583 60 35.59833 24.40167 0.050837  
3 8.848747 60 35.39499 24.60501 0.05126  
4 8.797486 60 35.18994 24.81006 0.051688  
5 8.745798 60 34.98319 25.01681 0.052118  
6 8.69368 60 34.77472 25.22528 0.052553  
7 8.641127 60 34.56451 25.43549 0.052991  
8 8.588137 60 34.35255 25.64745 0.053432  
9 8.534705 60 34.13882 25.86118 0.053877  
10 8.480827 60 33.92331 26.07669 0.054326  
11 8.426501 60 33.706 26.294 0.054779  
12 8.371722 60 33.48689 26.51311 0.055236  
13 8.316486 60 33.26594 26.73406 0.055696  
14 8.26079 60 33.04316 26.95684 0.05616  
15 8.20463 60 32.81852 27.18148 0.056628  
16 8.148002 60 32.59201 27.40799 0.0571  
17 8.090902 60 32.36361 27.63639 0.057576  
18 8.033326 60 32.1333 27.8667 0.058056  
19 8 60 32 28 0.466667 1 repair every
60 work minutes
20 7.533333 60 30.13333 29.86667 0.497778  
21 7.035556 60 28.14222 31.85778 0.530963  
22 6.504593 60 26.01837 33.98163 0.56636  
23 5.938232 60 23.75293 36.24707 0.604118  
24 5.334114 60 21.33646 38.66354 0.644392  
25 4.689722 60 18.75889 41.24111 0.687352  
26 4.00237 60 16.00948 43.99052 0.733175  
27 3.269195 60 13.07678 46.92322 0.782054  
28 2.487141 60 9.948564 50.05144 0.834191  
29 1.65295 60 6.611801 53.3882 0.889803  
30 0.763147 60 3.052588 56.94741 0.949124  
31 -0.18598 60 -0.74391 60.74391 1.012398  

The preceding model is very theoretical, with many assumptions and simplifications. But I think it's fair. In fact, my experience tells me that you get *much* more than a 30% productivity increase switching from hardest-first to easiest first. I think the preceding model understated the improvement for two reasons. The first reason is that an 8 minute interruption costs much more than 8 minutes of productivity. Depending on the nature of the work, returning to your original mental state could cost up to 20 minutes over and above the actual interruption time. Secondly, the overhead of repairs, issues and tasks skyrockets as their delay increases. The estimate of 8 minutes of phone calls per incomplete task per day could be much more if the system goes into response time avalanche. Do the easy ones first!

Unsolved easy ones often become difficult with time.

A stitch in time saves 9. How many times have we seen trivial problems become critical because they were ignored too long. A classic case is an insurance payment. Send it a few days before the due date and it takes 5 minutes to make out the check, place it in the envelope and place it in the local mailbox.

Wait until a day before the due date and you spend an hour going to the post office, waiting in line, and sending it next day air.

Two days later, you spend hours in the insurance company's phone system, navigating unfathomable menus, speaking to intelligence-challenged clerks, before you finally (hopefully) get an extension, after which you still need to send in the check.

And of course, if you wait much longer you'll be shopping for new insurance, and we all know how easy that is.

If a tough task is bollixed up due to delay, that's sometimes unavoidable. But to have a trivial task become a major ordeal is nothing short of negligence. Do the easy ones first!

Sometimes unsolved tough ones go away.

Think of how many projects get cancelled. If you perceive a task as extremely difficult, it's likely that others will too, and cancellation becomes more probable.. How would you feel if you spent several days on the project, putting your easier tasks aside, only to have the project cancelled?

Of course, the same argument could be made for easy tasks -- they can get cancelled too. But if they do, you're only out a few hours, not days or weeks. Do the easy ones first!

Steve Litt can be reached at Steve Litt's email address.

Prioritization Methodologies

By Steve Litt
Many prioritization strategies are used in business today. None of them, not even Easiest First, is uniformly "the best". Different circumstances call for different strategies. But Easiest First is usually a safe bet. This article discusses the following strategies:

First in, first out

This is the darling of repair shops and often help desks. It's almost never appropriate. The problem is that it forces you to endure excessive per-unit fixed costs for the sake of appearing "fair". Adopting this prioritization forces 80% of your customers to endure the inconvenience for the 20% with tough fixes, but does very little for the people with the tough fixes. In some cases, it delays even the toughest repairs due to overhead from easy units in line behind the tough ones. This is no way to run a shop, help desk, or anything else.

The perception of "fairness" is addressed by simply telling customers to "call us at such and such time". The time the customer is told to call depends on the expected difficulty of repair. For that rare customer (internal or external) getting itchy, explain about ordering parts, or intermittence testing, or extra time consuming diagnostic tests, or whatever makes the unit difficult.

It's been my experience that when done right, substitution of easiest first for first in first out invariably greatly improves the experience of over 90% of the customers, users, or whatever, and *mildly* delays the rest.

Prioritization by Inconvenience

This is either stupid or mean, depending on whether the organization has a monopoly. The idea is to bottleneck the amount of service by making it incredibly inconvenient to do business with the organization. When an organization goes into response time avalanche, prioritization switches to prioritization by inconvenience. Only when the flow of business has been reduced to a trickle can the organization's fixed cost weakened productivity keep pace with the incoming business. Obviously the organization dies.

Unless, of course, they have a monopoly. Visit your local HMO and you'll see what I mean. Most HMO's cynically restrict service by endless paperwork, maze like phone systems, contradictory information and the like. After all, they already have your money (called a capitation fee). And because they have a monopoly (this all began with a doctor shortage, and if you don't believe that ask why you've never met an unemployed doctor). The HMO's sole purpose is to lower medical expenditures by slowing the demand for service through the tactics described above.

So if your organization has a monopoly, you've already got the money, you want to chintz on your expenses, and you have no conscience, by all means practice prioritization by inconvenience. But if you have competition, prioritization by inconvenience quickly strangles cash flow and kills the organization.

Prioritization by Importance

This is a close cousin of "Easiest First", and is often appropriate. Prioritization by importance is a principle. The principle is that the more it costs to keep an outstanding repair, issue or task open, the more you prioritize it. Such costs include fixed costs (the justification for easiest first), critical path maintenance, political issues (squeaky wheel), etc. The theory here is that the more time you spend working around these costs, the less time you have to do your work, so it's best to minimize any costs stemming from open repairs or issues.

Squeakiest wheel

This is a subset of prioritization by importance, and is almost universally a bad idea. The theory behind squeaky wheel prioritization is that you reduce inconvenience by not having the screamers yelling at you. Once someone starts yelling, there are phone calls to make, forms to fill out, meetings, explanations and the like. So at first glance it would seem like an excellent idea to grease the squeaky wheel first. But there's a problem.

The problem is, word gets out that the way to get service is by yelling. Now, instead of having one screamer consuming your valuable time, everyone is screaming. Productivity goes down to zero.

We adults aren't that different than children. If your kid pitches a fit at a store wanting a piece of candy, it might be tempting just to buy it for him. But you don't. Because you know if you buy it, your child will pitch a fit every time he wants something. Hey, it worked once, and he's a fast learner.

This is also the principle behind many countries' refusal to negotiate with terrorists. Many believe that the lives you save by negotiating today will be vastly offset as more and more people decide that terrorism is the way to get your way.

So for the good of the organization, unless the screamer has a dead-bang perfect reason for screaming, it's counterproductive to give in to him.

The reason screaming is called "squeaky wheel" is because of the old saying, "it's the squeaky wheel that gets the grease", referring to a covered wagon or stagecoach with a squeaky wheel, which of course you'll grease. This explanation also reveals a truth about the squeaky wheel syndrome. The wheel squeaked for lack of sufficient preventive maintenance.

In the same way, much corporate or customer yelling takes place because of flaws in systems, procedures or prioritization.  If screaming is confined to one or two people, it's probably a problem with those people. But if it's more widespread, chances are they have a very legitimate gripe that must be addressed. Addressing that gripe will likely improve productivity and profit, and yes, reduce the inconvenience of screaming.

So here's the bottom line on "squeaky wheel" prioritization. Never give in to it, but instead affirmatively search, diagnose and eliminate defects in the organization that would plausibly cause screaming within the organization. Easiest first prioritization, coupled with an understanding of productivity from the organizational point of view, is a great step in fixing such defects.


Expediting is squeaky wheel on a rampage. It's necessary in those rare occasions when an unexpected opportunity or threat requires the organization to turn on a dime. But if it's a regular occurrence it's extremely disruptive. This is discussed more extensively in a separate article, Expediting: Destroyer of Systems.

Easiest First

As discussed previously, the Easiest First prioritization method boosts productivity by reducing per-task (or per-repair) overhead. The mathmatics of this were discussed in the article entitled Why "Easiest First" Boosts Productivity.

Hardest First

You hear this prioritization method espoused by many individuals. The theory is that doing the tough one immediately gives you a mental victory to use as a platform for the rest of the day's work. But it's equally likely that the failure or delay you face in doing the toughest one first will discourage you. Mental victories are much more likely to stem from easy fixes. And of course, Hardest First is mathmatically unsound, as shown in the article entitled Why "Easiest First" Boosts Productivity.

The concept of Hardest First prioritization is is contrary to all other human activity. Imagine jumping right into the hardest part of an exercise routine instead of warming up. Imagine learning high frequency electronics before learning ohms law.

The bottom line is this: If you're successful at Hardest First, you've got plenty of spare capacity that could be used more profitably Easiest First.

Steve Litt can be reached at Steve Litt's email address.

Expediting: Destroyer of Systems

By Steve Litt
Editors Note: This article appeared originally on MoreTime.Com, and is used with permission.  It reveals my opinion of expediting, and is therefore extremely topical for this month's Troubleshooting Professional.

It's far too common. A big customer or senior manager yells that if his task isn't done immediately, heads will roll.  And everyone dances to his tune. Tasks are shoved aside and forgotten. Workspaces are left messy. Setups are abandoned. 99 vital tasks languish while the entire workforce crowds around the "hot" task. Even those who can't possibly help make great pretense of involvement.

When the hot task is complete, the workforce goes back to the 99 "backburnered" tasks. Setups are re-done.  Workspaces are re-cleaned and re-supplied. Progress is re-remembered. Finally things are back where they were before the hot task kidnapped the workforce. But now five of those 99 tasks are behind schedule, so their five champions start yelling that heads will roll. And everyone dances to their tune...

Of course, once in a while every business must make a sudden and radical change of plans. An unexpected large earthquake or once in a lifetime sales opportunity must receive the full focus of the workforce. But when such diversions occur regularly, it's called expediting. No plan, no strategy, no system can long survive extensive expediting

It is said that "the squeaky wheel gets the grease". That might work well on covered wagons, but it kills businesses. Once word is out that a company is susceptible to the "squeaky wheel", everyone becomes a squeaky wheel, and the company thrashes about prioritizing instead of working to meet customer needs and bringing in revenue. If your employer regularly expedites, find a new employer quick. If you manage a business that regularly expedites, fix it before the marketplace fixes it for you.

Steve Litt is a long-time student and advocate of the quality movement (especially Deming), and a strong proponent of the Theory of Constraints (Goldratt, The Goal, etc.). He can be reached at  Steve Litt's email address.

Situations In Which "Easiest First" Fails

By Steve Litt
Easiest First prioritization often yields incredible productivity increases, but it can't be followed blindly. There are situations in which it fails. Some such situations are:

Vast Difference in Importance

The CEO wants a new website done in a week. A secretary needs you to take a quick look at her PC's malfunctioning email. Obviously, honoring several requests such as that from the secretary could make the major project late. If politically feasible (and it should be given who gave you the website project marching orders), tell the secretary you can do no work on her problem until the completion of the website project.

However, if it's decided that you must honor the secretary's request, it's probably best to knock it off right away so you can get back to the real work at hand. Be sure to document the time consumed by the secretary's request, including setup and teardown. Be sure to document who ordered you to honor the secretary's request.

True deadlines

Some tasks might as well not be done if they're not done on time. The classic example is delivering on a customer contract. He can cancel if you're late. Beating a competitor to market is another true deadline. Another true deadline is a situation in which a team of 20 application developers will need your tool twenty days from now, and if they don't have it they sit idle. These are reasons to postpone all other tasks, including the easy ones, until the deadline is met, or until you're absolutely on schedule to meet it. Once again, this importance should be acknowledged at the highest levels, and your performance evaluation should be based on your meeting the deadline, not on your "production".

The reason I use the word *true* in true deadlines is because in business there are many arbitrary deadlines. Some manager sets a "goal" to have it done on the 21st of the months, and by George, we're gonna do it. Probably the manager calculated the deadline based on getting the most out of his labor dollar, rather than any kind of competitive advantage gained by making the deadline, or avoiding any kind of serious problem caused by missing it. These arbitrary deadlines are the stuff death march projects are made of. I personally do *not* abandon easiest first for this type of deadline. Here's why.

From an organizational viewpoint, there's no pressing need to make this deadline. Especially if making it delays other projects. This deadline will likely slip once, twice, maybe many times. And with each slip, other work is once again pushed back. Considering that much of the organization may not be behind this project, it won't be viewed as a good reason to delay your other work. In my opinion, arbitrary deadlines are best viewed as business as usual, and handled easiest first. Unless you're being micromanaged to a fault your boss won't even know you're doing the easiest tasks. But he might marvel at your "organization" because you're not constantly rearranging undone tasks.

In summary, true deadlines are an excellent reason to abandon Easiest First. Arbitrary deadlines are not.

Safety Critical Situations

It's obvous you don't reupholster a seat on the airplane scheduled to take off in an hour when it has a hydrolic problem that could prevent lowering of the landing gear. When safety is an issue, all resources must be brought to bear in order to fix the problem before injuries occur.

This can be taken a step further. Some risks are economic rather than bodily injury risks. If your software is intermittently misplacing money, you'd stop writing that cool new subroutine and devote all resources to solving the intermittent problem.

In safety-critical environments it's best to follow policy exactly. Typically, the best minds in the industry have created those policies to prevent disasters.

Easiest First Doesn't Justify Expediting

Imagine an hour ago you finished all the easy ones and started a difficult project. Now an easy one has come in. Do you put aside the tough one and do the easy one? Probably not.

Interruptions are bad. You forget where you were. Work put aside risks lost materials, paperwork, files, etc. Dropping the current project the minute something easier comes in is just plain expediting.

If easy work piles up to the point where fixed costs are interfering with the difficult tasks, find a natural stopping point at which to put the difficult one aside, document where you left off so you can quickly pick it up later, and then quickly knock off the easy ones. But never just drop a tough one at first appearance of an easy one.

Easiest first doesn't mean easiest only

Easiest First prioritization takes discipline. The tough ones must be tackled during those inevitable slack periods. The slack periods are not the time to take long lunches, surf the net, or play video games. They're the time to do the tough projects.

Unnecessary is unnecessary, even if easy

It's possible to use Easiest First prioritization as an excuse for procrastination. "I'd like to fix that intermittent software crash, but I'm coding a kewl equivalent to the Unix date command". A responsibility that comes with Easiest First is to do only necessary tasks.

Now let me partially contradict myself. Throughout my career I've been amazed at how many of my "frivolous activities" later became extremely profitable. At a medical management company called Medi-Sec, a favor for a co-worker who had absolutely no authority to ask me to do anything ended up being a vital part of their receivables procedure. At Latham & Watkins, I wrote a cute little program to fix a problem with paper scanning, and it ended up being the timesheet front end they used for 8 years. At Troubleshooters.Com, I unleashed a bitter diatribe called "Corporationally Incorrect" in the April 1998 Troubleshooting Professional Magazine. There was absolutely no business justification for that diatribe. But that issue of Troubleshooting Professional ended a 15 month series of low traffic issues. From that point forward, Troubleshooting Professional Magazine attracted big traffic and contributed greatly to my income.

Judging the "necessity" of a task or project requires experience and maturity. It's often best to play it safe and do only the necessary tasks assigned by your superiors. Unless you work like me :-)

Steve Litt can be reached at Steve Litt's email address.

Common Objections to "Easiest First"

By Steve Litt
This article rebuts the three most common objections to the Easiest First prioritization method:
  1. It's not fair
  2. It's against policy
  3. But the tough ones will never get done

"It's Not Fair"

Imagine standing in line at your local fast food place. A long line. Imagine the counter person waiting on people walking in the door, when you've been waiting for 15 minutes. Frustrating, to say the least. And definitely not fair.

Now imagine your car waiting for a day while fifteen other cars come in and get fixed. Not fair, right? Of course it's not fair. It's exactly the same situation.

Or is it? Your car's waiting in line, you're not. With proper planning and scheduling, you can go on about your business. It's not a big problem if the repair takes a few extra hours. And you probably won't even know the order in which the cars were repaired. The concept of "fair" becomes less clear cut.

Now come the tough question: Is it fair to make a person wait a day because someone with a tough repair happened to walk in 10 minutes earlier? Is it fair that 10 people have to wait?

First in first out isn't any more fair, it's just more understandable to all. Is first in first out *less* fair? Yes. Everyone waits for the additional per-repair fixed costs caused by delaying the easy repairs. First in first out usually degenerates into lose lose lose. The people with the easy repairs lose big time. The people doing the repairs lose big time. And the people with the tough repairs might win slightly, lose slightly or break even. And if the organization is being run right, there will be only few tough ones.

As long as even the tough repairs, tasks or issues are done in a reasonable amount of time, easiest first is very fair.

"It's Against Policy"

Policy is a very valuable tool preventing "reinventing the wheel" when it comes to decisions. We'd live in a truly unproductive world if every action required a complete decision process. But unless a policy is revisited from time to time, there's a serious danger of creating a suboptimal system. If it's suboptimal enough, an organization's very survival can be jeopardized.

Imagine a small city with two "rent a technican" outfits. Mine operates on Easiest First prioritization. Joe's is "first in first out". My techs incur half the expense per fix. My time to solution (response time plus troubleshooting time) is half that of Joe's. My customer satisifaction is twice that of Joe's. Unless Joe changes his policy, he'll be out of business in a couple years.

"But the Tough Ones Will Never Get Done!"

This reaction to Easiest First prioritization is such a standard as to approach cliche status. The cliche answer is "I said easiest first, not easiest only".

If you have a 2 month backlog, aren't you just fooling yourself saying everything's getting done? You're practicing prioritization by inconvenience. People leave long lines. And they complain.

If the tough ones aren't getting done in an Easiest First environment, there will be even less productivity in a First In, First Out environment. We proved that mathmatically in an earlier article.

If, in an Easiest First organization, the tough repairs are not getting done, there are only three possible causes:

  1. There are too many difficult or unprofitable repairs or tasks
  2. The staff slacks off after completing the easy ones
  3. There's more profitable business than you can handle

There are too many difficult or unprofitable repairs or tasks

This is a management problem. Management must either boost prices to make such repairs profitable, be selective and not take in as many difficult repairs, or find procedures and systems to make these repairs simple. Otherwise, they will continue to lose money on every repair.

I wish I had a dollar for every repair shop I've seen that took in any kind of junk the customer brought in. They lose money on every one. But they justify it because "if I didn't take junk, I wouldn't have any work at all".

Faulty logic. If they simply refused the unprofitable repairs, and spent the freed up time marketing in order to bring in profitable repairs, they'd be in the black in no time. Believe me people, I've seen it happen, and I've done it myself.

In corporations, unprofitable tasks are a management problem. Typically two or three managers are involved in a turf war throwing junk work at each other, or getting the big guy way up the ladder to do it for them. If you're a manager in an organization like this, fix it. Talk to the other guys, get an organizational goal and focus, and everyone aim toward that goal. If you're a little guy, the best advice I can give you is document everything, so when someone asks you why you're working so slow, or tries to force you to work 80 hours a week on a regular basis, you can clearly state your position. Better yet, get a better job.

BUT! Make sure the repair or task is really unprofitable, and it's not just a case of your not knowing the best way to accomplish it. In the case of a sizable organization, sometimes it only seems unprofitable. For instance, if you work a week on a repair, but once completed that repair enables another production line making the one part whose shortage is causing late deliveries, it's a *very* profitable repair. In such a case, management should prioritize your work to cut you some slack from your other work.

The staff slacks off after completing the easy ones

The prioritization method is Easiest First, not Easiest Only. The people without the discipline to finish the tough ones have a problem that needs correcting. This is not a management problem.

Note that I'm not saying that you should work 80 hour weeks to complete the tough ones. What I'm saying is that the vast majority of the normal workday should be spent working (the exception is Step 9, Take Pride). There are always slowdowns in the flow of work. Those are the times to do the tough repairs and tasks.

There's more profitable business than you can handle

Congratulations, it's time to hire more employees and make more money. This is what every corporation hopes to achieve. Note, however, that if there's a reason to believe the voluminous flow of profitable work is temporary, paid overtime or temporary workers is a better solution. Unpaid overtime is risky -- morale problems almost always cut into profits one way or another.
Steve Litt can be reached at Steve Litt's email address.

"Easiest First" and the Theory of Contstraints

By Steve Litt
At first glance it would seem the practitioner of Theory of Constraints (TOC) would laugh at Easiest First. It would certainly be laughable to add yet another inexpensive inspection station, when the million dollar robot that feeds that inexpensive inspection station has a huge incoming inventory pile. The easy addition of the extra inspection station would do nothing to offload work from the robot (I'm assuming here that the production is sound and inspection stations find very few defects). The correct solution would be the financially difficult task of adding a second robot, or the equally difficult task of finding a way to route some production around the robot, or if the robot was not running around the clock, to get it to do so.

And I'm not going to cop out by saying that TOC works only on factory floors. My experience tells me the theory of constraints works everywhere. And besides, most white collar work is done in a factory -- a *knowledge factory*. And therein lies what I believe to be the TOC justification for Easiest First.

In a knowledge factory, it's quite likely the bottleneck (constraint) is the level of mental interruption. How much does a mental interruption cost? I've heard the 20 minute figure bandied about. After a 30 second phone call, it supposedly takes an application developer 20 minutes to regain his pre-phonecall mental state. As a 15 year veteran of programming, that sounds reasonable to me.

Imagine the impact on a developer's 12 hour day. A mere 9 incoming phone calls a day costs him 25% of his productivity. 18 calls cost him 50%. At 36 incoming calls a day, his productivity nears standstill. Of course, few programmers get anywhere near 36 calls a day, for precisely this reason. But there are many similar interruptions, such as bosses demanding status reports on various projects. Consider that each open "issue" (for want of a better word) on a developers plate generates regular incoming phone calls, and the calling frequency is not related to the difficulty of solving the issue. Wouldn't it make sense for the developer to spend the first hour of the day knocking off most of the easy issues, so they won't generate interruptions during the workday?

As you can imagine, few other knowledge workers require 20 minutes to regain their pre-interruption mental state. For a salesman, it might be 1 minute to 10 minutes, depending on whether he was chatting with a client, or assembling numbers for a new proposal. But of course, it's easy to imagine the salesman getting upwards of 100 incoming phone calls per day. At an average of 2 minutes to regain state, that's over 3 hours lost. And remember, the argument that he was productive during the phone call has no bearing, because the 3 hour loss does not take into account the (productive) time he spent on the phone. It's only the (nonproductive) time he spent returning to the pre-interruption mental state.

So to the extent that a person's bottleneck is per-outstanding-task overhead interruptions, the personal optimization is Easiest First prioritization.

Of course, local optimzation of all personnel and departments rarely leads to global optimization. The employee needs to tune his local optimization to deliver the needed work product when needed. That means that if the Orlando office really needs to go online in three days in order to fullfill their contract, you must give all necessary assistance to that effort, even if you need to put aside easier (but not as urgent) tasks to do it. But often local Easiest First prioritization aids global optimization...

You can't get the Orlando office work done with the phone ringing off the hook. If you can knock off half your outstanding responsibilities in a few hours, thereby decreasing interruptions by something like 50%, you can actually get Orlando done sooner. Naturally, this doesn't work if recipients of completed tasks turn around and tell you "that's great, but I also want this feature". That can be handled with a quick email saying you're on assignment til Wednesday (perhaps drop the name of the executive leaning on you to do Orlando), and that you'll discuss it when you come off assignment. Of course, you could have dropped him that email before completing the easy task, but it would have looked like a "shuffle off to Buffalo", possibly generating a time consuming political tiff. Besides, sending the email preemptively would require sending it to all users of your work product, not just the few asking for further enhancements.

You might think that early delivery of the easy tasks is contradictory to JIT (Just In Time) inventory. If these tasks were 27" televisions each consuming 10 cubic feet and weighing 50 pounds, you'd be right. But most of todays knowledge products are files that can be easily stored and retrieved in the world's most efficient file cabinet, the personal computer. The computer minimizes negative impacts of excess knowledge inventory.

Is Easiest First prioritization compatible with the Theory of Constraints? Not always, but surprisingly often. When the compatibility is there, by all means go Easiest First.

Steve Litt is a big fan of Eliyahu Goldratt, his book "The Goal", and the Theory of Constraints revealed in that book and others by Mr. Goldratt. Steve can be reached at Steve Litt's email address.

Justifying "Easiest First" to Users, Customers Partners and Management

By Steve Litt
We've all experienced situations where someone who comes in after us is served before us. It feels unpleasant, and often leads to a "lively chat" with management. It's human nature to want to "get our fair share".

If you've read this far you're probably convinced that Easiest First yields valuable productivity gains. But how do you justify them to users, customers, partners, and management?

Your justifications depend on your situation. Here are some of the justifications I find most helpful:

Isn't this dishonest? Yes, if what you're really doing is delaying repair til you finish the easy ones. Is such dishonesty wrong? That's a call each of us has to make. My policy is as long as every customer gets a reasonably timely repair, and as long as my actions accomplish the greatest good for the majority, I feel good about what I'm doing.

Of course, I usually come right out and tell customers their unit will take longer because I expect it to be difficult. I also explain that it still won't take as long as many competitors. They usually appreciate that.

Steve Litt can be reached at Steve Litt's email address.

Linux Log: We Did the Easy Ones First

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
The Linux invasion is a study in Easiest First prioritization. It makes me wonder if Easiest First is really the natural state of a human team without politics and powerplays.

Look what we did. We started by appealing to the geek hobbiest. The guy who has always wanted a UNIX computer in his bedroom. This was almost no sell at all. The conquest of the geek hobbiests guaranteed a supply of Open Source developers and ambassadors.

Linux already had sendmail, Apache, DNS, Perl. Add a high bandwidth line, and it's like an ISP in a box. So that's what the Linux community did next. It was by far the easiest and cheapest way to become a web host or dialin provider (or both). And because the adopter was a small independent, there was no predisposition to go with NT, IIS and ASP. Once again, an almost trivially easy sale. And as these small ISP's proved solid, Linux's reputation began to change from geek hobbiest toy to a route to moderate wealth.

Those early ISP adopters had friends in the Enterprise. These friends were tasked to construct Internet and Intranet websites. They often had that old corporate mandate -- "you can't have any money, you can't have any people, but you must do this project". Linux was the answer. Not only was their project on time and under budget, but it was more reliable than its NT/IIS/ASP cousins. The suits, even the Wall Street pundits, began to take notice.

On a parallel track, the Samba team had created file and print serving software that, in many cases, made NT servers redundant. But politics made it a difficult sell. Doing the easy task first, network admins used Samba equipped servers for those "quickie" networks with no time for budgets or approvals. Everyone noticed that those quickie servers were more reliable than their costly NT cousins. Forward looking managers began specifying Linux/Samba for file servers.

So far Linux had won using only technology it already had. Now, armed with heavy geek, corporate technologist, and Wall Street support, we began enhancing the product to invade Microsoft's turf. Hardware support and easy installation became a priority. GUI front ends moved from Army Surplus look and feel (we're talking about fvwm2 here) to an almost total knockoff of Windows (kde). Applications (spreadsheets, word processors, presentation programmers, graphics programs, fax programs, Internet programs) emerged so that the "but there are no applications" objection no longer carried weight. The result was that power users could now begin using Linux as a desktop productivity appliance.

Concurrently with Linux's desktop conquest, others were enhancing Linux for big iron. By far the easiest was Linux clustering, which used a bunch of boxes with standard Linux and a parallel enabled computer program. Everyone who reads the paper is aware that scenes in the movie "Titanic" were created with a relatively cheap Linux cluster supercomputer. Word was out -- if you need a supercomputer but don't have the budget, dumpster dive for a bunch of old 486's, install Linux and Ethernet cards, write the app for parallel processing, and you've done magic. I'm very proud that two Linux parallel supercomputer pioneers, Forrest M. Hoffman and William W. Hargrove of Oak Ridge National Laboratory, wrote about their Stone SouperComputer in the May, 1998 issue of Troubleshooting Professional Magazine.

Meanwhile, IBM began embracing Linux and Open Source in a big way. Today you can get Linux for modern IBM S/390 mainframes. And IBM recently (July 31 2000) introduced pricing so you can add processor capacity exclusively for Linux apps, without getting charged higher prices for licenses to non-Linux software. Now you can economically scale that mainframe to house a Samba file server, complete with server side automation. So while Windows 2000 runs only on x386 type processors (albeit huge clusters of them), Linux now runs on genuine mainframes.

So here we are in mid-summer 2000, continuing our easiest first conquest of the desktop and server markets. This easiest first prioritization has been driven not by policy, or re-engineering, or the report of a committee. No, it's been driven by something that, if Adam Smith had been born in 1980, might have been called "the invisible hand of Open Source".

How does Linux achieve world domination? Maybe it's as simple as doing the easy ones first.

Steve Litt is a member of Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.

URLs Mentioned in this Issue