February 26, 2021
Hot Topics:

Understanding the Planning Process

  • By Prentice Hall
  • Send Email »
  • More Articles »

Accordingly, for the software planning techniques in this book to succeed, management may need to "loosen up." That does not necessarily mean managing less, but managing differently, managing smarter. This book is called Planning Smarter, not "Managing Smarter," so it is not specifically about project management. However, smarter planning cannot succeed without smarter management, so it will touch on some management issues and practices.

"Poor management can increase software costs more rapidly than any other factor." (Robertson, 1999)4

Planning smarter can indirectly encourage smarter management. When managers and planners cooperate well, successes are transmitted and reinforced throughout the system.

Is the developer the blameless victim in all this? Certainly not! There are times when developers fail to deliver. Yes, there are hack programmers out there. Between teaching, hiring, and consulting, I have seen some amazingly bad ones. The bad practices that programmers can adopt are truly astounding. However, better planning and tighter project management generally do not even begin to fix coding problems. The only things that can mitigate these problems are training and talented, experienced developers with good programming standards and coding reviews. These are the types of problems and solutions that my first book addressed (Gill, 2000).

Quite often, however, the developers are not the problem, or at least not the only problem. No developer, however talented and conscientious, can develop a project efficiently from a bad plan. The rule of "garbage in, garbage out" is universal. Sometimes, through heroic efforts, developers manage to succeed despite working from a nearly useless project plan. However, in many cases a bad plan all but guarantees development problems. A mediocre programmer may be able to succeed if given a good plan, but he has no chance at all working from a bad plan.

"Attracting the best people is vital, but it is also essential to support them with an effectively managed software process." (Humphrey, 1989)5

Certainly, a bad programmer could mess up the best-laid plan, but it is not common to have a great plan and a poor developer. More frequently, you have the worst case of bad planning followed by bad implementation. In this case, the planners usually don't see the true nature of their complicity. Since the programmer obviously failed to achieve his or her goals, management fails to appreciate that the plan might have made success quite difficult. Managers conclude instead that they simply failed to exert enough control over the developers. They resolve to spend more time and money next time to maintain greater oversight and constraints upon the developers, limiting the ability of good developers to succeed despite the bad plan.

"A lot of software projects fail, but we software developers are not such dummies that our sheer incompetence can account for them all." (DeMarco, 1998)6

It is worth emphasizing again that the one thing that management, planning, and development all normally agree on is that more planning is better. More planning is the solution to all problems. It is the panacea of the software industry. When projects run into trouble, management almost invariably concludes that more planning is needed and tighter controls must be put in place to adhere to it. Managers reason that if they had invested more in planning, the good developers could be more efficient and the less experienced developers would encounter fewer problems.

The flaw in this is that it assumes that planning is always good. This mistaken assumption leads to the erroneous conclusion that more planning must be better. The reality is that planning is often quite bad. It can be as appallingly bad as the worst coding samples. When you try to fix the problems caused by bad planning with even more bad planning, the problems compound.

When a project has been poorly planned, it is usually no secret. Everyone, at least all the developers, knows it very early in the project and becomes quickly resigned to yet another Death March even before the ink has dried on the functional specification.

"A Death March is a project that is doomed from the start. Everyone knows it and yet everyone just resigns to march along dutifully to certain doom." (Yourdon, 1999)7

It can quickly reach the point at which no planning may be better than all that bad planning. No matter how skilled the developers may be, the quality of the plan they receive is critical to their success. Typical software planning often fails to provide the developers with what they need to meet expectations. That may seem like a harsh assessment. After all, the industry has almost universally agreed upon the merits of current planning tools and techniques. However, it is also commonly accepted that the majority of software projects fail to meet their goals.

To explain this contradiction, most software professionals would conclude that their peers simply fail to apply well-known and proven planning principles. I am not willing to accept that explanation. My follow-up question is, why do they fail to apply them?

Walk into any software shop and you hear almost everyone there talk about project planning. Everyone appreciates the importance of doing it effectively. Many attempt to apply standard planning methodologies to their projects. They usually fail.

Some talk about it incessantly and never do it. Some read all the literature and continually bemoan the fact that their shop doesn't implement this or that practice. Some produce incredibly complex planning documents that don't seem to provide much benefit.

In my mind, if it isn't getting done well, you must simplify the process rather than make it larger and more complicated. Threatening, educating, and licensing people into compliance isn't going to have much real benefit if the practices are simply too complex or cumbersome to apply effectively. To eliminate the pathology of poor planning, we must simplify project requirements to the essential elements required to specify the desired software. Then we must put processes in place to obtain that information in the most efficient and direct way possible. The first example of a well-known document that is typically overcomplicated and overinflated is the famous Vision Document.

Page 3 of 8

This article was originally published on June 6, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date