10/29/98 / 1

Defining PM Knowledge
as a Basis for Global Communication,
Learning and Professionalism

R. Max Wideman, FPMI, AEW Services, Vancouver, BC, Canada
(Minor revisions and footnote added, 10/29/98)


"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:

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, CD-ROMS, and videos on project management, projects, and "how-to-do-it". Yet there are still areas we have barely begun to tap such as "program management", with its focus on supporting corporate policy rather than individual project goals.

How does it 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.


This author reviewed some historic attempts to structure knowledge in general, and PMI's Project Management Body of Knowledge (PMBoK) 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 repeating. 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 and understandable, but comprehensive and flexible

  6. within practical limits of number of hierarchical levels

  7. built on existing PM understanding generally

  8. expressed in familiar terms and phrases that facilitate both electronic and non-electronic retrieval of PM-relevant information.

  9. responsive to hierarchies, word sets, and cross-links, that apply to more than one branch of the structure

  10. independent of any proprietary view of PM.

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 team (responsible for integration of objectives, teamwork, communication and effort) and the `client' (responsible for the vision, general direction, resources and project financing.") The reason for this selection was that it appeared to be the most fundamental to project management.

Why should we care?

If we had a better understanding of the nature of project management we might be better able to:

What is interesting is that after nearly thirty years of intensive study by members of PMI, practitioners, academics, authors, publishers, and papers and article writers around the world, we still have more questions than answers! Why? Because the application of project management in more industries is increasing so rapidly.


Following last year's presentation and discussion, our original concept map can be improved. For example, where is the place for `program management'? By what criteria should we exclude, include and place specific labels? The real world deals in real projects: How do we get from general principles to specific project management application?

Concept Map Update

The original concept map of project management knowledge is now split into two levels, see Exhibit 1.

[Following factors shown in a diagram.]

Global competitive environment
Enterprise environment
Uncertainty, risks
Area of PM Application: Programs, Projects

Exhibit 1. Concept Map: Project Management Knowledge - Level 1

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. Uncertainty is increased and the impact is felt on specific Areas of Project Management Application (APMA). This enables a variety of different types of project Programs that in turn determine project priorities, while the APMA determines the appropriate style of management.

Program management, with its focus on policy direction, resource allocation, priorities and matrix management, is clearly placed -- and is distinguished from project management which focuses on effectiveness and efficiency in real time (the project life cycle). At Level 2, the focus is again on the management of a single project, see Exhibit 2.

[Following factors shown in a diagram.]

Project commitment
Client environment
Project integration
Uncertainty, risks
Management processes
Real time life cycle

Exhibit 2. Concept Map: Project Management Knowledge - Level 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 detail.

Descriptor Criteria: Exclusion, inclusion and placement

We struggled considerably with the issue of concept map PMD criteria. 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 create the side effect that other users do not know where to find things. This creates the need for flexibility, and as a result we arrived at the following preliminary PMD placement criteria.

  1. 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.

  2. 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.

  3. 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.)

  4. 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.

  5. 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 end-items, whereas "Scheduling" might be followed by "Activity Duration", "Critical Activity", "Dummy Activity", "Float", etc.

Area of Project Management Application

The traditional way of segregating business activities is by industry, of which there are many. PMI, 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 PMI 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?

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 exercise?

For purposes of this 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.

  1. Tangible-Craft

    Projects whose products are tangible and the result of craftwork. Example - most construction. We might label this group Classical Construction Projects (CCP)

  2. Intangible-Craft

    Projects whose products are intangible and the result of craftwork. 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)

  3. 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)

  4. 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)

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 is project management and how to do it.

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 techniques; 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 ("first plan then accomplish") through phases, stages, activities and tasks. Each level can be "project managed" using the same basic principles, the difference is simply in scale and nomenclature. However, only the first two levels are common to most projects. Stages are typically APMA specific (witness the variety of PLCs described in the PMBoK Guide), 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 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 PM knowledge is probably "generic" only at the System and Component levels (L2 & 3). Therefore, APMA-specific knowledge is necessary at the Detail level (L4) since it involves specific types of people, scope, information and so on.

PMI's Missing Opportunity?

PMI has published a PMBoK guide that provides the basis for its professionalism programs (Duncan 1996). This guide provides a framework and covers nine "knowledge areas" that may be depicted as shown in Exhibit 3.

[Following factors shown in a diagram.]

Project Management
Human Resources

Exhibit 3. The Current PMI PMBoK

Each knowledge area is presented as processes, 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)

The considerations and concepts discussed in this paper can be simplified into the more familiar "tree" structure shown in Exhibit 4 In the lower part of the exhibit are shown seven concept areas each encompassing a number of attributes or topics. The topics shown in bold are those representing the Knowledge Areas contained in the PMBoK Guide. A comparison of Exhibits 3 and 4 is intended to convey the opportunities open to us if we will take a more holistic view of the field of 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.

