[6] Robust Project Planning(tm)

Accuracy relative to logistics is achieved best with reverse planning, which defines a necessity-based logistical network of activities and exchanges if inputs and outputs. Such necessity-based planning processes provide three outstandingly valuable benefits. First, they provide logistical networks that are complete. So long as all the players truly understand their jobs, as they all claim to do, all the intermediate inputs become captured by the planning process automatically. The resulting logistical networks, which are the backbones of project plans, capture all the significant work items. Further, they capture the work items in the correct sequence.

Second, since reverse planning processes are necessity based, no unnecessary intermediate inputs and no unnecessary activities find their way into the logistical network of the project. Thus, not only are the resulting project plans more complete. They are also devoid of unnecessary effort.

Finally, reverse planning processes automatically capture all the interactions among the members of a project team, and they exclude the countless micro-steps that are better managed directly by the team members and not by the project managers.

The Robust Project Planning is no exception. It is, in fact, an extremely simple and highly effective process with which a diligent project manager consistently can achieve accuracy relative to logistics. The process requires only that the project manager acquire the answers to five simple questions repeatedly, beginning with each of the tangible deliverables identified by the management team.

When using the Robust Project Planning process, it is useful to avoid the simultaneous use of software. While doing the difficult and important work of thinking, you and the members of your team need a view of the entire logistical network at once. You need the big picture view of the logic of your plan. This is simply not possible with a computer. A computer screen limits your view to a postage-stamp-sized segment of your plan, making it difficult for you and your team members to follow the logic of your network and, more importantly, making it difficult for you and your team members to spot the mistakes.

To really understand this unfortunate limitation created by computer screens, do the following exercise. Open any large map and plan an itinerary from one point on the map to five or six consecutive destinations. But, rather than allowing yourself to see the entire map in one eyeful, restrict your view of the map, by looking through the cardboard tube at the center of a roll of paper towels. You’ll understand very quickly the degree to which your team members will become frustrated by the highly limited view of the logistical network that a computer screen (or digital projector) provides for them.

A far more effective approach is to use Post-It notes while doing the hard work of thinking with your team members. With Post-It notes and large sheets of flipchart paper, you and your team can tackle a fairly large effort easily, all the while retaining the ability to see the big picture. At each step of the process, capture their answers to your five questions (see below) on white or yellow Post-It notes. Descriptions of required inputs (a final deliverable is an input to the customer) go on white Post-It notes. Task descriptions go on yellow Post-It notes.

By building the logistical network manually with Post-It notes, rather than moving directly to your software tool, you also avoid the annoyances, delays, and frustrations created by any idiosyncrasies of your software tool. These often impede the thinking process of your team. Certainly, the final version of your logistical network will end up in software. But the data entry should be nothing more than the final step, prior to the project becoming active.

Finally, prepare your conference room for the planning session. The walls of the room should be bare, rather than being cluttered with plaques or artwork. You’ll need them bare, so that your sheets of flipchart paper can be displayed and moved easily. Arrange for refreshments and snacks to be available throughout the planning process, so that team members find contributing to the planning process a pleasant and rewarding experience. And be absolutely certain that the first form of accuracy, accuracy relative to deliverables, has been achieved.

Once your preparations are complete.... [to be continued soon]

[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.

[4] Four Forms of Accuracy

In the book titled The New Economics, W. Edwards Deming states unequivocally, “Management is prediction.” Deming is on target. Executives and managers make predictions regularly, to shareholders, to customers, to banks, and even to the IRS. Some of these predictions involve the use of financial models (albeit many such financial models in use at this writing are highly questionable). The predictions required of executives are based in large part on the models of their projects, hence the need for unbiased, predictive models of projects.

Our need for predictive project models requires that our project models exhibit four forms of accuracy. These are:

1) Accuracy relative to deliverables.
2) Accuracy relative to logistics.
3) Accuracy relative to duration.
4) Accuracy relative to budget.

The four degrees of accuracy are hierarchical. Accuracy relative to deliverables is required before accuracy relative to logistics can be achieved. Accuracy relative to logistics lets us identify the required activities and the interactions among the various resources. It is necessary for accuracy relative to duration. The latter, in turn, is needed for accuracy relative to budget.

Therefore, the overall accuracy of a project’s model begins with the 1st form of accuracy, accuracy relative to deliverables. The tangible deliverables expected of a project must be defined clearly and completely, before the model of the project can be created.

Accuracy relative to deliverables is the responsibility of the customers of a project. The customers of any project include the customers of the enterprise and the leadership of the business, which represents the shareholders. As project managers, you bear a fiduciary responsibility. You are responsible for the overall accuracy of the model that you create, on behalf of the leadership team of your enterprise. Consequently, you must resist pressures to begin constructing a model of any project that lacks an agreed-upon list of tangible deliverables. In keeping with the iterative approach to product development, you cannot expect the list of tangible deliverables to be all-encompassing. But you must insist that expectations be well understood and well-defined for the limited project that you are about to undertake. In fact, you have a right to require that expectations be well-defined for any project that you are asked to undertake. This is accuracy relative to deliverables.

