Project documents or online repositories (Part One)?

When designing project delivery methodologies, we are faced with the decision of whether information should be housed in standalone documents or in online repositories. While there are those who view this as a binary choice, I would advocate a hybrid approach. Assuming we have or can procure or build underlying tooling support we can then choose to host some information centrally and utilize standalone documents for the rest.

Before proceeding too far with any of these options, it’s important to understand the advantages and disadvantages of each so that we can pick the right approach for each need.

Benefits of a document-centric approach include:

• Low cost of implementation and limited training requirements – whether it’s MS Office or a competing suite, most organizations have already deployed the basic desktop applications needed to support creation of project documents and the staff who will be working on projects are usually sufficiently competent with the use of these applications.
• External stakeholder access – as vendors and other external stakeholders are quite likely to have the desktop applications used to create the project documents, there is little difficulty in sharing these documents.
• Ease of providing guidance and examples – project document templates can be created with structure and guidance to facilitate appropriate usage and examples of properly populated instances can be easily shared.
• Approvals and versioning can be implemented easily – it is not challenging to conduct reviews and get approval using standalone documents, and taking a snapshot or baseline of a document is fairly simple.

However, there are some drawbacks when using documents to house project information:

• Collaboration is challenging – while documents can be easily shared, the desktop applications used to create them don’t lend themselves well to having multiple contributors collaborate to create a document. Attempting to do so in a distributed manner often leads to document corruption or overwritten changes so invariably one person holds the pen or a game of hot potato gets played.
• Documents proliferate like roaches – because of the relative ease of adding a new document to the methodology, without constant vigilance and refactoring it is easy to end up with too many document templates along with their supporting entourage of job aids and examples.
• Redundant or conflicting information – documents supporting project delivery are moderately interdependent. Standalone documents usually replicate common information elements such as tombstone data and when a change gets made to one document template, the effort required to ensure consistency and alignment with all dependant document templates can be prohibitive.
• They encourage an obsession on generating comprehensive documentation over delivering business value

But before jettisoning your documents in favor of a centralized tool, read next week’s article in which I’ll assess the pros and cons of that approach!