Your Ad Here

Knowledge - MAX

“We live in a world of self-generating beliefs which remain largely untested. We adopt those beliefs
because they are based on conclusions, which are inferred from what we observe, plus our past
experience. Our ability to achieve the results we truly desire is eroded by our feelings that: our beliefs
are the truth; the truth is obvious; our beliefs are based on real data; and the data we select are real
data.” (Ross 1994)
Since 1995, we have witnessed four Global Project Management Forums (GPMF) which have been
conducted with heightening interest and success. Undoubtedly, this is a reflection of the increasing
recognition of the ‘globalization’ of the market place and the competition that it brings. Project
management is no exception. However, if we are to advance towards a ‘Global Profession’ as some
suggest, then we need a vehicle for effective communication and a common understanding of the field.
Communication was clearly on the minds of the GPMF when they put forward the objectives that state
in part:
• To provide leaders of the project management profession around the world with the
opportunity to ... share information and to discuss issues...
• To advance globalization of the project management profession, by promoting
communication ... around the world.
• To provide educational opportunities for participants to learn...
• To advance the project management profession technically, and in more geographic areas,
industries and organizations, on a global basis.
But how can we achieve these laudable objectives without some collective and common understanding
of the dimensions and content of the project management profession and a vehicle for communication?
True, there is no shortage of books, articles, videos, and CD-ROMS on project management, projects,
and ‘how-to-do-it’. Yet there are still areas we have barely begun to tap such as better project portfolio
selection, program management, and beneficial product transfer with collective focus on supporting
corporate policy rather than individual and competing project goals.
How does this all knit together into a comprehensive whole? Since project management is clearly
pervasive and complex, do we not need some semblance of structure to facilitate learning? This paper
attempts to address that issue.
Last year this author reviewed some historic attempts to structure knowledge in general, and the Project
Management Institute’s Project Management Body of Knowledge in particular, by means of various
models (Wideman 1997). However, concept mapping is becoming increasingly popular with researchers
and educationalists as a way of capturing a knowledge area. Typically in a brainstorming wallboard type
session, the approach forces discovery of basic conceptual units and their relationships.
Concept maps are graphic displays of knowledge topics in a node-link structure. The nodes represent
concepts, entities or things that are described by labels with a set of attributes. The links show both the
connections between nodes and the nature of the relationship. A big advantage of the concept map is that
it provides a visual image making it easier to study the components and their relationships. However, the
particular view of the given structure must be stated explicitly because intellectual’ structures can be
seen from many perspectives.
The author’s 1997 paper describes the steps to creating a concept map, the view of project management
selected, criteria for inclusion or exclusion of ‘node labels’ and the resulting findings presented as the
first few levels of a more familiar breakdown structure. This framework is referred to as a Project
Management Knowledge Structure (PMKS) and the node labels as Project Management Descriptors
(PMDs). The objectives of the framework are worth reemphasizing. The PMKS must be:
1. Explicitly and operationally defined as to structure, variables and relationships
2. Obviously valid and intuitive to all project stakeholders
3. Generally applicable throughout the project environment in a way that accounts for the
complexity and dynamics of the project process...
4. Validated empirically in the real project world
5. Simple, logical, understandable and flexible, yet comprehensive within practical limits of
number of hierarchical levels
6. Built on existing project management understanding generally
7. Expressed in familiar terms and phrases that facilitate both electronic and non-electronic
retrieval of project management relevant information.
8. Responsive to hierarchies, word sets, and cross-links, that apply to more than one branch of
the structure
9. Independent of any proprietary view of project management
10. And, last but not least, beneficial to its users.
The view selected for this PMKS was based on the premise that:
A commitment, in terms of scope, quality, time and cost, exists between the project group,
responsible for integration of objectives, teamwork, communication and effort, and the client or
sponsor, responsible for the vision, general direction, resources and project financing.
The reason for this perspective was that this appears to be the primary duty of project management.
Why should we care?
If we had a better understanding of the nature of project management we might be better able to:
· Establish a more universal terminology to facilitate communication around the world.
· Provide professional leaders with a better basis for discussion of issues and knowledge and
information exchange.
· Provide educators with a better framework for project management learning.
· Provide owners and sponsors with a better basis for project selection, initiation and direction
· Simplify an otherwise complex arrangement.
· Reduce the confusion between what is general management, what is project management and
what is technical management.
· Better understand where a general understanding of project management ends, the need for
instruction on specific application of project management starts and hence better understand
the needs of our ‘customers’.
· Understand differences in levels of project management complexity, technological
complexity, and consequent risk and success criteria.
· Convey to potential customers the merits and methodologies of project management for
purposes of maximizing new-product benefits.
· Answer more convincingly the question “why do so many projects fail?”
· Advance the project management profession technically, into more industries and
organizations, and into more geographic areas globally.
What is interesting is that after nearly thirty years of intensive study by members of the Project
Management Institute, practitioners, academics, authors, publishers, and paper and article writers around
the world, we still have more questions than answers! Why? Because of the increase of the application
of project management in more and more industries.
Following last year’s presentation and discussion, our original concept map can be improved. But the
real world deals in real projects, so how do we get from general principles to specific areas of project
management application? For example, where is the place for program management? By what criteria
should we include, exclude, or place specific labels? And so on.
However, before moving on, we should clarify what we mean by Areas of Project Management
The traditional way for segregating business activities is by industry, of which there are many. The
Project Management Institute, in its membership application form, lists seven categories and no less than
seventy-five sub-categories. Clearly, developing project management specifics for each and every
industry would be both unwarranted and futile.
The problem is that most of these industry categories could just as easily be involved in, say, a
construction project as a systems project. The observation that the Project Management Institute has
flourishing Specific Interest Groups supporting each type indicates that these are different kinds of
project that are not differentiated by industry.
To distinguish different types of project from different industries the term ‘Area of Project Management
Application’ has been used. Area of Project Application (or APMA) has been defined simply as
“The environment in which a project takes place, with its own particular nomenclature and
accepted practices” (PMBoK 1987.)
Each APMA tends to have its own necessary management style and competency requirements. But what
are the distinguishing features of projects in each area?
APMA Differentiation
We talk a lot about scope, quality, time and cost, teams, risk and so on. Recently we’ve begun to talk
more about ‘success factors’, but we talk very little about the work involved. Yet surely it is the process
of successfully conducting the work to produce a successful product that is the ultimate aim of the
project management process? So, for purposes of APMA differentiation, Shenhar and Wideman
established a simple basic premise:
“For the project to be successful, different types of project work, associated with different types
of product, need to be managed differently” (Shenhar 1997).
The distinguishing features of the work to produce the project’s product seem to be governed by craft
versus intellect (work), and tangible versus intangible (product). If the work under consideration
represents the primary purpose (or work package) of the project, then this 2x2 matrix results in four
basic types of project as follows.
a) Tangible-Craft - Projects whose products are tangible and the result of craft work. Example
– most construction. We might label this group Classical Construction Projects (CCP)
[Note: in Wideman’s set of Issues and Considerations, this group is referred to as ‘EngCon’.]
b) Intangible-Craft - Projects whose products are intangible and the result of craft work. The
main value of the product is intangible but the effort to accomplish it is effectively routine
‘craft’ work. Examples – maintenance shutdown, update of a procedure. We might label this
group Corporate Operational Projects (COP) [Admin]
c) Tangible-Intellect - Projects whose products are tangible and the result of intellect work. The
product is tangible but the main effort is intellectual. Examples - new invention, original art.
We might label this group Product Development Projects (PDP) [NewProd]
d) Intangible-Intellect - Projects whose products are intangible and the result of intellect work.
The main value of the product is in its intangible content and which is the result of intensive
intellectual work. Examples - new theory, new software, writing a book. We might label this
group Research, Development Projects (RDP) [NewTech]
While the distinctions are clear, the examples and labels suggested could be arguable and subject to
further examination of specific commonalities. It is interesting, however, that listed in this way from (a)
to (d), these APMAs appear to align with environments of increasing technological risk to cost and
schedule. That is, ranging from ‘well established and relatively certain’ to ‘new ground and very
uncertain’. Undoubtedly, different people’s experience in different APMA environments accounts for
much heated argument over what constitutes project management and what constitutes good practice.
Concept Map Update
Returning to our concept mapping exercise, the original 1997 concept map of project management
knowledge has been updated and is now split into two levels, see Exhibits 1 and 2.

