Unintended Consequences: The Case for a Business Case

Some painful lessons seem to require periodic re-learning. Lessons about unintended consequences come around again and again, like an ugly pony on a carousel. People familiar with the merry-go-round of implementing change without regard to business consequences recognize these lessons as they reappear. For those new to the project carnival, Payson Hall describes a ride on the ugly pony and how you can avoid it.

Sometimes we too quickly or too narrowly define business problems and the projects intended to solve them. We evaluate how things are and how we want them to be, identify the gap, and assemble a project to close that gap. Because our vision focuses on the problem at hand and our earnest efforts to bridge the gap, we sometimes fail to consider all the consequences of our actions. Does the target solution save time and energy, or simply transfer effort or cost elsewhere?

Analyzing a client's new approach to handle payment for our training services is an interesting case study. Their old process was straightforward, but did not result in timely payment for service. They changed their process, but failed to predict how the "improvements" might affect the whole process.

The Old Way
The process began when the client's training department contacted our company to schedule a class. Then the client's automated class registration system would build a roster from captured enrollment information. The number of enrollees was tabulated two weeks prior to the class. If the roster didn't contain the minimum number of students needed, we'd reschedule. If registration numbers were greater than the minimum, we'd proceed with the scheduled class. After class we sent an invoice to the training department, which they would forward to their accounting department.

The accounting department divided the class costs among the departments that sent employees to the course. Gathering money from each department took months, so we wouldn't get paid until several months after class was completed. No one likes getting paid late, so the client set out to revamp their process.

The Problem
When reviewing internal processes, the client found the bulk of the delay was the time consuming division of the bill among the participants' departments. To eliminate the tedious and time-consuming task of processing the separate internal charges, the responsibility of paying for the course was transferred to the individual participants.

The New Way
The new process begins just like the old one. The client's training department contacts us to schedule classes; they still provide us with a roster. Instead of sending one large invoice for the class, we send out invoices to each registered participant in advance, meaning we now have to process multiple payments. This introduced a few new steps: our billing team has to deal with more people when resolving outstanding invoices, and cancellations and refunds must be handled case by case. This requires more administrative hours on our end as well as on the part of individual attendees. If people cancel from class, they must contact both our company, and their own training department.

Two weeks before class, the training department verifies that the number of pre-paid enrollees meets the class size minimum. Before class begins, our instructors ensure all attendees present have paid and handle any exceptional cases (People who have paid but fail to show no longer receive refunds). Attendees then receives receipts to be filed with expense reports, which are submitted to their accounting department for processing. Now it's the student who has to wait several months to receive reimbursement.

With this new plan, some problems have been solved. The client's accounting staff does not have to divide the class invoice into fifteen individual departmental transactions based on the training roster. Savings: fifteen work-minutes per class, if we assume one minute per attendee. And the vendor (me) gets paid about sixty days sooner. Savings: roughly 2 percent of fee, about $150 to $200 per class.

Splinters from the Ugly Pony
Unfortunately this new process created some unintended consequences. Individual invoices mean fifteen more payments to process for both the client and us, which amounts to more time and more transaction fees from the credit card company. New expense: Increased labor and fees per class—over $500.

Cancellations require participants to interact with the client registration system and with our company to process credit card refunds. New expense: thirty person-minutes of client time per class, if we assume two cancellations per class.

Cumulative Effect
The new model increased administrative burden for class participants, the training department, and my company. New expense: about 300 work-minutes, if we assume twenty minutes per participant. This also adds burden to the client’s administrative accounting department—about fifteen expense reports. New expense: about seventy-five person-minutes, if we assume five minutes per participant expense report.

Because work is never transferred to someone else for free in our economy, the cost of increased labor will be counterbalanced by a forthcoming increase in class fees. Next year’s tuition costs will increase to defray the new administrative costs described above.

While there may be some hidden cost savings or other benefits, the cure seems worse than the original disease. Somehow, the project met the narrowly defined goal of solving the identified problem, but created new problems. The project may have finished on time and on budget, but a senior manager looking at the total effect of the project might be shocked to hear it called a success. Certainly the participants—the training department, my company, and even the accounting department—will all experience the increased costs of unexpected administrative overhead.

How can we avoid this problematic "success"? Careful consideration of any business case helps assure that the problem being solved is worth the energy, risk, and opportunity cost. Doing so also uncovers potential unintended consequences and allows sponsors to make conscious decisions about the costs they will incur. It is never a waste of time to fully understand the business case—the underlying need—behind a project.

When building or reviewing a project business case, consider the following questions:

  • What work does the project eliminate or transfer elsewhere (either to other parts of the organization, its suppliers, or customers)?
  • What new work will be required to support the new system?
  • What are the costs of implementing, operating, and maintaining the new system?
  • How much does it cost to run the current system?
  • What risks are eliminated by the new system? What risks are created?
  • How much do errors cost in the current system, and where are they detected in the process? What will they cost and where will they be detected in the proposed process?
  • Does the project improve the quality of information? What is the value of the improvement?
  • Does the project improve the timeliness of information? What is the value of improved timeliness?
  • Who benefits from the new system and who is harmed by it?
  • Who/what is changed by the new system?

While it can be difficult to assign monetary values to these effects, crude back-of-the-envelope calculations can help confirm or question a project's value. If the business case doesn't add up, some diplomatic questions are in order for the project's sponsors.

In complex situations, it is difficult to anticipate the costs and consequences of changes or new ways of doing business. For our projects to be valuable to our organizations, we must do our best to imagine the effects our projects can have on users, the organization, our business partners, and the customers. Figuring out the costs of a business case provides one way of describing these effects. Let's work together to minimize the hidden costs of unintended consequences by ensuring that they are explicitly identified and considered before solving the problem. Perhaps, then, this lesson need not be learned again and again.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.