Rich irony: 37Signals, a great Web app for project management, ought to know better than anybody that real business planning is a process, not a plan. After all, they do the kind of nuts and bolts management that makes that happen. Instead, however, Matt of 37Signals posted the planning fallacy last week:
If you believe 100% in some big upfront advance plan, you're just lying to yourself.
I object. Who ever said planning was "believing 100% in some big upfront plan?" Good business planning is always a process involving metrics, following up, setting steps, reviewing results, and course correction.
He goes on:
But it's not just huge organizations and the government that mess up planning. Everyone does. It's the planning fallacy. We think we can plan, but we can't. Studies show it doesn't matter whether you ask people for their realistic best guess or a hoped-for best case scenario. Either way, they give you the best case scenario.
OK that's a dream, not a plan. Matt seems to confuse the two, but good business planners don't. Any decent business planning process considers the worst case, risks, and contingencies; and then tracks results and follows up to make course corrections.
Which leads to this, another quote:
It's true on a big scale and it's true on a small scale too. We just aren't good at being realistic. We envision everything going exactly as planned. We never factor in unexpected illnesses, hard drive failures, or other Murphy's Law-type stuff.
No, but you do allow extra time for the unexpected, and then you follow up, carefully (maybe even using 37 Signals' software) to check for plan vs. actual results, changes in schedule, new assumptions, and the constant course correction. Murphy was a planner. He understood planning process, plan review, course corrections.
That messy planning stage that delays things and prevents you from getting real is, in large part, a waste of time. So skip it. If you really want to know how much time/resources a project will take, start doing it.
Really bad advice there, based on a bad premise. Sure, if you define planning as messy and preventing you from getting real, then it would be a waste of time. But is that planning?
I wonder if Matt takes his own advice. When he travels, does he book flights and hotels? Or does he skip that, and just start walking.
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.
I noticed this very plan-as-you-go post by Guy Kawasaki on his blog. What I like about it, particularly, is where Guy says "set goals" and then lists these four desirable qualities of goals:
Measurable. If a goal isn't measurable, its unlikely you'll achieve it. For a startup, quantifiable goals are things like shipping deadlines, downloads, and sales volume. The old line "What gets measured gets done" is true. This also has ramifications for the number of goals, because you can't (and shouldn't) measure everything. Three to five goals measured on a weekly basis are plenty.
Achievable. Take your conservative forecasts for these goals and multiply them by 10 percent; then use that as your goal. For example, if you think you'll easily sell a million units in the first year, set your goal at 100,000 units. There is nothing more demoralizing than setting a conservative goal and falling short; instead take 10 percent of your forecast, make this your goal, and blow it away. You might think that such a practice will lead to underachieving organizations, because they aren't being challenged. Yeah, well, check back with me after you don't sell a million widgets.
Relevant. A good goal is relevant. If you're a software company, it's the number of downloads of your demo version. It's not your ranking in Alexa, so telling the company to focus on getting into the top 50,000 sites in the world in terms of traffic is not nearly as relevant as 10,000 downloads per month.
Rathole resistant. A goal can be measurable, achievable, and relevant and still send you down a rathole. Let's say you've created a content website. Your measurable, achievable, and relevant goal is to sign up 100,000 registered users in the first ninety days. So far, so good. But what if you focus on this body count without regard to the stickiness of the site? So now you've gotten 100,000 people to register, but they visit once and never return. That's a rathole. Ensure that your goal encompasses all the factors that will make your organization viable.
What I like about this, as you might guess, is that it's a very close match to what I'm saying here, in this site, and in the Plan-As You-Go Business Plan book itself. Goals are about business, getting things done, and they do you no good unless you follow up on results and manage accordingly.
(Note: reposted here with permission from Entrepreneur.com, where it first appeared, as one of my columns in the Business Plan coaching area. Since it's so closely related to the plan-as-you-go approach, I'm reposting it here. Tim.)
Plans are wrong, but nonetheless vital. There's a paradox for you. It's a simple statement, one that I hope is somewhat surprising coming from a business planning expert; but it's still very important. And it gets right to the heart of what business planning is all about.
More than ever, those who plan look to projections that often miss the mark. Nobody I know, and in fact nobody I've even heard about, accurately predicted the sharp plunge in the economy last fall. So of course those who actually use a business planning process are implementing a lot of course corrections, reviews and revisions.
It's a great example of how this paradoxical statement -- plans are wrong, but nonetheless vital -- makes sense. As we look at the year to come, most of us are dialing down our forecasts. Does that mean we wasted our time making them? Not at all. How do we even make sense of where we are if we don't have a map that shows us how we got there?
If you had a plan earlier this year and results differed greatly from what was expected, I hope you're taking the time to compare those results, in detail, to the earlier plan. Look for where the differences were greatest. Look for where expenses were tied to sales. Look for the bright spots where sales held up. Look for how the numbers were supposed to come together, and not just how they didn't.
And if you didn't have a plan, then think of this as a good time to get a planning process started so you have a better view of your business in the future. Start making simple sales and expense projections. Don't worry that they're wrong; just make sure you go back each month and plot where and how and in which direction they were wrong so you can correct them.
You should only be wrong a month at a time, and as you use that plan-vs.-results analysis to look more closely at how things are going, you adjust again and improve results for the next time around. With each month, your grasp on reality gets better.
And then, as things go back up -- and they will -- you'll be able to use what you learned to see the signs, anticipate and act accordingly.
This kind of planning process is what's meant by the phrase, "The plan may be wrong, but planning is essential." Then there's another old military saying: "No battle plan ever survived the first encounter with the enemy." What does happen, though, with battle plans as well as business plans, is you don't know how to recover or how to adjust the plan if you didn't have a plan in the first place.
The book is Slide:ology, and this five-minute video is a great summary.
And you might also enjoy this summary from CBS news, another short video.
These things go up and down, but I'm proud to share that -- at least as I write this -- The Plan-As-You-Go Business Plan is the number one ranking for business plan books at Amazon.com.
I've just finished a 12-minute online video (presentation, slides, with me talking) summary of Chapter 2, Attitude Adjustment. Click here for that ... it does require Flash Player and Java on your system, and the window has to be about 860 pixels wide to show the whole thing.
[kml_flashembed movie="http://timsstuff.s3.amazonaws.com/Media/whypaygblogsize.swf" height="357" width="475" /]