See the previous blog on this subject at The Project Knowledge "Elephant" (01).

Accordingly, when it comes to "seeing the elephant", it is best to:

• See the elephant early rather than late. It could be said that this is the "big bang" approach to requirements definition and system development. Define the requirements in detail and then build to that requirement with hopefully as few requirements as possible changing (as measured by say "requirements volatility metrics"). This is probably no more epitomised than in some aspects of the CMMI methodology.
• If you don't see the elephant early then you need to have mechanisms that permit you to quickly respond to the elephant as you see it. This is epitomised by the agile software development processes where they capture some requirements and then develop against those in short cycles - evolving the system as the user/customer evolves their understanding of what is required.

This conceptual spectrum I have illustrated below with the "big bang" being on the left of the spectrum and the "agile" on the right of the spectrum. Plainly there are numerous areas for compromise depending on the type of system being created or changed and perhaps the type of culture the organisation running the vehicle has.

If we accept that "knowledge" of the system and vehicle, and so the project, is essential to a successful project, then we can start to get a better understanding of a project by looking at what "knowledge" is required.

For this I use what I call the Project Knowledge Model or PKM and I am going to explore some of its broader concepts in this next series of blogs.