At Level 1, the driver is the global competitive environment that we all now face, whether in
government, the private sector or in humble community volunteer work projects. The enterprise
environment recognizes the need for different types of project, i.e. different APMAs, which generally
determine the appropriate style of management. At the same time, uncertainty provides opportunity, as
well as risks, spawning a variety of programs and projects.
Programs determine policy direction, project priorities, resource allocation, and matrix management.
This is clearly distinguishable from project management which focuses on effectiveness and efficiency
in real time, the project life cycle.
At Level 2, the focus is on the management of a single project as shown in Exhibit 2.
From the two exhibits, it will be noted that the attributes (as indicated by ‘+’) can be transformed into
the PMDs of the next lower level. This is typical of concept mapping as you drill down into greater

Descriptor Criteria: Exclusion, inclusion and placement
We struggled considerably with the issue of project management descriptor (PMD) criteria for the
mapping exercise. It would be nice if every PMD slipped neatly into one and only one place. However,
the reality is that knowledge domains are not necessarily hierarchical as such, and may even contain sub
hierarchies, possibly based on modified criteria. Thus, assembling a tree structure, with which we, in
project management are so familiar, forces arbitrary choices which gives rise to the possibility that other
users will not know where to find things or even what to look for. This creates the need for flexibility,
and as a result we arrived at the following preliminary PMD placement criteria:
· Is the Descriptor commonly used, or is it required to describe attributes of other project
management descriptors, in program or project management or any one of the Areas of
Project Management Application (APMA)?
For example: (Project) ‘Cost Accounting’ is commonly used, and is therefore included as a
‘Project Management Descriptor’ (PMD), but ‘Financial Accounting’ is not and is not
included, though elements of financial accounting theory may be included to give meaning to
project cost accounting.
· Conversely, do not include the descriptor if it is primarily used in General Management or
Technical Management (i.e. the management of the technical work of the project’s product.)
For example: ‘Financial Auditing’ belongs to General Management, ‘Material Hoisting’
belongs to Construction, and ‘Prototyping’ belongs to technology management.
Note, however, that in the real world of project management, general, project and technical
management activities must all be closely integrated through the course of the project.
· Is the Descriptor commonly used in most APMAs? If so, include it in the upper (generic)
levels, otherwise include it within an APMA.
For example: ‘work breakdown structure’ is a common technique, but ‘Scheduling
Prototypes’ is not and belongs within an APMA (Information Technology.)
· What are the primary attributes of the PMD, and hence where is its best fit?
This is a judgement call and there may not be a unique location.
For example: ‘Earned Value’ is a PMD that is closely allied to ‘Cost’, Schedule’ and
‘Progress Reporting’. The solution is to enter it at the first level encountered and create
hyperlinks from other locations.
· Is the PMD capable of further breakdown or is it an ‘end-item’? If no further breakdown is
apparent, seek to place it at the lowest level of a branch, otherwise place it where it appears
to have the most affinity.
For example: ‘Bar Chart’, ‘Resource Histogram’ and ‘Network Diagram’ appear to be enditems,
whereas ‘Scheduling’ might be followed by ‘Activity Duration’, ‘Critical Activity’,
‘Dummy Activity’, ‘Float’, etc.
Where do APMAs fit in the Concept Map Structure?
Most experienced project people recognize the ‘fractal’ nature of project management. Like the shell of
the common snail, the cross section is similar wherever you section it – it is just a question of scale. This
is reflected in a number of project management ‘hierarchical word sets’ such as:
· The knowledge hierarchy: Profession – discipline – function – process - tools and
· The project road map (answers what?): Vision – mission – goals – objectives - action plans -
performance standards (Batten 1989)
· The approach (how?): Philosophy – organization – strategy – tactics – activity – control.
Perhaps the most obvious is the breakdown of the project life cycle (PLC). The PLC can be
progressively decomposed from:
· Abstract Principle: “Plan your work, work your plan” (i.e. first establish a period of planning
followed by a period of doing) subdivided through phases – stages – activities – tasks.
Each level can be ‘project managed’ using the same basic principles, the difference is simply in scale
and terminology. However, only the first two levels are common to most projects. Stages are typically
APMA specific (witness the variety of PLCs described in the Project Management Institute’s Guide to
the Project Management Body of Knowledge), while activities and tasks are very project specific
(Wideman 1991). What changes here is the level of detail, the focus, the personal goals, the consequent
conflicts, and resulting levels of stress.
From this it will be seen that while APMAs determine the nature of programs and projects (Concept
Map Level 1) the knowledge content of each specific APMA is probably realized at, say, level 3 (as
represented by the attributes shown on the Concept Map Level 2)
Another way of looking at it, if we make ‘Project’ as our top level for a moment, then universal project
management knowledge is probably limited even at this level and that APMA-specific knowledge is
necessary, or at least the way it is presented, for reasons described later.
The Project Management Institute’s Missing Opportunities?
As noted earlier, the Project Management Institute has published a Project Management Body of
Knowledge Guide that provides the basis for its professionalism programs (Duncan 1996). This guide
provides a framework and covers eleven ‘knowledge areas’, twelve if you include the introductory
chapter. Each knowledge area is presented as a process, the descriptions of which cover a number of
topics. The content is limited to knowledge and practice that is generally accepted and unique or nearly
unique to the field of project management. By design it is targeted at the management of a single project
(Duncan 1998). These knowledge areas are depicted as shown in Exhibit 3.

