Page 59 - The McKinsey Mind

02 (031-048B) chapter 2 1/29/02 4:49 PM Page 37

Designing the Analysis 37

ally correct.” We had a saying, “There is never enough data
or enough time,” which I always interpreted as, “Take
action earlier rather than later.” With a small business—$90
million in revenue—I can’t let myself or my staff violate these
lessons. Over and over, I find myself stopping people from
building the “unifying theory” of the business.

As we discussed in the previous section, analytically minded
people face a great temptation to do analyses that are interesting,
rather than relevant. In designing your analysis plan, it is your
responsibility to curtail this tendency in your team and, most espe-
cially, in yourself.
As your next step, you should figure out which analyses are
quick wins—easy to complete and likely to make a major contri-
bution to proving or refuting the initial hypothesis. In other words,
as we say in Chapter 7, pluck the low-hanging fruit. As an exam-
ple of how to think about this, Chacko Sonny of Savage Enter-
tainment describes how his team attacks debugging, a crucial step
in the development of any software product:

Quality assurance for software in the early stages of testing
is definitely centered on this principle. While we have to be
exhaustive when searching for bugs in our software, and we
can’t afford to have 20 percent of the bugs slip through into
a released product, the 80/20 rule* does apply when search-
ing for the cause of a bug. In many cases, the same error in
the code will cause a number of different symptoms. Rather
than tracking down every single incarnation of the error, we
will uncover 80 percent of the effects of a major bug. This
will offer clues as to the cause of the errors. We can address
a large problem in the code without having enumerated

*We will discuss the 80/20 rule at length in Chapter 4.