After reading the previous section, I know you get my point. However, I will spend some more text on the matter, because it's too important, and the natural tendency within software projects is to consider software design documents as a product of their own. "We design to create a design." Wrong, wrong, wrong. A design is a medium to tell how the requirements will be translated to the real world. And there lies the problem for project management with specifications and designs; the designs are considered to be a word passed from one technician to another. The global expert, tells the detailed expert, who tells the developer what to do. And they pass their message by the medium 'design'. They leave out the non-technicians, the 'normal' people…

During the actual construction of the design documents the software project manager will not be involved too much in the discussions. And if he is, it's not because he has the role of project manager. The biggest challenge for the manager is to make sure the communication to the stakeholders is done effectively and timely. He should make sure that once in a while the software gurus come out of their cave and tell in understandable words what they are envisioning. These discussions are legendary, two different worlds meet each other. Try to order something in Paris and you catch the drift.

Enhancing the chance of success

The project manager can do something to enhance the chance of success of this process. First, to be aware… and that you are now. Second, the choice of the guy or gal leading the design activities should not be solemnly based upon his technical know-how, communicative skills weigh even stronger. And, last in the 'open-door' series, take more time for the software design documents than you think you need. Take the time to create designs. You will earn it back later on. However, use the extra time for communicating with the stakeholders, not to make your graphics look more slick.

The communication between the designers and the stakeholders can take place in workshops and other kinds of meetings. So, the project manager, that means you, can check if such meetings are planned and held, or can even actively schedule such sessions or emphasize the need for them. After such a meeting is held, schedule a talk with one of the stakeholders to see if he got the information he wanted.

Document it all

To ensure that the information is presented in such a way, that the stakeholders can understand the specifications, the designers should keep track of all the decisions they made, and, more importantly, the arguments why they made a certain decision. If they decide to use Super XMLParser sub-system GNA (don't try to find this one) somewhere should be recorded that they intend to use it, and further more, the arguments on why this sub-system and not an other one. If they talk with normal people, then at least they can keep up the appearance of knowing what they are doing, to be aware of their actions.

But stakeholders just want to know one thing: "What the heck happened to my requirements?" So, the next log the designers have to keep is the one containing relations between the design decisions and the requirements issued. A paragraph in a design on the generation of an error log file in HTML on some server, should be linked to have an "easy to access medium to verify incorrect responses of export to the other system." The latter being an example of a requirement. In preparation for one of the feedback meetings a designer just has to see who's coming, extract their requirements and present the information on what he did with them. That's feedback especially tailored to suit you.

As a closing remark for this section, remember that designing is an iterative process; you design, you discuss, you throw stuff away and put new consideration into it. You win some, you lose some. Keep this in mind, when you design the process to perform these activities. Brooks (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition) even states that you have to plan to throw one away. You will in the end anyway!