Notice the all-on-one-level relationship of these knowledge areas. This arrangement gives little
opportunity for the student of project management to digest and understand the relationships between
these various areas, although process diagrams are provided in the body of the text, some of which are
conceptually flawed.
However, the considerations and concepts discussed in this paper can be simplified into the more
familiar ‘tree’ structure shown in Exhibit 4. A comparison of Exhibits 3 and 4 shows how the discussion
of project management knowledge can be both simplified and expanded in its coverage.

Continued Development since 1998
Since the presentation of this paper in 1998 work on the PMKS has continued.
For example, if we take the upper part of the structure shown in Exhibit 4 we might label the levels
progressively from the top as Enterprise; Program; and Project as shown in Exhibit 5. Note that the
program level corresponds to the strategic focus of the organization, which determines the type of
project according to different Areas of Project Management Application (APMAs). The APMAs reflect
the ‘nature’ of the project environment and all that this entails (Shenhar 1997)
Exhibit 5 highlights the differences between the four major APMAs which determine the appropriate
style of management for the project to be successful in implementation. The APMA box also shows the
given name used in Wideman’s Issues and Considerations as a broad characterization of each
application area. The label ‘Universal’ provides the opportunity to categorize project management
knowledge, as distinct from program management knowledge, that appears to be universal across all
four APMAs.

