- Categorize the Context
- Case Study: Peak Workload
- Focus on the Customer
- Gather Information Regularly
This chapter is from the book
This chapter is from the book
This chapter is from the book
Case Study: Peak Workload
Questions that expand understanding of a problem’s context could have been used to avoid the situation described in the following case: A utility company issued more than a hundred thousand bills each month. Most of the bills had first-of-the-month due dates, and were computer-generated in a single lengthy run about twenty-five days before each due date. The rest of the bills had due dates at five other points throughout the month—the fifth, tenth, fifteenth, twentieth, or twenty-fifth—and were produced in five comparatively short runs, also about twenty-five days before each due date. Because most customers sent in their payment close to the due date, the billing process placed a considerable workload on both computer and human resources in getting the first-of-the-month bills out and in processing first-of-the-month payments. The billing staff wanted to even out the workload so that it was spread throughout the month, and they wanted to accomplish the spread by reallocating accounts evenly across the six billing cycles.
)
The request came from a department that had credibility and clout in the organization, so it was easy to unquestioningly accept the request as stated. Besides, the problem seemed clear: how to distribute the workload more evenly.
If this request were submitted to you, what types of contextual questions would you want to ask? You could ask any of the previously listed business, impact, timing, or risk questions, but you might also ask questions that address a variety of additional factors such as personnel, financial, or scheduling issues.
When I’ve presented this case study as a seminar exercise, participants have listed such factors as staffing, workload distribution, problem history, financial impact, and implementation as areas of particular interest, and have suggested such additional questions as the following:
- What was the original reason for establishing the billing process this way? Is that reason still valid?
- What other departments would be affected by a change in billing cycles?
- What kinds of savings does the current approach provide, such as postage discounts for the high-volume mailing of first-of-the-month bills?
- What are the desirable aspects of the problem?
- What need is there for temporary personnel or overtime to handle the current peak workload?
- How long has this situation been a problem? Why has it not been addressed before?
- How would a distribution of payments throughout the month affect the company’s cash flow?
- How does computer processing currently accommodate the lengthy billing run each month without negative impact on other processing?
- How would the company’s customers be affected by a shift to a different billing cycle? How should they be advised and prepared?
- Who outside the billing department views this situation as a problem?
- Who might find the current approach preferable?
These questions are typical in that they constitute a mix of two types of questions: First are those that focus on the specific problem; second are questions that pertain more generally to any problem, such as those that ask who views the situation as a problem, who might prefer to keep things as they are, and what the desirable aspects of the problem are. All of these questions help define the problem. As Gause and Weinberg note, “Without some common understanding of the problem, a solution will almost invariably be to the wrong problem.”4
Group Brainstorming
Whenever I’ve used this type of case-study exercise in my seminars, I’ve found that people working in groups develop more pertinent questions than they do working individually.
It is clear that group brainstorming provides an effective catalyst for expectations management. It’s also clear that all members of the group need not have firsthand knowledge either of the specific business environment or of the system problem in order to identify appropriate questions. In fact, participants in companies most like the case-study company usually generate the narrowest range of questions, perhaps because they’re too familiar with the context. The objectivity of those least familiar with a problem sometimes leads to the best examination. Therefore, as suggested in Chapter 6, if you want to learn as much as possible about a customer’s problem, draw upon as many resources as you can, seeking the input of both those familiar and unfamiliar with the problem.
To further benefit from this technique, involve your customers in developing these questions, and encourage them to formulate some of their own. By making this question-generating process a joint effort as well as a routine part of your problem-solving methodology, you will improve the odds of a successful outcome. And in some cases, that outcome may include the determination that your customers’ original expectations were not realistic, and needed to be modified. At least, that was the case with the billing system request.
Unforeseen Interconnections
Any of these previously listed questions would have been valuable to ask at the start of the billing project on which this case study is based, but none were asked. Not only was the problem not explored in greater depth, but the reaction of numerous people who heard that modifications were being undertaken was, “It’s about time!” Everyone viewed the problem as straightforward. No one assumed the role of information-gathering skeptic. No one suggested that it might be wise to first evaluate the possible consequences of tackling the problem. Everyone, later on, wished they had.
In fact, the modifications turned out to have wide-ranging negative impact—on numerous computer systems, on operating procedures both in and outside the billing department, and on the utility company’s public image. By the time these major, previously unforeseen complications became apparent, it was several months into the system modification effort, and also well into the efforts of several departments to prepare for the new system.
As the project proceeded, it became increasingly clear that the “problem” only existed when viewed within the narrow context of the billing department’s staffing needs. But this problem, real though it was, was trivial by contrast with the negative consequences that would likely emerge if the company implemented the planned solution. Finally, after several slips in the implementation date while trying to tie off yet another loose end, systems staff and customers jointly agreed to terminate the project.