Last night after the final install of a solution, Mike and I hit the pub for a couple of celebratory beers. A lot of my "spare" time of late has been thinking about ways to improve the quoting/communications/management of projects, so as you can guess this is where the conversation moved. We both agreed there is a major mismatch between what we as developers see as a detailed design and what the customer understands. Talk about normalization, ER diagrams and flowcharts and watch the customer's eyes glaze over! Clearly we are speaking two different languages.
The trick appears to be to speak in terms they can understand, yet include enough technical detail that you can quote accurately and still allow some movement due to small, inevitable changes in the project down the track.
I have devised a logical design for how these two levels of communications may be met, now we need to think about how to implment this.
I don't think a document can accurately track the changes in a project. Over time, keeping the document up to date will result in a weighty tome too much to digest in one sitting. In addition, if you keep updating the document and sending out the latest copy, it's hard to see what has changed and what is new. Very soon recipients of the document stop reading it - broken communications again.
Very few IT projects I know have gone perfectly, obviously the skills we are being taught at university are not the right way to address the software projects.