Accuracy relative to deliverables does not appear to be a difficult thing to achieve at this time. It is missing in many cases only because no attempt is made to achieve it. Once individuals are aware of the need to achieve accuracy relative to deliverables, they are usually quite capable of doing so. Therefore, I do not address accuracy relative to deliverables further.

Next on the hierarchy of accuracy there is accuracy relative to logistics. Accuracy relative to logistics is a product of the specific planning process that you use. Unfortunately, we do not study project planning in college. Consequently, very few people today possess an effective project planning process. The resulting project models lack accuracy relative to logistics to a substantial degree.

Today, most people who contribute to the construction of project models use a forward-going, workflow description approach to logistical planning. This is most unfortunate, for two reasons. First, the resulting logistical plan ends up with far too much detail, which severely limits the usefulness of the project’s model. Second, much of the work that is required for the successful completion of the project at hand is never included in the logistical plan. This happens because the conventional approach to logistical planning is not necessity based.

The alternative to this ineffective form of logistical planning is the Robust Project Planning Process, discussed in a subsequent chapter. Robust Project Planning yields logistical plans that are consistently complete and simultaneously devoid of unnecessary activities. Please study the corresponding segment of this book carefully, and practice the Robust Project Planning Process at every opportunity. If you use it consistently, it will serve you well for a lifetime.

After we achieve accuracy relative to logistics, we face the task of achieving accuracy relative to duration, with our project models. Here, virtually every project manager fails today, for the following reasons:

1) Due to damaging management practices, individual developers are justifiably unwilling to provide estimates of the process time of their tasks.

2) Due to widespread multitasking, individual developers today are entirely incapable of estimating the process time of their tasks.

3) Due to their lack of understanding of variation, project managers today are entirely incapable of taking into account the many effects of variation, on project duration.

4) Due to their completely lack of understanding of variation, executives and managers today strive to use project models not as predictive tools but as prescriptive tools, in a misguided effort to improve the performance of their teams.

Any one of these factors is enough to prevent you from building project models that exhibit accuracy relative to duration. It is very likely that in the future you will face all these factors, as do today’s project managers, for whom accuracy relative to duration is an unimaginable nirvana.

Although in this book I discuss the Robust Project Planning process, I focus purposely on achieving accuracy relative to duration, by addressing variation at every step of the modeling process. In my opinion, this is where the understanding of project managers falls short today, as does that of resource managers and executives.

Finally, we have accuracy relative to the budget. This is at the top of the hierarchy of accuracies. It relies upon all the other forms of accuracy. Thus, it is compromised to the greatest degree.

Accuracy relative to the budget is compromised further by the widespread misapplication of the Earned Value Measurement System, particularly among defense contractors. The section on accuracy relative to the budget addresses the Earned Value Measurement System, highlighting the changes that are needed to make the Earned Value Measurement System useful rather than counterproductive.

[3] To Plan Or To Iterate

Today there is a growing realization that effective product development requires an iterative process. This realization is greatest in the area of software development, where feedback from the users of software products is relatively quick and decisive. Developers of software have learned that they cannot know at the beginning of a large development effort all the use-cases and all the preferences of their target customers. At the time that a large development effort is started, information about the needs of the target customers is incomplete. Hence, there is now a movement away from defining complete sets of specifications and, consequently, from designing models of entire development efforts.

However, this in no way means that we can do without project plans and project models. Quite the contrary is true. Our need to coordinate the efforts of many contributors toward a common goal persists. Creating a product that meets the needs and expectations of customers is still a requirement; it will remain a requirement forevermore. The need to develop products rapidly persists as well. Speed is every bit as important as effectiveness, in product development. Thus, the job of project managers remains unchanged: to aid the many contributors, so that they might work together in the most effective manner possible and create the right products rapidly and cost-effectively.

The conflict between those who would use an iterative approach and those who would define specifications and develop appropriately detailed models of projects is really no conflict at all. Both sides of this conflict are correct. An iterative process is needed. But we also need project plans and well-designed project models. We simply must recognize that we cannot plan an entire, large development effort to the same level of detail. Instead, we design a strategy for the overall development effort, and we construct plans and detailed models only for the few steps immediately before us. Therefore, little has changed really, other than the scope of our project plans and the corresponding models. Instead of trying to define the mother of all project plans, we define many smaller project plans, in rapid succession. We then use these to model our systems of resources and their work, so that the leadership of an enterprise might make its predictions with an appropriate degree of accuracy and, more importantly, so that the entire flow of projects can proceed expediently.