Distance Consulting Logo

Improving the Performance of People, Processes and Organizations

Articles      Columns      Projects      Resume      Services      Tool Room

Three Case Studies in Figuring Out What to Do

Solution Engineering in Action

Fred Nickols 2012


This is the second of two articles that center on a mythical management consultant named Charles "Lucky" Luciano and on the process of Solution Engineering.   The first, Why Those Darn Training Problems Won't Go Away, was published in Performance and Instruction in 1990 and led to a nice letter from Jack Gordon, editor of Training Magazine. So, I wrote this one for Jack, which appeared in slightly different form, with the title "Figuring Out What to Do," in the August 1991 issue of Training Magazine.


Darryl McKisson has a problem. The average reject rate for one of the programs supported by the document scanning operation in his division stands at a whopping 60 percent. Darryl wants something done about it -- and pronto. What should he do?

Sandy Schneider has a problem, too. Recently, she was given the assignment of developing the training in support of an effort to triple the size of a highly technical customer service work force. She has 90 days in which to work this minor miracle. Unfortunately, her plan of contracting out the training has just been doused with cold water: All the training firms she contacted have declined to bid, claiming that the assignment is impossible. What should she do?

Even good ol' Burnell Farmer has a problem. The costs of the labor-intensive operation he manages have crept steadily upward during the past few years and he is now under intense pressure from senior management to reduce the costs of operations -- but layoffs are out of the question. What should he do?

Enter Charles "Lucky" Luciano, a little-known but handsomely-paid management consultant -- one who is worth every penny of his sizable fee because he knows how to solve problems. He is very good at figuring out what to do. So, let's follow Mr. Luciano as he makes his way through the three cases outlined above.

The Case of The Reject Rate

Darryl McKisson works for the American Testing Corporation (ATC), where he is the director of ATC's licensing and certification division. ATC has many such programs, one of which is MLAST, a state-authorized competency test of medical laboratory assistants. Under its contract with various states, ATC tests medical laboratory assistants and the states then grant or deny certification based on these test results. Lacking state certification, the lab assistants cannot be legally employed by any state-licensed laboratory.

The tests, written and performance-based, are administered in the field, at the laboratories employing the lab assistants. To take these tests, the would-be lab assistants must first register for a specific test administration date. The registration form contains both printed and gridded or "fill-in-the-bubbles" information.

The rejects that are at the center of Darryl's problem come about as follows: The registration forms are received, batched, and then scanned. The gridded entries are "read" by the scanner and the data obtained in this manner are loaded into a computer and edited (i.e., checked for missing data, double-gridded entries, and invalid entries). Any records failing these edits are rejected for manual review and resolution. The reject rate typically runs anywhere from 50 to 70 percent of each batch of registration forms scanned. The reject rate has always been that high.

Darryl has known Luciano for several years and asks Lucky if he would be willing to tackle the problem. Lucky, glad to oblige, digs into the reject rate problem and unearths the following information.

Judging by their comments, the members of Darryl's resolution staff believe that the aspiring lab assistants are incapable of filling out any form properly. Lucky thinks otherwise.

Luciano asks for and receives a copy of the instructions given to the lab assistants. Reading them, he is hard-pressed to refrain from shaking with uncontrolled mirth.

The instructions for filling out the registration form are vague, incomplete, and make no mention of the consequences of errors (e.g., delays in processing that lead to delays in testing that lead to delays in certification that lead to delays in employment and the associated loss of income). In light of the complexity of the form, the instructions are also extremely brief; less than two pages in length. Worse; the instructions are not keyed to the items on the registration form.

Of particular significance to Lucky is the discovery that a list of codes used by the lab assistants to look up a five-digit code for the laboratory where they will be tested and where they hope to be employed, is organized in numerical order instead of alphabetically by laboratory name, making it very difficult for the lab assistants to look up the code for their laboratory. Invalid or missing codes account for almost half of all rejects. (The resolution staff, which required a numerically organized list for looking up laboratories, had simply provided the laboratories with a copy of their list instead of creating an alphabetically organized list.)

Lucky recommends that the instructions be rewritten (and that the code listing be reorganized in alphabetical order of laboratory names). His recommendations are adopted and Lucky personally undertakes the task of rewriting the instructions.