Next, if we take the lower part of Exhibit 4, we can add appropriate labels from the project on down as
shown in Exhibit 6. Note that the seven subdivisions of the project-specific knowledge areas are
identified as Components at level 4 and that each of these have attributes as suggested at the Process
level 5. Note also that the attributes or subject matter shown in bold are those representing the
knowledge areas contained in the Project Management Institute’s Guide to the Project Management
Body of Knowledge.
We have suggested that much project management knowledge becomes customized at the project
application level. While most of the methodology, or processes at the function level, or tools and
techniques at the component level have universal application, nevertheless, their practical application
need to be ‘interpreted’ for each APMA by virtue of:
· The types of people, culture, attitudes and vocabulary involved
· The types of scope, quality, time frames and cost ranges encountered, and
· The types of information, communication, teamwork, skills and work effort required.

Validation of the Structure
Since the original presentation we have also attempted to validate the usefulness of the structure by
populating each APMA with Project Management Descriptors (PMDs) and further developing the
structure on down as seemed appropriate. This has been done using Abdomerovich’s 1800+ PMDs
(PMJ, March 1992, p42.) Trying to establish consistent placing of the PMDs on each branch has
necessarily tested the set of criteria described in the paper.
These criteria are not immediately self-evident and require some degree of subjectivity and consequently
the results are no doubt arguable. Nevertheless, this exercise has provided some comfort that the
structure is both workable and potentially useful. The result so far is that each APMA has up to ten
levels (starting at the project level) and their respective contents range between 900 and 1500 PMDs.
Of themselves, the PMDs are meaningless without definition. Therefore, a parallel effort was conducted
to develop a glossary of project management terms to complement this PMKS. This has resulted in the
now well-established Wideman Comparative Glossary of Common Project Management Terms which
you can find elsewhere on this site.
The approach adopted for the glossary was not to mandate specific definitional wording to any given
PMD (experience shows this to be a controversial and therefore fruitless exercise) but rather to assemble
several ‘typical’ definitions of each where needed or as encountered in the marketplace. From these, the
‘best fit’ may be selected by the users of the structure.
Further Opportunities
We are now in a position to identify opportunities for further work. For example:
· Have knowledgeable people experienced in each application area critique each structure.
· Review more recent PM literature for additional descriptors to test the structure’s flexibility
· Continue development of the Glossary and possibly segregate it into the four different APMAs
· Attract interest in this PMKS device for testing in a practical application.
In the course of this extensive work we have been plagued by the question “Why should anyone use this
(type of) structure rather than any other?”
We believe that the answer to this question may lie in Miller’s classic psychology paper “The Magical
Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information” (George
A. Miller, 1956, Harvard University – first published in Psychology Review, 63, 81-97. Also on
Internet: http://www.yorku.ca/dept/psych/classics/Miller/)
Without any preconceived limitations, our original concept mapping exercises arrived at branches
generally within this range. This quality alone should make the structure more amenable to acceptance
as a vehicle for both universal and specific application area learning and project management
Conclusions – the Global Opportunity
There is a need, and hence an opportunity, to provide a more comprehensive and open structure to the
project management body of knowledge. Such a structure could better enable knowledge and
information exchange, a better framework for project management learning, greater clarity of a complex
subject, better differentiation between general, technical and project management, and a ‘more friendly’
understanding of project management ‘customer’ needs. Confusion reigns because of differences in
terminology, management approaches and success identification, so that even a more universal general
terminology would greatly facilitate project management communication around the world.
Probably most of the topics displayed in Exhibit 4 are covered by existing literature. However, the chart
serves to put the whole into context and, through a more structured approach, suggests areas ripe for
further research. What is needed in the real and competitive world of project management is more focus
on its distinct areas of application and corresponding competency. We already know that many
organizations, at least in the United States accept the Project Management Institute’s Project
Management Professional designation as a basic knowledge level and then ‘customize’ the rest to suit
their own requirements based on experience. How much more influential we might be if we had a basis
for capturing and differentiating this experience — and making it more universally available and useful.
Clearly, some structure and delineation would be beneficial, if only to unify and advance project
management understanding across global cultural interests. Would we not be more effective if we could
at least agree on a more comprehensive glossary of terms including governing word sets? At the same
time, I am convinced that we need to pursue a more structured approach if we are to break out of the
simplistic generic mode and get serious about professionalism, professional qualifications and
meaningful competence. We simply must be more resolute over service to the general public, employer
acceptance, professional differentiation and recognition of highly qualified and experienced project
management practitioners in their respective Areas of Project Management Application.
But perhaps most important of all, by establishing some form of flexible structure we can better
facilitate continuous learning and ensure knowledge continuity well into the future.
Therefore, I hope that this paper will generate much further discussion on this topic.