If we admit that the 1.2.1 definition unambiguously decides whether an endeavor is or is not a project, than we must admit that endeavors creating not unique product (service, result) are not projects. Let us look at consequences steaming from this assumption.

The decision of performing a project is made in the Develop Project Charter process. Project Charter must contain, among others (4.1):

Requirements that satisfy customer, sponsor, and other stakeholder needs, wants and expectations,
Business needs, high level project description, or product requirements that the project is undertaken to address.

There is nothing in this process about defining unique product, but about business requirements and needs. Even product requirements (which are quite distant from product definition) are not obligatory! And this is the right approach. Just the business needs drive projects.

The next in the control thread is the Develop Preliminary Project Scope Statement process. It requires, this time obligatory, product requirements. But they are only requirements, not description. Many different products may be defined on the basis of the same requirements. Once they may be produced at home, once purchased from one or another manufacturer. In Polish public bid regulations it is even legally strictly forbidden to define product requirements in the way unambiguously defining the final product. There must be open space for competition of many service or product providers. When you define requirements that a car must have the power of 150 hp, max speed not less than180 km/h etc, you may not say that you have pointed out a car. Product requirements are not product definition.

The full knowledge about deliverables to be produced is mandatory not earlier than in the Scope Definition process, when project works are substantially advanced. The main output of this process is Project Scope Statement, one of its section are Project Deliverables: „(...) any unique and verifiable product, result or capability to perform a service (...)”. They “(…) may be described there at a summary level or in great detail.” So only there (we did not know the product before) we may assess anything about project product, especially its uniqueness (btw. I think that “uniqueness” as defined by PMBoK means nothing.).

So, if we admit that we decide whether an endeavor is or is not a project, then not earlier than in this process we may decide if the planned works constitute a project. Consequently if, after defining deliverables we find them unique, we proceed to next processes and phases of project planning and execution. Otherwise we are not entitled to use project management knowledge and technique and we, as people form project management society, loose interest in this works. Particularly we would be obliged to inform the project initiator, that his/her decision was wrong. She/he initiated as a project some work which are not a project.

Making decision about project execution according to PMBoK

Please notice that ANY reference to deliverables’ characteristics generates the same problem: suspends the decision of project execution till its precise definition, ie. till the Scope Definition process. If we define that only green (heavy, southern, user friendly…) products may be produced by products, then we would have to wait till the Scope Definition process with the decision about project execution. Otherwise: if uniqueness in the 1.2.1 definition means anything, we may not say that an endeavor is a project before executing the Scope Definition process.

Practical irrelevance of project definition

The requirement of product uniqueness is too strong. It may happen that an office buildings is developed according just to the same documentation as some other developed previously. A program: “Thousand (elementary) schools for thousand years (of Polish history)” was very well known in Poland some years ago. The same with office buildings: hundreds of buildings of „Leipzig” type are popular in Poland and probably in other former communist countries. The design, type of location, subcontractors and owner were the same for all the schools. But every process of school building development might have been considered as really separate project. And every real, not methodically oriented building company, would think just this way, without any awareness about building uniqueness. The only important matter is that the endeavor of school building would satisfy its requirements and that it would be possible to apply project management knowledge to this work.

During process initiation no one bothers with testing whether a product is unique or not. The only important thing is the purpose of the work.

Project product traceability

The good, operational definition of anything must provide, at any phase of an item’s existence, tools for assessing whether this item fulfils the definition. Moreover, the definition must guarantee that items identity is recognized by identity of items used in its definition.

All the factors in the project definition constitute a project. It means that project X producing product X1 or service S1 or result R1 is not the same as project Y producing product X2 or service S2 or result R2 if X1 is different than X2 or S1 is different form S2 or R1 is different than R2. In business reality of most organizations, decisions about the set of performed project are made, as stated in chapter 4.1, externally to project organization. If we treat the 1.2.1 definition “as is” it would mean that even the smallest change in product scope would need sponsors decisions. But this is not the way in which organizations make the decisions concerning project products. The project manager is always authorized to control – to some extent – project scope.

Other comments

Looking even more formally at the definition. There is singular mode and “or” conjunction. It means that a project may deliver no more than one product one service and one result. So, unless applying linguistical tricks, there is no possibility to charter a project aiming at building more than one building (especially in remote locations).

Product uniqueness. What does it mean? According to the explanation in section 1.2.1.2 for two buildings it is sufficient to be called “unique” if two of them have different location (probably the same with other objects). But in our physical world every two different things must occupy different location, so adding the “unique” adjective adds nothing to our knowledge about project result and projects. The solution

There is a simple way to remove all these problems. Project definition must be constructed in a way that enables decision makers to correctly define the projects when making decision about its initiating. The natural way to do it is to use project characteristics enlisted in point 4.1 as factors constituting a project.

A project is a temporary endeavor undertaken to do one ore more of the following: solving a problem, exploring opportunity or satisfying business requirements.

This definition solves all the above presented issues with project definition.

Knowledge in PMBoK

Types of knowledge

As it was shown on PMBoK figure 1-2, this book does not cover all the project management knowledge. What really is described in this document are the project management processes. They are grouped and presented from two perspectives. The first of them is a set of process groups: initiating, planning, executing, monitoring and controlling and closing. The second perspective is the nine project management areas. The better name would be “process areas” instead of “knowledge areas”. Each of the areas (chapters of PMBoK) contains a set of processes from this area. For the need of management area description we may divide the knowledge into two parts: processual knowledge and off-processual (declarative) knowledge.

General structure of project management knowledge