When Luciano completes his task, the instructions are 21 pages long, filled with step-by-step instructions for each of the 18 items on the form, including examples of properly filled out items and examples of improperly filled out items. The instructions also contain frequent cautions regarding the consequences of errors, with particular emphasis on delays in processing, employment, and paychecks. This version of the instructions meets with some objections but none are serious enough to preclude giving them a try.

On the occasion of the processing of the very first batch of forms filled out using the revised instructions, the reject rate plummets to just under nine percent -- and there it stays to this very day.

How did Lucky figure out what to do?

The Case of the 90 Day Wonders

Lucky gets wind of Sandy Schneider's problem through a friend who is marveling at the fact that some very prestigious training firms are turning up their noses at $250,000.00 (the dollar size of Sandy's budget). Quick to spot and exploit opportunity, Lucky asks his friend to arrange a meeting with Sandy.

Sandy is a senior member of the professional staff (MPS) in the Human Resources Development (HRD) department at the International Communications Corporation (ICC). One of ICC's divisions sells integrated voice and data business systems and these systems are selling much better than projected. The integration of voice and data, however, poses many unfamiliar problems for the systems staffs at ICC's customers and so ICC provides in-depth technical support via some especially high-powered technical representatives known as Customer Service Support Specialists (referred to internally as CS3s).

Owing to the higher than anticipated sales, there simply aren't enough CS3s in place to adequately support what is being sold. Past and future sales could well be in jeopardy.

Currently, there are 30 CS3s in place and the head of the business systems division has given Sandy one-quarter of a million dollars and 90 days to come up with 60 more.

Sandy did indeed send out RFPs to three of the largest and best-known training development firms in the country. All declined to bid and all for essentially the same reason: they said 90 days wasn't enough time to conduct a job-task analysis, let alone develop and deliver the training. Sandy is at her wit's end.

Mr. Luciano meets with Sandy, reviews the particulars of the situation, and informs her that he'd like a few days to ponder the matter before getting back to her with a proposal. He spends the next three days writing it.

Lucky begins his proposal by agreeing with the assessment of the training firms: 90 days isn't enough time to carry out the approach they customarily take. Unfortunately, as Lucky points out, "That doesn't answer the mail." Obviously, he argues, a different approach is called for.

Lucky suggests to Sandy that she recast the problem as a "staffing" problem instead of a "training" problem. He argues that most of the skill and knowledge requirements for the CS3 position can be met through careful selection.

He argues further that most of the skill or knowledge deficiencies that might be encountered would be either a) tied to specific system components, which would mean they could be addressed through packaged or off-the-shelf programs offered by the equipment manufacturers; or b) likely to vary from new-hire to new-hire, which would mean that no single training course could be responsive to any one new-hire.

In the end, Charles Alphonse "Lucky" Luciano proposes the following approach:

  1. Set aside the bulk of the budget, $200,000.00, to use in paying for off-the-shelf training courses.
  2. Use the remaining $50,000.00 to fund the development of selection and hiring guidelines, an inventory of available off-the-shelf training, an inventory of the support activities provided by the CS3s, diagnostic guidelines for the existing CS3s to use in determining which courses a given new-hire should attend, interview and observation guidelines for the new-hires to use in obtaining additional information about the job and its requirements, and anything else that might crop up along the way.
  3. Hire the new CS3s in two batches of 30 each, 30 days apart.
  4. Pair up the first 30 new-hires with the existing 30 CS3s already in place (i.e., establish a "buddy" system between the new-hires and the "old-timers").
  5. Provide the old-timers with one set of diagnostic guidelines and the new-hires with another set, and have the new-hires "shadow" the old-timers for a period of 30 days.
  6. Based on 30 days in the field with the old-timers, the new hires and the old-timers should both have a pretty good idea of the areas in which the new-hires might be lacking in knowledge or skill and the two of them can jointly lay out a training program aimed at remedying these deficiencies using off-the-shelf training packages.
  7. Next, put the first set of 30 new-hires in their own job slots, recognizing full well that precious few, if any, will be fully trained, but that all will have an experienced and savvy "buddy" on which they can call for guidance, direction, and specific assistance.
  8. At the same time, bring in the next batch of 30 new-hires, pair them up with the old-timers, and repeat the process. Thirty days later, they too will be out on their own, so to speak, with work assignments and their own training plans.

