PMBoK project definition
Logical inconsistence of project definition with
project management processes
Practical irrelevance of project definition
Project product traceability
Knowledge in PMBoK
Types of knowledge
Levels of knowledge description
Knowledge perspective in PMBoK
Scope of project management knowledge
No business management in PMBoK
Defining business goals
Business goals monitoring and control
Assessment of project business effect
PMBoK project definition
The PMBoK uses the following definition of a project
A project is a temporary endeavor
undertaken to create a unique product, service, or result.
from the other hand, according to the description of Develop Project
Charter process (chapter 4.1):
„Projects are usually chartered and authorized [...] as a result of
one or more of the following:
· A market demand [...]
· A business need [...]
· A customer request [...]
· A technological advance [...]
· A social need [...]
These stimuli can also be called problems, opportunities or business
to PMBoK a project comes to existence in the
Develop Project Charter process.
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.
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.
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.
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
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
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.
decision about project execution according to PMBoK
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.
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.
process initiation no one bothers with testing whether a product is unique
or not. The only important thing is the purpose of the work.
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.
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.
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).
uniqueness. What does it mean? According to the explanation in section
18.104.22.168 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
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
definition solves all the above presented issues with project definition.
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.
structure of project management knowledge
is the whole of information acquired as a result of learning process.
Processes make only a part of an area knowledge.
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.
may be three levels of detail of knowledge description:
knowledge units. On this level knowledge units are distinguished and
pointed out. The knowledge units often are defined at the aggregate level.
units structure. The internal structure of knowledge units, their
relationships and attributes and are defined on this level of
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
- Full level
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.
management areas may be presented from two perspectives:
- Process perspective
- Knowledge perspective
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.
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.
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.
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
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.
knowledge may be general, environment dependent or pertaining to a
are different scopes of knowledge described at the highest, full
presentation, level. I can see the following scopes:
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).
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.
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.
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.
division into these levels is not a strict one. These levels may intersect.
presence of global declarative knowledge in PMBoK
shows that PMI recognizes that the declarative knowledge is an integral
part of project management knowledge.
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
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.
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.
is a natural structure of Business Management knowledge area:
- Defining business goals
- Business goals monitoring
- Business effects assessment
process is performed to define, accept and describe business goals for
which the project is initiated and performed.
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.
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.