I have just completed (what I hope is) my final revision to a set of discovery documents. This is my first "real" output at the new gig, so I'm hoping there are no holes, mistakes, oversights--not to mention lousy grammar, etc. It's been an interesting process putting these together, knowing that they are client-facing, and will be read at least once by the nice people who pay us large sums of money to do this for them. Not only that, but they're technically the first true work product I've generated at this gig. And these are also very likely the only documents I'll need to build for this project. So, I'm wanting to overshoot a bit.

All the docs required for my previous corporate gig were pretty much for a technical audience only, consisting of a requirements overview and quasi-detailed functional specifications. Neither of these was ever examined (or, in many cases, read at all) by the business team. The information they wanted was communicated in emails, meetings, and by "unofficial" throw-away docs printed specifically for said meetings. I was also the coder in almost every case, which rendered the functional specs doc somewhat superfluous or at least redundant for development purposes. But even on those, my personal investment disallowed me from permitting spelling/punctuation/gross grammatical errors, and my conscience as a developer kept me from throwing in "filler" or just skating by with them. Plus, those docs were used by QA to establish a test plan, so there was an actual purpose and audience.

So what's the difference between our two coexisting worlds? Well, it's not so predictably cut and dried in this arena.

In the consulting world, your document deliverables had better be A) actually "deliverable" and B) worth doing. If you're burning hours on something of no value to client or company, or, worse yet, that makes the company look sloppy or incompetent, then why bother? Depending on how formal the shop is regarding methodologies, I'd wager that you will typically have a "leaner" set of documents on the average project in a consulting shop. You will do what's been contracted or is necessary for client communication, but no more. The rest of that time MUST be spent on actual development, creating the product.

In the corporate world, the documentation experience runs the gamut. Some places have actual document templates (with varying levels thought put into them, yielding various levels of success), while others work it freestyle. Some places actually have active audiences for their development docs, others not so much. Some shops go way overboard on requiring deliverables, others undershoot healthy levels of documentation. In my corporate experience, the required documents mostly had value, but were frequently unread by their target audience. However, I've also been witness to the birth of vast numbers of RUP artifacts into a corporate project atmosphere of total apathy. Sheafs of use-case diagrams, sequence diagrams, UML versions of the Last Supper -- you name it; unread, unused, sent straight to dead-document heaven. All just to satisfy a decree that RUP should be followed TO THE LETTER. So documentation in corporate development is harder to singly classify. There is plenty of room for and evidence of the waste I typically attribute to the corporate world. But there are also sensible examples.