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 product
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.).
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
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
184.108.40.206 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 requirements.
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)
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.
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.
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 description.
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
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
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.
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.
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