Troubleshooting Professional Magazine
|
Do the Easy Ones First |
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!.
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.
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.
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.
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.
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 | V |
| 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 | V |
| 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 | V |
| 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 | V |
| 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!
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!
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!
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.
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.
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.
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.
|
|
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.
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.
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.
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.
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.
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 :-)
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.
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.
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:
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.
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.
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.
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:
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.
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.
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):