I was the planning consultant to Apple Computer's Latin America group from 1982 until 1991 or 1992, the end of the relationship being a bit hard to define as I was called on steadily more by Apple Japan and less by Apple Latin America.
The challenge came in the spring of 1985. The annual business plan was done every Spring, turned into management in June and then discussed and revised and resubmitted and eventually accepted in July. In April of 1985 I had been the consultant for that process for four years running when Hector Saldana, manager of the group, said:
"Tim, yes I want you to do our annual plan for us again this year. But only on two conditions: first, I want you to stop working for other computer companies. Second, I want you to take up a desk in our office, come every day, and sit here and see us implement the plan."
Happily, he also had some good news related to giving up other competing companies as clients: "And, if you agree to do this, I want to contract you for all of your hours for the next year, and at your regular billing rate."
The condition of giving up competing clients was difficult for a single person business. What if Apple had problems, or changed its policy regarding consultants? What if Hector got promoted or fired? Where would I be then, if I had given up other business relationships.
That's not the real point of the story, although it does relate to planning as you go. That certainly wasn't part of my business plan for my business, but it was a classic example of changed assumptions. We talked about it at home at length, and decided to go ahead with it. However, we also modified the plan we had going related to efforts to generate new leads and new business: we would focus that effort within Apple itself, different groups that didn't talk much to each other, to reduce risk of having two many eggs in the single Apple Latin America basket. The plan was modified for cause, to accommodate changed assumptions.
The problem of implementation, however, forced me to consider the difference between the plan and the results of the plan.
There was some history. The previous year or two had been the time of "desktop publishing" for Apple Computer. Desktop publishing, which we now take for granted, started with the first Macintosh laser printer in 1985. It was a huge advantage for Apple in competition against other personal computer systems.
Our plan for fiscal 1985 had been to emphasize desktop publishing in most of our marketing efforts. And it didn't happen. While we talked about desktop publishing in every meeting, the managers would go back to their desks, take phone calls, put out fires, and forget about it. They didn't intend to, but they'd had so much emphasis on desktop publishing that it seemed boring, old hat. Multimedia was the thing.
So, faced with the implementation challenge, I created what became the strategy pyramid to manage strategic alignment. We ended up with a relatively simple database of business activities. Collaterals (meaning brochures and such), bundle deals (software included with the hardware at special bundled prices),advertising, trade shows, meetings and events, all were tied into a system that identified what strategy point they impacted, and what tactic.
So during that year, as business went on, we were able to view actual activities, spending and effort, divided by priority. We set more budget money for desktop publishing activities than any other. During the review meetings, we compared actual spending and activities (the beginning of what I talk about as metrics) to planned spending and activities. And over time, with pie charts and bar charts to help, we were able to build strategic alignment. What was done was what the strategy dictated.
The plan-as-you-go implication was that this didn't happen just because it was in the plan. It took management. There was a plan review schedule with the meetings on the calendar way in advance, and for every meeting I was able to produce data on progress towards planned goals. The managers discussed results. Plan vs. actual metrics became important.
When things didn't go according to plan, the meetings would bring that to the surface. Managers would explain how the assumptions turned out wrong, or some unforeseen event -- we had good results as well as bad results -- and we would on occasion revise the plan.
It's not for nothing that I always say a business plan has to be your plan and nobody else's. It can't be your consultant's plan. You must know it backward and forward and inside out, or it won't work.
I learned this the hard way, sitting in venture capital offices at 300 Sand Hill Drive, Menlo Park, California , the business plan consultant on the tail end of the new venture team. I had done the plan, built the financial model, written the text, shepherded the document through the painful coil binding and the whole thing, but I wasn't part of the team. I didn't want to be. I was still at grad school, getting my MBA, and my part of this venture was writing the plan, period. I needed the money to pay tuition.
In meeting after meeting, at key moments, the venture capitalists would ask critical questions and all heads would turn to me. I would answer. I knew the plan, backward, forward, and inside out, but I was the only one who did. It was my plan.
It was a good founders team. It included three Silicon Valley veterans -- a marketing guy, a technical guy, and a deal maker. They had about 40 years of computer company experience between them. They had a good idea and, much more important, a market window, differentiation, and experience to make it happen.
The three of them never really got into the plan. It was a hurdle they paid me to jump for them. Every meeting generated new changes, so I would go back to the basement computer at the business school, and rerun the financial model. The team of three didn't include a financial person to learn and manage the model, so it was always me doing the tweaking, which meant I was the only one who knew the plan. I'd rerun my financial model, edit the text, and publish a new version of the plan. They read paragraphs here and there, glanced at the numbers, but they stayed with the strategy, and left the details to me.
Details that, in fact, they didn't look at. They trusted my faithful recording of their ideas and my financial modeling. They assumed, I guessed at the time, that these were functions that could always be delegated to somebody with special skills while they generated high-level strategy.
They did not get financed. I was disappointed. When you develop the plan and revise it dozens of times and support it and defend it through the long series of meetings with supposedly interested investors, you want it to take flight.
All these years later, memory of that disappointment is still fresh. I did learn my lesson, though, and I changed my strategy as a business plan consultant. From then on I made sure that any plan I worked on belonged -- and I'm talking about intellectual ownership here, conceptual ownership -- to the business owners, not the consultant.
If you have the luxury of a budget to pay an outside expert, consultant, or business plan writer, then maybe you should use one. This might be a good use of division of labor, and perhaps you can lever off somebody else's experience and expertise. However, that will not work for you unless you always remember that it has to be your plan, not the consultant's plan. Know everything in it, backward and forward, and inside out.
In chapter four of his book Blink, Malcolm Gladwell describes how Paul Van Riper, a retired Marine commander, drove the U.S. military to fits in a war exercise called "Millennium Challenge." It's a brilliant argument for the plan-as-you-go idea compared with the traditional plan method.
The Millennium Challenge was an exercise designed to test the military's ability to deal with a simulated war in the Middle East. It pitted a very large team (Blue Team) equipped with a very detailed battle plan, a lot of computer models and simulations, against a very small team (Red Team) led by Van Riper, experienced and self confident and good at making quick decisions.
"Blue Team had their databases and matrixes and methodologies for systematically understanding the intentions of the enemy. Red Team was commanded by a man who looked at a long-haired, unkempt, seat-of-the-pants commodities trader yelling and pushing and making a thousand instant decisions an hour and saw in him a soul mate."
As you've already guessed, Blue Team is the might of the military, and Red Team is essentially one smart guy who starts with a plan and revises it constantly as the battle ensues.
When the game was actually played, Van Riper surprised the Blue Team quickly with a move not in its plans, and as they reacted to that, he surprised them again, and quickly caused considerable unexpected damage to a much larger force. It was all simulated and hypothetical, but the result was that the quick-to-react team with flexible planning beat the pants off the very detailed plan team that couldn't react to changes.
"Had Millennium Challenge been a real war instead of just an exercise, 20,000 American servicemen and women would have been killed before their own army had even fired a shot."
That was pretty hard for the military to explain. They analyzed it a lot.
"There were numerous explanations from the analysts at JFCOM (Joint Forces Command Center) about exactly what happened that day in July. Some would say that it was an artifact of the particular way war games are run. Others would say that in real life, the ships would never have been as vulnerable as they were in the game. But none of the explanations change the fact that Blue Team suffered a catastrophic failure. The rogue commander did what rogue commanders do. He fought back, yet somehow this fact caught Blue Team by surprise."
Implicitly, the problem was the big team full of computers and data trusted a static plan, while the other team didn't.
Red Team's powers of rapid cognition were intact—and Blue Team's were not.
So relate that to the planning we want: planning that responds to rapidly changing reality. Not just "Duh, I can't plan, I don't know the future," and not just "Why plan? Why bother" and not "We have to follow the plan," but planning as you go.
You probably know this already, but I'll go over it just in case. I recommend using Business Plan Pro software so you don't have to do this, but it's good to know anyhow, and you can certainly do everything in this book without that software. So here's a bit about spreadsheets.
Spreadsheets are normally arranged in rows and columns, with rows numbered from 1 to whatever, and columns labeled from A to whatever. Simple mathematical formulas refer to the cells that are identified by row and column. For example:
So what we see here is a simple formula that adds the 34 in cell B2 to the 45 in cell C2 to get the sum of those two, which is 79. That number is in cell D2, so you see the formula showing at the top when you click on D2. Also the number in the upper left corner indicates which cell the displayed formula belongs to.
Here's another simple example:
In this case the cell named B5 is highlighted, and its formula says to sum up all the cells from B2 to B4. That's three cells, and the numbers they contain sum up to 128.
There are lots of books and websites and different instructions and tutorials available for spreadsheets. This is enough for now, so you can understand my simple forecast examples.
The most important problem is getting people who haven't been running companies to believe that cash flow and profits are different. That's so vitally important because, on the surface, it doesn't add up. It isn't believable.
I developed business planning software originally as templates for business-planning clients to deal with the following amazingly typical exchange:
Me: So if you grow faster, then you'll need to get more financing.
They: No, that can't be true, because we're profitable. We make money with each sale, so the more we sell, the more we can fund ourselves.
Me: Bingo! Please sit down here for a few minutes and deal with these numbers.
And so it would go. As soon as you're managing inventory or selling on credit -- which means just about any sale you make to a business -- then your cash flow is waiting in the wings, a silent killer, to foul you up.
I learned this first in business school and then forgot about it. I learned it later again, the hard way, when Palo Alto Software sales tripled in 1995 and that nearly killed the company. Why? How? Well, we experienced a huge sales increase by selling a software product through traditional channels of distribution, meaning stores, and that means selling to distributors who then resell to stores, and that means that it can take five months between selling the product and being paid for the product. In the meantime, you've got to make payroll and pay your vendors.
Yes, it's a good problem to have -- we all want to increase our sales and profits -- but it's a whole lot easier to deal with if you plan the cash implications well.
Often in presentations I use one of my favorite metaphors, the Willamette River as it runs through Eugene, Oregon, where I live. The river slows down coming out of the Cascade Mountains and into Eugene, and it looks deep, slow, and peaceful, but it's much more dangerous there than when it's throwing up white water through the rapids. Why? Because it seems so calm and welcoming. People disrespect its currents, get caught in weeds, branches, or rocks, and ... well that's a good metaphor for the way cash flow hits small businesses when things are good, when sales are growing.
What's particularly painful about the cash-flow problems that come with growth is that, precisely because there is growth, these problems can be prevented by planning.
You can see how the sales are growing, then determine what your cost of sales will be, and look at what you have to pay, to whom, and when. See how your checking account will balance go down and down. Next, chart out when your customers will pay you. It will be obvious if you will run out of money before those profits actually reach your hands. You can then plan how to find the financing to float your boat before you actually hit the snag and sink.
We've had growth spurts since then that were far less painful because we understood the dangers of cash flow, planned for the cash implications of growth, and worked with our bank ahead of time to make sure the working capital was there.
Adapted from an article originally published on blog.timberry.com. All rights reserved. Image: courtesy of University of Oregon Department of Journalism