[Following factors shown in a diagram.]

Global competitive environment
Enterprise Management Environment
Programs - Operations
Area of PM Application: Programs, Projects
CCP..... COP..... PDP..... RDP
Project #1......... #2..........#3........, etc.
Client Environment
Integration of Activities
Uncertainty, Opportunity and Risk
Management Processes
Real Time (Life Cycle Responses)

Exhibit 4. Project Management in the Real 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 accept the PMP as a foundation and then "customize" 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 in the market place. 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.


Batten, J. D. 1989. (Adapted from)Tough-minded Leadership. AMACOM, NY: 36.

Duncan, W. R. 1996. A Guide to the Project Management Body of Knowledge. Standards Committee. Upper Darby, PA: Project Management Institute.

Duncan, W. R. 1998. In an Email dated 3/31/98 to public forum pmilist@list.4.com.

PMBoK 1987. The Project Management Body of Knowledge of the Project Management Institute: Glossary of Terms.

Ross, R. 1994. The Fifth Discipline Fieldbook. Doubleday, NY. 242.

Shenhar, A. J. and R. M. Wideman. 1997. Toward a Fundamental Differentiation between Projects. PICMET '97. Innovation in Technology Management. 397 (Full paper on CD-ROM)

Wideman, R. M. 1991. A Framework for Project and Program Management Integration. Upper Darby, PA: Project Management Institute: III-1.

Wideman, R. M. 1997. A Project Management Knowledge Structure for the Next Century. PMI 1997 Seminar & Symposium Proceedings: 1006-1011. (An updated version of the paper is available at web site www.pmforum.org/docs/pmks4y2k.pdf)

Footnote (added 10/29/98)

Since submitting this paper for the Project Management Institute's 1998 Annual Seminar/Symposium in Long Beach, California, 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 Business; Program; Application Area and Project as shown in Exhibit 5. Note that the Application Area corresponds to the strategic focus of the organization and this sets the "nature" of the project `environment' and all that this entails, including Tactical Objectives (rather than the other way round.) The Exhibit also highlights the differences between the four major Application Areas which determine the most appropriate style of management for the project to be successful in implementation. (Shenhar 1997)

Next, if we take the lower part of Exhibit 4, we can see appropriate labels from the project on down as shown in Exhibit 6. This Exhibit suggests that project management application becomes specific at the Detail Level where the "types" of resources, objectives and processes are being considered.

[Following factors shown in a diagram.]


Global competitive environment


Enterprise Management Environment

(Strategic Goals)

Programs - Operations

Application Area

Area of PM Application: Programs, Projects
CCP..... COP..... PDP..... RDP

Project Area

Project #1......... #2..........#3........, etc.

Note the increasing technical Risk/Opportunity

APMAs represent different "flavors" of project management

Classic Construction Projects (CCP) involve a Tangible Product & Craft Work (TC)

Corporate Operational Projects (COP involve Intangible Product & Craft Work (IC)

Product Development Projects (PDP) involve Tangible Product & Intellect Work (TI)

Research & Development Prjs (RDP) involve Intangible Product & Intellect Work (II)

Exhibit 5. Labeling the project environment

Since the submission of the paper we have also attempted to validate the usefulness of the structure by populating each Area of Project Management Application (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 attempt is being made to develop a Glossary of Project Management Terminology to complement the PMKS. The approach here is not to mandate specific definitional wording to any given PMD (experience shows this to be a fruitless exercise) but rather to assemble several "typical" definitions of each where necessary, as encountered in the marketplace. From these, the "best fit" may be selected by the users.

We are now in a position to identify opportunities for further work. For example:

[Following factors shown in a diagram.]


Project (L1)

Project #1......... #2..........#3........, etc.

System (L2)

Client Environment
Integration of Activities
Uncertainty, Opportunity and Risk
Management Processes
Real Time (Life Cycle Responses)

Component (L3)




Etc., etc., etc.

Down to this level, including a broad outline description of each component, is probably generally applicable across all projects, i.e. "generic" information.

Detail below this level is most likely specific to the Area of Project Management Application (APMA) and its environment, e.g.

Detail (L4)

Types of people, culture, attitudes, vocabulary Types of scope, quality, time frames, cost ranges Types of information, communication, teamwork, skills, work effort, etc.

Exhibit 6. Labeling the project content.

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 attribute alone should make the structure more amenable to acceptance as a vehicle for both generic and specific application area learning and project management professionalism.

R. Max Wideman, October 1998.
Email: max_wideman@sfu.ca

AEW Services, Vancouver, BC, c October 1998