This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5 The Project Plan
The automobile thought experiment is applicable in several ways to software development. In the thought experiment, the goal is to have the car arrive on a target; in software development, the goal is to have your team deliver a solution to the development problem. The initial conditions in the auto experiment are the setting of the steering wheel and the amount of gas in the tank; in the development problem, the initial conditions are the staff on board and their understanding of the requirements.
Note that a classic project plan pictured in project management books and supported by project planning tools is a linear object. It breaks the work into small pieces and adds them together to determine the effort and schedule. It does not account for the nonlinear nature of the interactions among the team members. As linear objects, these project plans are only approximations of what will take place. The plans then are useful only if they are not taken too seriously. As with many linear objects, a project plan can serve as a useful approximation.
Project plans are also predictions of the future. They contain information on what each of the staff members will be doing when solving the problem. Insights from chaos theory tell us that the information contained in a real-life project plan is unknowable. Insisting that a team hold to a frozen plan ignores the fundamental nonlinearity of the process. In fact, you can be sure that the initial plan is almost certainly not accurate. This does not mean you should not have a plan, but only that you must refine and update the plan continually throughout the development.
This process of refinement and updating enables the plan to serve as a steering mechanism. This requires the plan's details to be filled in as the project evolves. The team's experience in a given phase serves as input to the details of the plan for the next phase. This iterative development of the project plan is one of the features of the Rational Unified Process, introduced in Chapter 5.
3.5.1 Less Is More
Some managers and staff process engineers do not understand the nonlinear nature of their projects. They believe that the reason project plans aren't followed is that they are not sufficiently detailed. They believe that adding granularity to a project plan creates order. (Adding granularity means adding tasks of a shorter duration.) For example, the manager may respond to an identified shortcoming in a previous project by adding more work items. Of course, more detail only makes things worse. Adding details takes the leap of faith that one can predict the future with great fidelity.
I have seen six-month projects with 1,800 work items. Based on 180 working hours in a month, each item, on average, would be less than two hours in duration. Anyone trying to administer such a plan would spend considerable time just updating status. Each developer from hour to hour would have to report which of the work items was being addressed. Fortunately, most organizations wisely ignore managers or process groups that try to impose such plans. The downside is that the projects are left with no plan at all. Ironically, the attempt to impose order results in chaos.