Understanding the Planning Process, Page 2
2.1 The Pathology of Poor Planning
In the human body, certain materials called allergens stimulate allergic responses. The immune system responds by creating antibodies to combat the allergens. As a side effect, the victim can suffer histamine responses like itchiness and a runny nose, or even more severe life-threatening allergic reactions. In a similar fashion, relatively minor problems identified in a software project often stimulate the production of management countermeasures. Too often, these responses cause even worse, and sometimes fatal, reactions in the project.
The allergens in software projects are almost always buggy code and missed deadlines. In effect, they have lower than acceptable quality and productivity. These symptoms may in turn have been caused or aggravated by poor planning. They stimulate typical responses including more elaborate planning and a tightening of restrictions on the developer's ability to improvise. When this becomes a cyclical pattern, projects suffer. Either they become too congested to even breathe, or at the very least they suffer diminished ability to perform at peak capacity.
In the human body, the different systems interact intimately. Similarly, planning, development, management, and the client together form the systems of a software project. These systems interact so intimately that any cure must be holistic in nature, considering the response of all systems to stresses or remedies. Each of these areas has a very different perspective on the typical recurring problems we face in software projects.
From its perspective, management may sometimes recognize that the marketing department overcommitted deliverables. More often, it simply sees that the developers failed to deliver a satisfactory product. Its dissatisfaction may be based upon profitability, budget, timing, functionality, maintainability, usability, or any number of metrics. When this happens, management has limited courses of action available. It can replace or retrain developers if it suspects that the developers lack competence. It can insist upon more planning if it assesses that the planning was lacking. And it can tighten up management controls to ensure that developers follow the plan more closely. Most often, management applies a combination of these remedies in shotgun fashion, hoping to eliminate any problems next time around.
Figure 2-13 Industry insiders are usually the last to recognize and correct their systemic problems.
From the planners' perspective, we see a slight variation. When projects run into trouble, planners also see a fairly limited number of causes. Planners often feel that marketing doomed planning efforts right from the start by prematurely promising features, approaches, and budget. They feel that the planning process was rushed, inadequately budgeted, and impatiently supported by management. Planners feel that the development group did not fully utilize their planning documentation and that management allowed them to deviate too far from the planned specification. The project planner's remedy for these problems almost always involves more planning next time with greater management control over development.
Developers feel they were handed unrealistic deadlines, constraints, and requirements. They feel they were given a poor project plan that did not meet their needs. They feel neglected and ignored by management when they ask for support to augment or adjust the plan, and then they feel hammered upon when deadlines are missed. Often they feel that management undermined development efforts by understaffing or moving critical staff in midproject. Developers typically want software planning, but they want better, not necessarily more, software planning. They want management, but they seek more responsive and supportive management, not more restrictive, counterproductive management.
From the clients' viewpoint, they just want the software done well, and of course completed as quickly and inexpensively as possible. Poor planning is the first thing they blame if there are problems in the project. They usually feel that the planners did not understand their needs thoroughly enough and did not document adequately. They often complain that although they got what they specified, they did not get what was needed.
Sounds kind of like the interaction between parents and their kids, doesn't it? The parents just want their kids to get an "A" in school. The kids may want that also, but when the kids get only a "C," the parents blame themselves for not taking a more active role. They grimly tighten up and create more restrictions for their kids and impose penalties if the kids deviate. They try to gather more measurable data by requesting more frequent grade reports from the teacher. When increased parental management conflicts with other demands upon them, the kids divert energy into working around those constraints and end up getting a "D" next time. Both sides have taken what they consider to be reasonable action at each step, but the interaction still degenerates into an increasingly counterproductive and hostile relationship.
This same sort of situation occurs over and over again in software development. As a consultant, I was sometimes called upon to save failed projects. Management invariably insisted that the reasons for failure lie within planning and development. If they blame themselves, it is because they didn't manage enough. They vow to be more diligent and proactive about increased project management next time.
The developers want both more and less management at the same time. What they really mean, even if they haven't realized it, is that they want more supportive management.
When you talk to the planners, they lament that they didn't have time to do more software planning and puzzle over why the developers have such problems after all the "good planning" they did do.
When I came into these situations, it was usually only after management had already tried replacing developers several times and had tightened up management practices drastically. It still wasn't working, and probably had gotten worse. In some of these cases, management had become so desperate that it was willing to give me a free hand. In those situations, I was able to succeed dramatically.
In other cases, management insisted that I fix the project while adhering to all of the management controls and requirements it had put in place. I declined those projects. I knew there was no way I could succeed where other fine developers had failed if I was locked into the same underlying causes of failure.
Page 2 of 8