[5] Resistance to Planning

There are several reasons why today project plans leave so much room for improvement. Not the least of these is a certain degree of resistance, on the part of developers, to contribute to project plans.

“We don’t plan R&D.” These were the words spoken to me by an otherwise intelligent and highly educated individual, a man with a Ph.D. in physics, of all things. This misconception is a major source of inadequate project plans, because it prevents so many developers from even trying to create a project plan. You can expect to encounter this sort of resistance among the more highly educated contributors, who normally tackle the most intellectually challenging work of your projects. The difficulty of the technical challenges that these people face regularly, particularly with problems that require inventive solutions, causes them to conclude that planning projects is nothing more than a fruitless waste of time. They could not be more wrong on this particular issue.

They are wrong for two reasons. First, today it is quite possible to schedule invention. All that’s required is expertise in TRIZ, the Theory for the Resolution of Inventive Problems. A detailed discussion of TRIZ is beyond the scope of this small book. But I encourage you strongly to educate yourselves about this subject. Read first "And Suddenly the Inventor Appeared" by Genrich Altshuller.

Second, our inability to predict the future in no way justifies the conclusion that all planning is a waste of time. Indeed, we cannot know the future. For example, we may expect to proceed in a specific direction, with the design of a product. But, depending on the outcome of initial evaluations of competing technologies, the direction of our development effort may change, and we cannot know at the start of a project how the evaluations will turn out.

Does this mean that we should do no planning at all? Of course not! Planning a project is not unlike planning a long road trip. Initially we may decide to take a specific interstate highway, to reach our destination. But road construction and random accidents can easily cause us to make unanticipated changes. We are still far better off if we start our trip with a plan than if we start our trip with no plan at all, because the lack of any plan brings with it numerous additional problems that we might otherwise anticipate and avoid.

The same is true of projects. We cannot know the outcome of initial evaluations of key technologies, which often occur some months after the start of a project, and we may have to do some re-planning, once we gain important new knowledge. But, by planning the project to the best of our ability before we start it, we can avoid numerous additional problems that otherwise would surely create unnecessary delays and greater variation in both duration and budget.

“I know my job. I don’ t need to plan my work.” You’ll hear this one too, from many quarters. Again, this sort of thinking is shortsighted and simply wrong. We don’t create project plans so that we can micromanage the work of individual contributors (although those individuals often would benefit from scrutinizing their own work processes). The people whom we select as members of our project teams are already experts at their jobs, and we don’t need to manage the details of their work. But we do need to understand the interactions among the members of the project team. We do need to identify, monitor, and manage all the significant exchanges of inputs and outputs among the developers who contribute to our projects. This is the real purpose of a project plan. Therefore, all those who expect to contribute to the successful completion of a project must also contribute to the successful creation of that project’s plan. Their refusal to help build the plan is nothing less than the deliberate sabotage of the company’s speed to market.

“I’m not sure that we can afford to spend a week per project, just to create project plans.” Difficult to believe though it may be, these were the words spoken to me by the director of a product development organization. This sort of thinking, particularly among executives, is nothing short of complete stupidity. The value of effective project plans is stated most clearly by the next figure. Study it carefully.

At the core of all these forms of resistance there is the complete lack of a planning process. Most people, even those who contribute to the plans of new projects willingly, don’t know how to create a useful project plan. This is not surprising. After all, none of us was ever offered an elective on project planning, in college. Nor were we offered such training by our employers. As a result, most of the people who contribute to your project plans do so simply by describing their activities, using a forward-going workflow description approach. As you read the next chapter, contrast the results of this simplistic approach with the results of the Robust Project Planning(tm) process.