Understanding the Planning Process, Page 5
We often spend as much time preparing this document as we do developing the application it represents. This entails a tremendous expenditure of time, effort, and resources. The amazing thing is that in the end, no working code is actually produced. That is not to say it has no value, but it will not process one transaction, send one byte of data to a hardware controller, or accept one character of user input.
Certainly one would argue that the Functional Specification pays for itself ten times over by preventing errors and inefficiency during development. This is the basic assumption implicit in most planning literature. That may be true when the Functional Specification is appropriate for the project it represents. However, all of the reported benefits of a Functional Specification do not normally consider its quality. They do not consider the cost and risk of a poor Functional Specification.
The reality is that many Functional Specifications are quite poor and fail to produce a fraction of their expected benefits. In practice, we are fortunate when developers can find anything of value in a Functional Specification. Often it is highly debatable as to whether these documents are worth the effort that was put into them.
At that point in their studies, my students should not be expected to know how to write an effective planning document. However, the same degree of variation in content and quality exists in most commercial Functional Specifications. These documents come from professionals who should be skilled in this work. Even though the real-world specifications get bigger and take longer to produce, they don't necessarily get better. If anything, the authors of commercial specifications have even less ability to produce a useful specification than my students, relative to the scope of their tasks.
Most commercial-quality specifications suffer from the same fundamental problems as the student specifications, except on a larger scale. They are verbose and complex, they lack cohesiveness, and they include a great deal of extraneous information. If anything, the problems are magnified because of the greater level of scope, detail, and interdependency required in a commercial application.
Consequently, as with the Vision Document, the Functional Specification does not get utilized as effectively as the planners might imagine or hope. In far too many projects, the developers barely look at the specification. When they do consult it, they typically absorb only the few discrete sections that are useful and then ignore the rest. Usually the only parts of the specification that have much value are the screen mock-ups or prototypes. Even these mock-ups are often created without considering the needs of the developers. The rest of the information is frequently too sparse, disorganized, inconsistent, and incomplete to be of much value.
Developers typically take what they can from the specification, and then go back to the client experts for additional information. From the developer's perspective, this is far more efficient and accurate then trying to glean more information from the specification. From the management and client perspectives, this is frustrating and redundant. Even worse, it opens the possibility of scope creep.
The term scope creep describes the phenomenon in which features are added or changed after the specification is finalized so that they increase the time required to deliver the product.
Planners probably spent many months working on the Functional Specification in an effort to anticipate and provide the developers with all the information they need to produce the product. They are understandably frustrated and bewildered when the developers never seem to use it effectively. Management concludes that greater control is needed to force those developers to adhere more rigidly to the specification.
As with the Vision Document, the reason that these documents are so out of touch with the needs of development is that the planners probably never actually asked their developers in advance what they need and how to present it. Developers were handed a document that did not seem to be prepared specifically for them. And in truth it probably was not. It was probably prepared first and foremost to satisfy the very different expectations of management and client.
What we end up with is a highly inefficient planning process that devours resources and doesn't meet the needs of the developers in the end. The best way to produce an effective specification that serves developers is to go direct to blueprint 9 and use the Software Blueprinter application 10 or something like it to produce a developer-oriented specification as the planning process progresses.
2.4 Recognizing a Bad Plan
We have been discussing the reality that the cornerstone documents of project planning—the Vision Document and Functional Specification—often fail to produce the benefits that one might hope to gain, relative to the cost incurred.
By recognizing the typical planning problems that plague projects, you can better redirect those projects and more readily avoid those mistakes in your own planning. And there is no lack of bad plans out there to be found. It is easy to recognize bad plans by looking for some telltale indicators.
First, look for signs of underplanning. If the plan is sparse, it may mean that the plan suffers from a lack of good planning. But that is not necessarily so. The best plans should be the most concise. You can't confirm underplanning based on small size alone. You must look for the absence of critical components such as a Data Dictionary 11 and a blueprint.
Overplanning is more reliably linked to large size. If the plan is bulky relative to the scope of the project, then it may suffer from too much bad planning. Bad plans tend to make up for their lack of quality with sheer volume. The key concern should be quality, not size, and conciseness is a key metric of quality. Don't be fooled by size!
Lack of a Data Dictionary
Perhaps the most glaring sign of a bad plan is the lack of a Data Dictionary. Without an unambiguous vocabulary, the language of the plan is almost certainly imprecise and inconsistent. This ambiguity will inevitably lead to programming questions or errors due to imprecision in what was felt to be perfectly clear and detailed narratives.
Another symptom of overplanning is a predominance of metadata.12 Metadata is information obtained during the analysis of the client business processes. It includes things like Use Cases, Test Cases, Sequence Diagrams, Process Flow Diagrams, narratives, and other analytical graphics. Metadata may be useful in understanding the business requirements, but not necessarily useful in communicating requirements to the development team. Planners that call it a day after producing metadata alone seldom deliver a useful blueprint.
Unless someone sifts through metadata to find its bearing on software requirements, it remains a nebulous fog, which can obstruct the vision of the developer. Information in blueprint form should not need to be further analyzed by the developer in order to establish its relationship to other elements or to the functionality to be implemented.
Another telltale sign of a bad plan is the presence of a lot of unrelated, unorganized details. These plans contain extraneous information simply collected and tossed in, assuming that someone, somewhere, sometime, may need it. It was probably acquired in an uncontrolled information dump 13 from the client, never really understood or analyzed, but included mainly to protect the planner from being blamed for omissions.