practices. Often, a proposal fails to convert to a project because the proposal documentation lacks concise and expressive language, professional organization and polish. It may not be their inability to deliver, but their inability to express their capability.
For many, documentation is only about creating user manuals and online help, and even that documentation lacks an established process. When a project nears completion, a writer is called upon to document it. Someone sits with the technical writer and quickly runs through the application, telling the technical writer to prepare a user manual and to "please call on me if you have any questions…" The technical writer does their best to prepare a manual for the application. Then come the calls for more training or help over the phone, and half of the support staff will be answering queries on the user manual itself. Think how much time would have been saved if the documentation had been considered an important part of the process from the beginning.
Doing it is important!
It's not that we don't know how to do the documentation right. We just don't think it's important. The simplest thing one can do is to involve documentation people from project initiation and let them understand the project dynamics, technology, domain, and objective. We need to make sure the person who does the documentation-whether internal or external-understands the document audience well, and the purpose and objectives of creating the document. Once this is done, the documentation will be organized and articulated in a way that makes sense to the readers. The idea behind this is to take a proactive approach toward documentation. We will surely be better off planning our project documentation and executing it when the writers know the purpose and stay involved throughout the lifecycle.
To set our documentation standards in place, we need to integrate our software processes with our project documentation requirements; specifically, the various documents and records we create for our quality conformance purposes should adhere to set document standards. There might be the understanding that "we already have templates that we follow." But I am not talking about the process we follow for certification's sake (e.g., ISO or CMM). I am talking about synchronizing our real quality assurance with our documentation standards and other processes. Hence, it is very important that both our QA and documentation processes go hand-in-hand and that both departments work in synchrony. It actually has to be a synchrony triad-the processes defined by QA, followed by the technical people, and documented as per the standards.
Remember that change happens slowly. This morning, I spoke to our team of project owners and told them it is important to follow whatever standard templates and styles we publish. As I was enjoying my cup of coffee with a sense of satisfaction thinking about the morning session, I received a call from one of the project owners. He congratulated me on all my endeavours to bring order to the chaotic environment, and then he came to the point: "Kumar, I have a document to be reviewed. I wish I had time to format it in line with the dot template you sent me the other day; but I think you will appreciate that I have an important design review to attend. Can I send you the document and ask that one of your technical writers format it according to our style before it is reviewed?" I hung up the phone with a very hesitant "Yes." Old habits die hard, but if we are persistent and patient, our efforts will pay off, and others will