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