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:
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.
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.
Exhibit 1. Concept Map: Project Management Knowledge - Level 1
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.
Exhibit 2. Concept Map: Project Management Knowledge - Level 2
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.
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.
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.
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.
Projects whose products are tangible and the result of craftwork. Example - most construction. We might label this group Classical Construction Projects (CCP)
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)
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)
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.
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.
Exhibit 3. The Current PMI PMBoK
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.
Exhibit 4. Project Management in the Real World
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)
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.
Levels
Global competitive environment
Business
Competitors
Enterprise Management Environment
Program
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
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:
Levels
Project (L1)
Project #1......... #2..........#3........, etc.
System (L2)
Client Environment
Commitment
Integration of Activities
Uncertainty, Opportunity and Risk
Management Processes
Real Time (Life Cycle Responses)
Success
Component (L3)
People
Scope
Quality
Time
Cost
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 (L4)
Exhibit 6. Labeling the project content.
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