This chapter is from the book
This chapter is from the book
This chapter is from the book
Analysis Paralysis
Preventing the Disease Behind the Symptoms
Many predators hunt based on movement. In fact, even with their keen eyesight, they cannot really see their prey unless the prey itself moves. Consequently, many hunted animals are programmed literally to freeze with fear. Not a bad thing to do if it saves your life!
Recently, we were asked to perform a postmortem review of a large project that had failed miserably at a major corporation. I will spare you all the unpleasant details—let's just say they started the coding phase way too early. The wounds to the business were deep, and in several ways, the company had begun to ooze red ink, its very lifeblood.
What went wrong? The diagnosis was relatively easy for us to make—no Policy Charter or other means to assess business motivation, and no true top-down business model.
They should have frozen with fear then and there. Instead, they jumped right on into development, loosely following a spiral "methodology" based on the mantra analyze a little, design a little, code a little, test a little. The company learned the hard way what that mantra means in practice—lots of rework for lots of time! (By the way, on other projects the company called such rework "maintenance." Sound familiar?)
Projects spiral out of control all too often. Unfortunately, there are no magic cures—just very expensive and time-consuming ones. Can the company really afford to squander its resources in this way? We think an ounce of prevention is worth a pound of cure.
Take a hard, early look at projects and learn to read the symptoms before it is too late to prevent the disease. Here are some possibilities.
Maybe you do not really know what the business problem is. In that case, how will you know if you are developing the right solution?
Maybe the business problem itself is hard. Will thinking about it in a programming language (or in IT system models) make understanding it easier?
Maybe you are not getting the right answers from the right people. Then, realistically, how good are your chances of success?
Maybe there are unresolved differences of opinion on the business side about what form the business solution should take. If left to the programmers, do you think they can code their way to some satisfactory resolution?
Maybe future business directions are hard to predict. Are designers and programmers in a position to make the best strategic choices?
The next time you hear anyone say, "Watch out for analysis paralysis," take pause. Just freeze—it might save your company's life (or your own job). Somewhere close by there is probably a programmer poised to pounce on a keyboard. To stay on the safe path, think business model, Policy Charter, and business rules. Remember, every problem is first and foremost a business problem!
References
Appleton, Daniel S. 1984. "Business Rules: The Missing Link." Datamation, October 15, pp. 145–150.
Burlton, Roger T. 2001. Business Process Management: Profiting from Success. Indianapolis, IN: Sams Publishing.
Business Rules Group (Ronald G. Ross and Keri Anderson Healy, eds.). 2000. "Organizing Business Strategy: The Standard Model for Business Rule Motivation." Version 1, November 2000. Available at http://www.BusinessRulesGroup.org.
Chisholm, Malcolm. 2001. Managing Reference Data in Enterprise Databases. San Francisco, CA: Morgan Kaufmann.
GUIDE Business Rules Project Report. 1995. Third edition available in November 2002 as "Defining Business Rules—What Are They Really?", edited by David C. Hay and Keri Anderson Healy, Business Rules Group, July 2000, at http://www.BusinessRulesGroup.org.
Lam, Gladys S. W. 1998. "Business Knowledge—Packaged in a Policy Charter." DataToKnowledge Newsletter (formerly Data Base Newsletter), May/June. Available at http://www.BRCommunity.com.
Morgan, Tony. 2002. Business Rules and Information Systems. Boston, MA: Addison-Wesley.
Ross, Ronald G. 1997. The Business Rule Book (2nd ed.). Houston, TX: Business Rule Solutions, LLC. Available http://www.BRSolutions.com.
———. 1994. The Business Rule Book (1st ed.). Boston, MA: Database Research Group.
———. 1987. Entity Modeling: Techniques and Application. Boston, MA: Database Research Group.
Ross, Ronald G., and Gladys S. W. Lam. 2000a. The BRS Core Business Rule Practitioner's Guide: Using Business Rules in Developing Business Strategy. Houston, TX: Business Rule Solutions, LLC. Available http://www.BRSolutions.com.
———. 2000b. Capturing Business Rules. Workbook for public seminar, presented in Boston, MA, June 19–21.
von Halle, Barbara. 2002. Business Rules Applied: Building Better Systems Using the Business Rule Approach. New York: Wiley Computer Publishing.
Zachman, John A. 2002. The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing (electronic book). Available at http://www.zachmaninternational.com.