Although this topic is touched upon in the previous chapters, this chapter concentrates on comparing PKM against project documents with respect to the creation and maintenance of project knowledge. It introduces both the mechanisms and provides an exhaustive comparison of the two from different perspectives. An example is provided for both document extract and PKM extract to aid understanding of their differences. It also details the artefact sets that can be extracted from PKM.

Project Knowledge Model and Project Documents

Figure 6.1 depicts how knowledge is managed in a typical project delivery from the perspectives of PKM and document production regime. Document production regime is based on Waterfall (structured) methodology. Agile methodology have a sleeker version of the document production regime.

Any methodology of software development starts from gathering requirements and ends with the working software and the related specifications of the software. The traditional methodologies have been relying on document production regime for capturing specifications of the software from solution, technical and test perspective. In the Waterfall methodology, emphasis is given on rigorous maintenance of the documents during different phases of the project delivery. Agile methodology go for ‘fit-for-purpose’ documentation and documents are kept at high level so that they do not need frequent changes.

As mentioned earlier, keeping the documents updated in real-time is a challenging task in project delivery and that causes a lot of gaps in communication, ultimately delaying the project. This is one reason the Agile methodology only go for high level documentation that does not need frequent updates.

The main issue with the document production regime is that there is a need to update the contents of the documents regularly as the project progresses through different phases. But the problem is the before the updated document can be issued, it needs to be approved by the relevant stakeholders. The revised version of the documents is mostly issued on reaching selected milestones. For example, in Figure 6.1, six versions of BRS (Business Requirement Specification) are visualised over the course of the project delivery lifecycle. Let us say there is a gap of two months before the next version of the BRS is scheduled to be released. From the couple of days of release of the last version, the information contained in the document may not be the latest.