Project and Design Documents
SharePoint products and technologies are best thought of as a solution platform. This means, however, that it is impossible to define exactly what constitutes a SharePoint solution and therefore what design deliverables are required. I have seen many SharePoint projects that are nothing more than installing WSS and turning a departmental team loose.
While this approach may violate several planning and change principles, it certainly is not a project that requires layers of design documents. On the other hand, I have also been part of unique projects that utilize forms, documents, search, and workflow to implement specific processes. In these projects, good documentation—specifically use cases—is invaluable. Furthermore, SharePoint solutions are iterative by nature; as users become more familiar with the environment, you end up fine-tuning your solution.
As a result, you must decide for each project how much documentation is needed. The danger here, however, is that it’s just so easy to start customizing in SharePoint. While this is not necessarily a bad approach for small projects, it can also lead to a maintenance nightmare if entire departmental or enterprise solutions are approached in this way. Instead of customizing many sites individually, for example, creating a single site template that can be used over and over will be much more efficient.