"At this point," concludes Lucky, "you'll have all 60 new CS3s in place, with training plans in hand, and a buddy system to back them up."

"But," calculates Sandy, "that's only 60 days elapsed time."

"I know," replies Lucky. "We'll use the first 30 days to compile a catalog of relevant off-the-shelf training packages and to put together some interview, observation, and assessment guidelines for the old-timers and the new-hires to use, plus whatever else we might find out we need."

"But," asks Sandy, "won't the 'old-timers' object to the added workload?"

"Not if we emphasize that this is a whole lot lighter load than trying to support all those customers by themselves," answers Lucky.

The following week, Sandy presents her new plan for addressing the "staffing" problem to the head of the business systems division. Following Lucky's suggestion, she has a single overhead transparency containing this simple equation: "30 + 30 + 30 = 90."

The head of the business systems division authorizes Sandy to carry out her plan. Ninety days later, the 60 new CS3s are in place, each with a personalized training plan, and each with an old-timer for a "buddy."

Lucky has a $50,000.00 entry on the plus side of his ledger.

How did he do it?

The Case of Doing It Twice

Burnell Farmer, manager of a rather sizable clerical processing operation that, like many such operations, dangles off a mainframe computer system, is feeling the heat from his vice president's intense and recently renewed pressure to reduce costs.

To make matters worse, Coopers-Booze & Jekkyl (CB&I), a fancy New York consulting firm, has just completed a study in which it suggests that sizable savings can be realized in Burnell's shop as a result of a) some unspecified "productivity improvements" and b) more efficient training for the swarms of temporary employees that swell the ranks in Burnell's shop at the beginning of each processing year.

Burnell's company, Data Processing Systems (DPS), processes applications for financial aid from college-bound students. This includes receiving, batching, keying, and then computing the student's requirement for financial aid, and then reporting all this to the colleges the student plans to attend.

The financial aid applications are lengthy, complicated, and contain printed alpha-numeric entries, numeric entries, and boxes to be checked. They contain a great deal of personal and financial information about the student and, in many cases, the student's parents. Further complicating matters is the fact that almost two-thirds of the 2,000,000 forms DPS processes each year are received at DPS in the first quarter of the year. Hence, the hordes of "temps."

Dean David, a senior consultant with CB&I, the New York consulting firm, recommended that Burnell's company avail itself of the services of a consultant who specializes in such projects: Mr. Charles Luciano. Today marks a preliminary meeting with this mysterious Mr. Luciano and Burnell is anxious to see if this new consultant has anything concrete to offer or if Luciano's fees will simply add to Burnell's expense problem.

Lucky Luciano is at that very moment out on the floor, talking with some of the DPS employees who are employed on a year-round basis. He already has ascertained that, in terms of volumes, the operation is a very large, and that Burnell's shop handles what are known as "correction documents."

Upon receipt, financial aid applications are keyed in a data entry shop, then submitted to a mainframe computer for processing. The computer performs a number of edits and, if the data fail the edits, a correction document is printed, identifying the form in question and listing a coded number for each edit that fails. The correction documents are "matched and batched" with the original financial aid applications and sent to Burnell's area for correction. The typical correction document contains from one to eight error codes. The average is three error codes per correction document.

Standing next to one of the correction clerks, Lucky muses to himself about the difficulty of observing the unobservable; namely, the work going on inside the clerk's head. After a while, Lucky notices that, on occasion, the clerk refers to a black, three-ring binder.

Waiting until the next such occasion, Lucky interrupts and says, "Excuse me, but why are you going to the manual?"

"I'm trying to figure out why I got this error message," replies the clerk.

"What do you mean, why you got it?" asks Lucky.

"Well," explains the clerk, pointing to the form, "you see this error message -- number 261?"


"Well," continues the clerk, "I could have gotten it for any one of five different reasons. So, the first thing I have to do is figure out why I got it. Then I can figure out what to do about it."

"Thanks," concludes Lucky and walks away, headed for his one o'clock meeting with Burnell.