Knowledge is the whole of information acquired as a result of learning process. Processes make only a part of an area knowledge.

The processual knowledge is a dynamic knowledge describing the way of transforming input objects into output objects. The declarative, off-processual knowledge is a set of static information describing objects present in given area, and its attributes. For instance in the cost management area the processual knowledge describes the way of cost estimating, cost budgeting and cost control. The most important part of declarative knowledge in this area consists of price lists.

Levels of knowledge description

There may be three levels of detail of knowledge description:

Units level

Defining knowledge units. On this level knowledge units are distinguished and pointed out. The knowledge units often are defined at the aggregate level.

Examples

Price list

Change Request

Structure level

Defining units structure. The internal structure of knowledge units, their relationships and attributes and are defined on this level of description.

Example

A price list must contain parts for products prices and services.

For every product there must be as many records as products providers. In every record there must be a place for:

Product Name
Provider’s identification (reference to a separate knowledge structure)
Unit of measure
Unit price
.......

For every service there must be as many records as service providers. In every record there must be a place for:

Service Name,
Provider’s identifier (reference to a separate knowledge structure)
Work duration
Price
.......

Full level

Full knowledge presentation. The highest level of knowledge description is just its presentation. This is the structure of knowledge filled with information in every record.

The (full) project management knowledge is the full knowledge about all the knowledge units from that area.

Knowledge perspective in PMBoK

The management areas may be presented from two perspectives:

Process perspective
Knowledge perspective

The process perspective is the one in which an area is described as a set of processes: an area contains processes, processes contain inputs, functions (techniques) and outputs.

The knowledge perspective is the one in which an area is described as a set of interrelated knowledge units. This perspective has been described in detail above. Please notice that every process may be treated as a separate knowledge unit in every management area. It has its data units, attributes; there are relationships between processes. Hence the process perspective may be treated as a special case of knowledge perspective. Every process description may be more or less detailed.

PMBoK contains almost full processual knowledge. But the description of declarative knowledge usually is left on the knowledge unit level. So it is difficult to admit that PMBoK is the full PM knowledge description. After all figure 1-2 shows that PMBoK does not present the full project management knowledge. We may precisely point out the PMBoK knowledge – this is just the processual knowledge.

The PMBoK Guide is the accepted standard describing the process of project management and the management of individual projects through their life cycle.

Because the portion of project management knowledge described in PMBoK is well defined, this document should have more adequate name: this name should be “The Project Management Processes Framework.”

In order to agree that this document describes all the project management knowledge, much more declarative knowledge should be covered by it. The knowledge description should be moved from the unit level to at least the knowledge structure description level. The knowledge structure may be described as an additional component of every PMBoK chapter or may be an appendix to the whole book. Moving to the next, even more detailed level would demand a lot of additional work related to collecting these data.

Scope of project management knowledge

The knowledge may be general, environment dependent or pertaining to a particular project.

There are different scopes of knowledge described at the highest, full presentation, level. I can see the following scopes:

Global

Some detailed declarative knowledge may be used across all the projects and organizations. The example of such knowledge is, for instance, the knowledge about project stakeholders. You may globally name every stakeholder for every project. And this knowledge may be found in PMBoK (chapter 2.2).

Domain dependent

Every application domain has a substantial amount of its knowledge. So called “technical knowledge” is the best example. But also a set of roles needed for performing a project in a given domain, which is a strictly managerial knowledge, is of the same type.

Local

Some knowledge is applicable for particular area. The price list is the best example. Polish price lists are totally inadequate for Russia as well as for the United States.

Organizational

Most of the project performing companies develop and maintain their knowledge data bases. Their experience with project management is described there. The experience may have the shape of procedures, lessons learned, data about particular resources performance etc.

The division into these levels is not a strict one. These levels may intersect.

The presence of global declarative knowledge in PMBoK shows that PMI recognizes that the declarative knowledge is an integral part of project management knowledge.

No doubt the knowledge of all the above mentioned scopes is needed for successful project management. If so, than there should be some initiatives to develop such databases. The open question is: who should do it. When I think of this problem I think of several public initiatives like Panoramio of GoogleEarth, YouTube or GNU software initiative, in which everybody who has access to the Web may contribute to these initiatives. The question is: who should be the moderator of such project in the project management area. For me the answer is obvious: the most appreciated public organization in this domain – Project Management Institute.

On the basis of consideration of relationships between processual and declarative knowledge I think about other structure of PMBoK. All the processes should be totally integrated (Prince 2 is a good example to follow). If so, they should not be divided into nine management areas. There should be one process described in the Integration Management area. In PMBoK 2004 we can see the right move in this direction – there is figure 4-2 depicting the whole project execution process at the highest level. And only the declarative knowledge should be attached to separate project management areas.

No business management in PMBoK

Processes are performed to achieve business goals. So the most important area of project management should be just the business goals management (or, for simplicity, business management). But this area is absent from PMBoK. There are many references to this area, especially at early stages of project life cycle, but business management has not received as much attention as it should.

There is a natural structure of Business Management knowledge area:

Defining business goals
Business goals monitoring and control
Business effects assessment

Defining business goals

This process is performed to define, accept and describe business goals for which the project is initiated and performed.

Business goals monitoring and control

Business goals monitoring and control covers activities performed during project execution in order to assure achieving these goals or modify them. A special activity in this process may be early project termination – when it is impossible to achieve the planned goals and there is no way to define new project goals satisfying all the key stakeholders.

Assessment of project business effect

Assessment of project business effect are activities aiming at assessing whether project business goals have been achieved. This process is often executed after processes of project closure.