So your company wants to adopt a new approach for software development projects. The selection committee wants to pick an approach that can be used across the board — on all projects. The committee naturally focuses on big (i.e. expensive) projects because they offer the biggest bang and the biggest risk.
The development approach they select has all the deliverable artifacts any project manager could ask for. When in doubt about an artifact, include it. Better to have too much documentation rather than not enough, right? Here is a short list of what might be included in the documentation for a major project:
- Vision statement
- Statement of Work
- Project Plan
- Requirements Specification
- User Interface Documents
- Functional Specification
- System Design Documents
- Technical Specifications
- Test Plan
- Test Procedures
- Release Plan
- Deployment Plan
I could go on (and on) but you get the idea. If you like writing documentation, there are plenty of opportunities in the world of software development.
I’ll concede that some large, enterprise projects require substantial documentation. The biggest issue I have with it is that much of that documentation is often redundant. Information is frequently copied from one document to another as each writer tries to make his document thicker than the one before it. It’s simply W-A-S-T-E-F-U-L.
As for smaller projects, requiring them to conform to the same rules as large projects is a big mistake. Some companies will select a subset of the documentation set and make the subset mandatory so small projects are not required to deliver all the artifacts required of large projects. But that doesn’t work either if the documentation subset relies on the same templates and rules governing large projects. There will still be far too much overhead (i.e. cost) for the value derived.
Reverse the Thought Process
What’s the solution? Instead of starting with a document-heavy approach, start with a minimalist approach. Establish two ground rules:
- Keep the document set minimal. Each document must provide substantial added value to the company and/or it’s customers.
- Keep each document brief — no redundancy and no boilerplate.
Allow teams to add artifacts as needed but make them justify the effort needed to create the artifact. When it comes to software development, one size does not fit all. Project teams need some latitude. Let the small teams run as fast and free as they reasonably can. Place more controls on large teams but only enough to keep them on track.
photo credit: Rowan-Harrison via photopin cc