In attendance at the meeting are Burnell, all three of his managers, two key supervisors, three representatives from the systems group, two people from marketing, and a member of the management services or internal consulting group (there, presumably, to keep an eye on Lucky).

The meeting begins with introductions, a few opening remarks by Burnell, and a request by Burnell for Lucky to share with them his background and experience, as well as any insights he might have into the problems faced by Burnell's shop.

"As I understand it," Lucky begins, "Dean David of CB&I recommended me to you. From what he's told me, he thinks I can help out by making the training of your temporary employees more efficient. Specifically, he thinks I can shorten it. If we can do that, then the costs of training your agency temps go down and the lead time for hiring them goes down as well. Further, if we can improve the training as well as shorten it, we should see additional reductions in costs as a result of having fewer drop-outs from the training, and from gains in productivity resulting from people getting up to speed more quickly. I also imagine that if we can reduce the error rate, then the time and costs associated with rework will also be reduced. Those results are on downstream somewhere, but, just a few minutes ago, I encountered a situation out on the floor that makes me think we might realize a gain in productivity right away."

"What's that?" inquires Burnell, instantly on the alert.

"I was watching one of the clerks process some correction documents and I noticed that at times she referred to her manual and at others she didn't. When I asked her about it, she said that some error messages appeared for more than one reason and when that was the case, she had to refer to the manual to see which reason applied. The case in point was error message 261."

"That's right," chimes in one of the supervisors, "there are five reasons for 261 -- and sometimes more than one applies."

"Well," continues Lucky, "it seems to me that the computer already knows the reason for the message. After all, it's the computer that's kicking out the correction document and it's doing so because an edit failed. Just how difficult would it be to modify the error message printing routine so it would print 261-1, 261-2, and so on, depending on the reason the edit failed?"

"That should be an easy fix," responds the head of the systems group.

"What?" explodes the supervisor who had spoken earlier. "You mean to tell me that for years now we've had to figure out why we got those messages and you could have been telling us all along?"

Beet-red, the head of systems, knowing that discretion is indeed the better part of valor, remains silent.

Next ensues a quick-and-dirty calculation of the cost of making the change to the system and the time and dollar savings in clerical costs of doing so. Eliminating the first step of the clerical procedure would provide a very real and tangible first-year savings of $60,000.00.

Lucky earned his fee in his first hour on-site. How did he do it?

Discussion: How he did it

Did Lucky solve the wrong problem in these cases? Maybe. Did he treat the symptoms instead of the "real" problem? Perhaps. Was he successful? His clients think so. Did his success depend in large part on his own experience and knowledge? You bet. Might someone else have come up with different and perhaps better solutions? Of course.

There are any number of points and perspectives on which and from which Lucky might be faulted for the way he solved these three problems. But there is one point on which it would be difficult to fault him:

Lucky selected an appropriate model or frame of reference from which to study, investigate and analyze the problem.

In the case of the reject rate being too high, Lucky began with an operations perspective. He was looking at a reject rate that was much too high.

Almost immediately, he ascertained that the reject rate was not due to scanner malfunctioning nor to torn or damaged documents. The clear and direct causes of the reject rate were the missing and erroneous entries being made by the lab assistants when filling out the registration forms.

This finding, in turn, invoked a view of the problem from a human performance perspective. In this scheme of things, Lucky's chief aim was to bring the lab assistants' "form-filling-out" behavior under control; hence, his examination of the instructions provided them. Hence, too, his subsequent rewrite of those instructions with special emphasis on the consequences of error.

Ultimately, then, Lucky focused on two factors related to filling out the form: 1) communicating to the lab assistants the information necessary to fill out the registration form properly and how to tell if it was in fact properly filled out; and, 2) communicating to the lab assistants the consequences of failure to fill it out properly (which included delays in processing and, consequently, delays in certification and employment).

In the case of the 90 Day Wonders, Lucky recognized immediately that Sandy was a victim of her own view of the problem. She had labeled it a "training" problem. With these blinders on, she was stymied; there was no way to get where she was going if she continued treating the problem as a "training" problem. Lucky recast the problem for her by relabeling it a "staffing" problem. This opened her thinking to the possibility of attaining the end she sought by different means.

