In my blog The Project Knowledge "Elephant" (02) I said:

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.

I wish to start that explanation of the Project Knowledge Model (PKM) here in this blog.

The first element of the Project Knowledge Model (PKM) is to understand that there are "sectors" of knowledge or information about a project or sectors of a project's information/knowledge asset (IKA) as I have illustrated below.

Broadly these sectors are for the Vehicle:

• Requirement for the Vehicle. This is the requirement for how Vehicle is to be run. The type of knowledge might include selected principles of project management as embodied in the PMBOK or PRINCE2, quality standards such as ISO 9000, configuration management standards and so on. It might include a series of organisational policies or internal directives on what a Vehicle needs to achieve. However, no matter what else or how it might be derived, it must include a series of stakeholder agreed outcomes on what the Vehicle must achieve. I will explain more of this later.
• Solutions for the Vehicle (Deliverables). Plainly if you have a series of requirements to which the Vehicle should/must comply, there are a series of solutions that should be delivered to demonstrate or meet that requirement. It is this set of knowledge that is required here.
• Process to Transform the Vehicle Solutions. Once you have identified a set of solutions, the process by which those solutions will be developed and produced needs to be articulated. This knowledge goes here.

The knowledge sectors for the System are:

• Requirement for the System. This is the requirement for a system of some sort such as a new product, new software, a modified facility or even a new organisational location. There are numerous ways to currently articulate this including user and system requirements, architect's brief, developers guidance, customer requirements, and use cases to name but a few.
• Solutions for the System (Deliverables). The solution space for a system should describe the design of the system in terms that make sense to that industry, system user or customer as well as the builders/developers of that system.
• Process to Transform the System Solutions. This is the processes that are to be used to transform the solutions from their current state to their required future states to bring the system into existence or to change it in accordance with the requirements.

I will expand on this and explain the "flow" that is able to be generated from this sort of conceptual framework.