In the case of the correction documents, Lucky began with no particular purpose in mind except to begin his own education about the processing operation he was expected to improve. However, when he realized that the very first step of the clerical procedure was one of repeating an analysis that had already been performed by the computer, he recognized immediately that this signaled a "productivity" problem traceable in turn to a "systems" solution. (Incidentally, by the time he completed his assignment for Burnell, Lucky had taken a total of $280,000.00 out of the cost of operations in Burnell's shop.)

Lucky, then, not only had several different frames of reference available to him, he was able to select from among these the ones appropriate to the matter at hand. Mr. Luciano holds several other views regarding problems and problem solving that have stood him in good stead over the years. These are worth reviewing.

Lucky abhors highly-structured approaches to problem solving. His view is that such approaches rely on linear, step-by-step analytical processes, and they make him feel like he's being put through his paces.

His own view is that problem solving is a bounce-around, cover-the-bases, investigative activity, more akin to police or detective work than to so-called scientific analyses. Lucky goes where the information takes him, not to the next step in some arbitrarily defined procedure.

Mr. Luciano's general views regarding problem solving can be summed up in the following basic points:

  1. To truly solve a problem, you have to do something; you have to take action.
  2. A problem, then, is nothing more (or less) than a situation that requires action.
  3. From this, it follows that a solution is nothing more (or less) than a course of action that, once implemented, changes the situation in such a way that action is no longer required.
  4. It is rarely the case that all we seek is to rid ourselves of what might be termed "the problem state." Darryl, for instance, didn't want to just get rid of the high reject rate; he wanted a much lower one in its place.
  5. Most often, it is the case that we seek some other state of affairs in place of the problem state, some new situation or set of circumstances that might be termed "the solved state." Burnell, for example, was looking for reduced costs of operations. How he got them was of secondary concern.
  6. The "causes" of the problem state are not always correctable. The causes of the upward "drift" in the costs of Burnell's operation probably can't even be identified, let alone corrected.
  7. Thus, it is important that we identify and keep the "solved state" fixed firmly in mind because, although we cannot always undo the causes of the problem state, there are other ways of bringing the solved state into being. Sandy Schneider's problem offers a case in point.
  8. When confronted with a problem, we sometimes know immediately what to do and we sometimes don't. Sandy Schneider thought she did and then found out she didn't. (As often as not, this is because we are clear about the problem state but not about the solved state.)
  9. Some problems require investigation before intervention and some don't. Those that do are the occasion for the kind of search activity that most of us have in mind when we use the term "problem solving." The search for a solution constitutes the investigative phase of problem solving.
  10. Successful investigation is a matter of knowing what you're looking for and where to look for it. (In the case of the correction documents, Lucky wasn't looking for anything in particular but, to his credit, he recognized it when he saw it -- which probably accounts in part for his nickname.)
  11. Investigation, the search for a solution, is guided by the frame of reference (or the framework of referents) the problem solver adopts during the investigation.
  12. The frame of reference one adopts is invoked, at least in part, by the label one places on the problem.
  13. Labeling problems is a valid exercise. There are indeed different kinds or classes of problems, calling for different approaches. But, when the wrong label is applied, the wrong frame of reference will be used -- and that can derail the problem solving effort (as was seen in the case of the 90 Day Wonders).

If you'd like to get some feel for how good a problem solver you might be, make a list of all the different kinds of problems you can think of (the list that follows will help get you started). Then, check off those classes or kinds of problems for which you have a conscious, rational, specific approach, one that is tailored to that particular class or kind of problem, and one which you can invoke at will in order to systematically identify and investigate the structure of the class of problem facing you.

If you check off more than three or four, give Mr. Luciano a call -- he might have a job for you.

Classes or Kinds of Problems

  1. attitude problems
  2. business problems
  3. capacity problems
  4. communication problems
  5. control problems
  6. feedback problems
  7. financial problems
  8. health problems
  9. legal problems
  10. management problems
  11. measurement problems
  12. morale problems
  13. motivation problems
  14. organizational problems
  15. performance problems
  16. personal problems
  17. personnel problems
  18. political problems
  19. production problems
  20. productivity problems
  21. psychological problems
  22. quality problems
  23. resource problems
  24. staffing problems
  25. systems problems
  26. technical problems
  27. training problems


About          Contact          Comments          Home


This page last updated on June 27, 2015