Pm的知识架构

A Project Management Knowledge Structure for the 21st Century
R. Max Wideman
(Revision 11, Oct-06-98)

The original version of this paper was presented at the Project Management Institute’s
28th Annual Seminar & Symposium, Chicago, Illinois, September 29, 1997.

Introduction

This paper is a ‘discussion’ paper rather than a ‘solution’ paper and describes the possibilities for a
structured arrangement of the elements of a body of knowledge for project management. The purpose of
such a structured arrangement would be to provide the basis for a more systematic discussion of project
management issues. Such issues include the impact on project management practice as a professional
discipline in various parts of the world and on different types of project by virtue of the diversity of their
cultural norms and values.

Clearly, any proposed knowledge structure must be responsive to the working realities of project
management practitioners. So, to capture the types of issues involved, and to do it in an organized way,
we needed a checklist as a reference baseline. This checklist must not only cover ‘theoretical or generic’
project management but also the various practical areas of project management application (APMA).

Only then can a systematic development be conducted and assembled into a logical grouping of
elements. These elements of knowledge will initially be represented by a list of discrete project
management terms which can then be assembled into a proposed structure. We will refer to this as a
‘Project Management Knowledge Structure’ (PMKS), and the terms it contains we can refer to as
Project Management Knowledge Descriptors (PMKDs).

[Editor’s note: This paper generated useful exchanges and helped pave the way for global discussion of
project management knowledge.]

We are not alone in this endeavor

We have identified one particular reason for developing a PMKS, but are there others? After all, the
journey could be long and fraught with obstacles. So, is there any other potential for a PMKS, other
needs and opportunities? The history of analogous attempts is worth recounting briefly.

As early as 1668, the English philosopher John Wilkins presented a universal classification scheme to
London’s Royal Society. His scheme neatly divided all of reality into forty root categories, including
things; called ‘transcendental’, ‘discourse’ and ‘beasts’. The knowledge classification dream continued
and peaked in popularity during the 18th century but, today, Wilkin’s system is remembered only as an
example of the arbitrariness of attempts to classify knowledge. Still, some attempts have continued even
in this century. The Project Management Institute’s 1987 Project Management Body of Knowledge1 was
an attempt to capture a specialized area of knowledge in a similar way.

Just recently, however, the long moribund fields of knowledge organization have re-emerged. The
reason, of course, is the Internet Web—that mass of distributed and disparate information which is such
AEW Services, Vancouver, BC, © September 2000 Email: max_wideman@sfu.ca

A PMKS for the 21st Century Page 2

a powerful information source, if only we know what to look for and how to find it. And let us not
underestimate its value. It is claimed that by the end of 1998, the Web could contain more words than
the whole of the Library of Congress!

Some recent attempts to organize that information are startling reminiscent of John Wilkin’s attempts
more than three hundred years ago. But there is a difference. The most popular sites on the Web today
are those — like the Yahoo! 2 or AltaVista3 search engine sites — that attempt to exert some kind of
order on this otherwise anarchic collection of information. These powerful search engines provide the
tools to extract long lists of data sources, but these lists are often so overwhelming that we are little
further ahead, unless we can narrow the search by specifying several related topics as constraints.
Interestingly, after producing the results of its search, AltaVista provides access to a context-sensitive
thesaurus-like hierarchy of words that can be included or excluded to further refine the search.

Suddenly, the hard problems of knowledge classification and indexing are of commercial importance!
So, perhaps the most important opportunity for a PMKS is to facilitate rapid identification of needed
information. A consistent grouping of subject matter would also be helpful to practitioners and educators
alike for practice, training, education and research. It could be very helpful in conveying an integrated
understanding of PM. Even identifying a realistic scope of project management for professional
purposes would be a significant step forward.

But on what basis?

The most obvious place to turn, library science, turns out to be of almost no help. Even librarians admit
that the schemes used to day are antiquated and inadequate. The most common systems in the US, the
Dewey Decimal System, and Library of Congress Classification, were developed during the close of the
19th century. Unsurprisingly, they are poor at classifying ‘newly’ established fields such as project
management. If you want confirmation, just check out project management as a subject area!

Moreover, while a physical book or document can be shelved in only one place, a digital document can
be placed in several categories at the cost of only a few bytes. The field of information retrieval, which
focuses on automated techniques like keyword indexing for searching large data bases, isn’t much more
encouraging. The reason is simple. If humans have a hard time figuring out some system, trying to get a
computer to do it is nearly impossible.

There are still other issues. For example, what should be included? Presumably, specific management
practices relating to the primary production work effort of particular areas of project management
application. For example, presumably information technology, software development, or construction,
each with its own particular regulatory requirements or legal restraints, techniques and vocabulary,
should be included. A basis for distinguishing between APMA groupings, by the way, has been
described in a recent paper ‘Toward a Fundamental Differentiation between Projects’4 How much
knowledge contained in related general management professions such as financial management,
accounting, ethics and law, should be included or excluded? How should the information be presented
and in what order?

We need guidance.

AEW Services, Vancouver, BC, © October 1998 Email: max_wideman@sfu.ca


Models to the rescue

Pictorial models help us understand complex relationships. They can broaden and clarify our
perspectives by helping us to see the big picture, help to avoid confusion by explaining how things
work, and express rules more simply by clarifying relationships. Who, for instance, would be able to
grasp the complexities of nature’s DNA structure without the colored 3-D graphics we see on TV?

Project management is also a complex structure and there have been a number of attempts to capture it
through models. Some examples include the early ‘Schedule-Cost-Performance’ model, the ‘Scope of
Project Management’ model, the ‘Matrix Model’, the 1987 PMBoK ‘Star’ model, or the ‘3-D Integrative
(toolbox) Model5. However, few of these seem to capture the totality of project management.

One of the most recent models has been developed by Forsberg, Mooz and Cotterham 6. Their model
depicts a wheel made up of nine management elements or spokes, held together by a tenth element
which forms its rim. This wheel progresses along a three-stranded axle representing the product’s life
cycle. The model is somewhat complex and therefore unsuited to our purpose, but it is important for
several reasons.

In addition to the usual topics of teamwork, project life cycle and the elements of management control,
Forsberg et al first emphasize the importance of communicating through a common vocabulary for each
project — even small ones. They also differentiate between ‘technical’ management and ‘project’
management. Most crucial, they separate the ‘perpetual’ aspects of the project life cycle, imposed by the
project environment, the ‘sequence-driven’ aspect imposed by logical performance, and the ‘situation-
driven’ aspect, imposed by managing7. These are all facets of project management that are commonly
overlooked.

For example, Project Management Institute’s current Guide to the Project Management Body of
Knowledge takes a systems input-process-output view of project management and is replete with
diagrammatic models. Unfortunately, in this author’s view, the most important project management
model, ‘Links Among Process Groups...’8 is badly flawed. It, and subsequent diagrams, confuse a major
management situational process with several sequential processes and show misleading relationships.

In a thoughtful 1992 Project Management Journal paper on project management descriptors,
Abdomerovic observed that “Information today is produced in such quantities that our efforts may be
repeatedly wasted simply because it is not possible to determine what work has already been done or, at
a minimum, we spend more time looking for documents than looking at them.”9

His paper describes research on some 2000 titles from which he abstracted more than 1800 descriptors
and shows how they might be organized into a structured hierarchy. The structure has two difficulties.
The normal hierarchy gives no indication of what rules are being applied in, or relationships implied by,
entering a descriptor at any given location. Also, his hierarchy has up to eighteen levels, rather more
than is practical. Nevertheless, his paper does provide a valuable resource for our project.



Concept Mapping, the preferred choice

Hitherto an area of interest only to Cognitive Science, Artificial Intelligence and Educational
Technology, ‘concept mapping’ is now considered by researchers and educationalists to be an excellent
way of capturing a knowledge area. It is becoming increasingly popular and is used, for example, by
systems analysts to obtain an understanding of systems planned for automating or upgrading. The
approach forces discovery of basic conceptual units and their relationships, typically in a brain-storming
wall-board session.

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 appropriate nodes and describe the nature of each relationship, as shown in the
Simple Concept Map, Exhibit 1. Since the most important single factor influencing learning is what the
learner already knows, concept mapping provides a way for people to consciously and explicitly tie new
knowledge to relevant knowledge they already possess. A big advantage of the Concept Map is that it
provides a visual image of the components and their relationships so that it can be studied very easily.

Steps to constructing a concept map involve

1. Select: Focus on a theme and then identify related key words or phrases as labels
2. Rank: Rank the labels from the most abstract and inclusive to the most concrete and specific
3. Cluster: Cluster labels that function at similar levels of abstraction and those that interrelate
closely
4. Arrange: Arrange labels into a diagrammatic representation
5. Attribute: Add attributes to each label if/as appropriate
6. Link and describe relationship: Connect the labels with linking lines and name each link-line with a
relationship description.

Exhibit 1. Simple Concept Map

The labels selected may in fact be concepts, ideas, entities or things. Their attributes are often simply
sub-category labels. Typical relationships include one or more of the following: Has part(s):
Implements; Has Goal(s); Uses; Satisfies; Has Output(s); Has Example(s); or Relates to (undefined
generic relationship). A subtlety of the approach is that any attribute or relationship might be converted



into an entity if its content is to be further elaborated, or vice versa. Concept maps can get very
complicated depending on the number, type and level of detail of the relationships exposed.

However, graphical software is now available that greatly facilitates electronic concept mapping. One
example is SemNet, short for Semantic Networks, presently under development10. This innovative
software for the Mac works like a word processor, but can be used to portray any descriptive domain of
knowledge. SemNet is a hypertext environment in which ideas and concepts on any subject can be
organized into a network of descriptors linked by named relationships. The nets can be elaborated with
objects like charts, pictures, sounds, multimedia and web documents, and can even be merged together.

One of many other software products for the PC-Windows environment and serving similar purposes is
Visio11. Visio uses the metaphor of drafting templates from amongst several of which appropriate
symbols can be ‘drag and dropped’ anywhere on a past-up board. Its power is in the automatic attached
arrow links that can be created as relationships, complete with descriptive text automatically displayed
in the shaft of the arrow.

So now we have the tools available, but even so, the ‘maps’ thus developed, represent only the view of
the knowledge area according to the perspective selected.

Believe it or not, it turns out that representation of the concept map found most useful for teaching and
learning is one with which project management people are most familiar. That is, a typical ‘organization
chart’ that has the more general and inclusive concepts at the top and the more detailed ones at the
bottom. However, the boxes need elaborating with their attributes and the links must be annotated to
show the specific relationships.

For purposes of hardcopy distribution or keyword searches, this chart can be reduced to an ‘outline
form’ by

• Tabbing in for each level of label (as is usual)
• Adding the relationship description in brackets to the end of each label for both ‘peer’ and ‘child’
relationships
• Repeating the label if it has a cross-reference relationship, i.e. a relationship to another part of the
structure (in lieu of a ‘hypertext’ link)
• Including any attributes of the label in the next lower level of the hierarchy, generally when it forms
the lowest level of that particular branch.

So now we have the principles of our PMKS, and the labels are the PMKDs.

PMKS theme, view or project goal

From the discussion of project management models described earlier, project management is obviously
complex. We are in the same position as the proverbial elephant and the two blind men. The one feeling
the tail concludes that it is like a rope, while the one feeling the trunk concludes that it is like a snake.
Whereas we all know that it is really a huge oval supported on four pillars (scope, quality, time and
cost?)—with a variety of exotic attachments!



Project management is an overhead and its only justification is to ensure optimum success in both the
process and output, but particularly the output, compared to what might otherwise occur. So, let us
accept the proposition that “A successful future depends on successful projects”12, and that this goes for
both enterprises and individuals. So what view of project management should we take in constructing
our PMKS? Based on the issues described earlier, we might well respond to questions like:

• What primary elements of project management should enterprises recognize and refine to make their
projects more successful?
• Or, given PMI’s existing project management concepts as a baseline, what are the new primary
elements that we in PMI should now articulate to our sponsoring enterprises to enable more successful
projects?
• Or, more simply, what view of project management must we convey to be successful into the next
century?

No matter the exact wording, the result should be roughly the same. So, where do we start? Successful
project management teaches us that we should first be clear on our objectives, and then state our
assumptions. After that, the starting point for developing a new PMKS concept model must be the most
fundamental things we know about project management.

Objectives for structuring a PMKS

For our PMKS objectives we may again borrow from Forsberg’s observations on the essentials of a
project management model13. That is, to create a PMKS that:

1. Is explicitly and operationally defined as to structure, variables and relationships
2. Is obviously valid and intuitive to all project stakeholders
3. Is generally applicable throughout the project environment in a way that accounts for the complexity
and dynamics of the project process...
4. Is validated empirically in the real project world

To this we might add the following practical considerations:

5. Is simple, logical and understandable, but comprehensive and flexible
6. Keeps the number of hierarchical levels within practical limits
7. Builds on existing project management understanding
8. Uses familiar terms and phrases that facilitate both electronic and non-electronic retrieval of
information relevant to project management.
9. Identifies and cross-links to hierarchies and word sets that apply to more than one branch of the
structure
10. Does not impose any proprietary view of project management.

With reference to item 9, the cross-linking suggested would highlight both overlaps between areas of
project management application and the ‘fractal’ nature of project management. A ‘fractal’, by the way,
is defined as a geometric shape having the property that each smaller portion of it can be viewed as a
reduced scale replica of the whole — a common feature of the project management process.



If we can meet these lofty objectives, then perhaps we might arrive at a useful and near-universally
accepted structure.

Assumptions

We are assuming that the PMKS will be used to

• Assemble knowledge and experience that is encompassed by project management and clarify what is
excluded
• Provide a basis for comparing features and practices in different environments, cultures and areas of
application
• Run electronic and non-electronic information searches based on the contained PMKDs
• Establish a reference baseline and checklists for the benefit of academics and practitioners alike in
their education, training and application endeavors

Included in our assumptions should be the founding definitions of the PMKS model. Given our goal,
these would be the definitions we adopt for the terms ‘project management’, ‘project’, ‘management’
and ‘success’. The more convincing and focused we can make these definitions, the more likely we are
to succeed in achieving collective buy-in of the structure. Given the stated objectives, we propose the
following. Note, however, it is not so much the exact wording but the content that is important.

• Project Management: The art and science of managing a project from inception to closure as
evidenced by successful product delivery and transfer.
• Project: A unique process or undertaking designed to create a new product or service.
• Management: The act of planning, organizing, coordinating, commanding, and controlling14.
• Success (project success): The perception of satisfaction on the part of the customers, i.e. those who
will use the product, firstly with the resulting product or service, and secondly with the process that
achieved it.

Criteria for exclusion

The criteria for forming the structure of the PMKS has already been identified in the section “Concept
Mapping, the preferred choice” discussed earlier. Criteria for content has been established by our
Objectives and Assumptions. However, knowing what to exclude is just as important, because project
management tends to draw from, or trespass upon, a number of established management areas. We don’t
want to find ourselves including the whole world!

The boundary between project management knowledge, information or experience, and general
management disciplines is bound to be a fuzzy line resulting from different perceptions and usage. It
may also vary with the complexity and technology of the project. In principle, however, the essential
guidelines are that:

• The PMKS excludes most areas of general and technical management, such as accounting, law,
personnel administration, and the theoretical basis for the technology vested in a project and its
associated disciplines, which are not directly involved in managing the project.



• The PMKS therefore does include sufficient reference to relevant material in other management and
technology disciplines to enable the project management practitioner to be effective in understanding
and appreciating project requirements and technical management issues.

[Note: This is not to suggest that managing the technology of the project is not important. Indeed, the
work of technology management must be closely integrated with that of project management.]

For example, an understanding of the part of accounting which deals with the collection, identification
and allocation of actual costs is vital knowledge for the project management practitioner.

The starting point

Following the Concept Mapping methodology described earlier, what are the most inclusive things that
we know about project management? Perhaps the most fundamental is that a project represents a
commitment between the project’s management and its client or sponsor.

In a concept mapping exercise, a concept map emerged as shown in Exhibit 2.

Note that in this exhibit, the various relationships are attached to the corresponding linking arrows. The
upper line of each relationship description represents the relationship flowing from left to right or from
the top downwards. The lower line describes the relationship flowing in the opposite direction.

It should also be observed that the flow of all the relationships shown are enabled by communication,
and hence communication is inherent in the total concept map.

The fundamental topics of Project Management and their relationships were described as follows:

• Universal Practice. An overriding body of common practices has been identified as appropriate for
most projects.
• Area of Application. The dominant technology involved in the project has a major influence on how
it should be managed.
• Client Environment. This determines how projects are generated and has a major influence on how
they are structured.
• Commitment. A project represents a commitment to scope, quality, time and cost between the
project’s management and its client or sponsor.
• Project Integration. A project is a short-lived arrangement of people integrated for the purpose.
• Uncertainty. This provides both opportunity for the client and risks to the project.
• Management Processes. These are the major project contribution and responsibility.
• Real Time (Life Cycle). Perpetual, Sequential and Situational aspects play a major role in successful
project completion.
• Success. The ultimate objective of project management is success in all its aspects.



Exhibit 2. Concept Map of Project Management
when viewed as a knowledge structure

Note that commitment to scope, quality, time and cost is the dominant theme of communication across
the client/project boundary. It is worth repeating that of all of the relationship, this commitment is
perhaps the most central to successful project management.

This project management concept map is developed as a PMKS outline in Appendices A and B. See
Appendix A for Universal Project Management Practice, and Appendix B for Areas of Project
Management Application. These appendices include several further levels of detail.

Conclusions

In this paper we have provided background and rational basis for using concept mapping methodology
to develop a project management knowledge structure (PMKS). We have shown how concept mapping
rules can be used to develop an orderly arrangement and touch on software that can help in the process.
We have also shown how it would consist of an orderly arrangement of project management knowledge
descriptors (PMKDs) which could greatly facilitate research, learning and the practice of project
management. While the graphic representation of the PMKS is more useful in conveying a mental
image, it can, nevertheless, be represented by an outline structure.


We have proposed goals and objectives for the structure, the assumptions we have used, and suggest
criteria for content that should be either included and excluded. Finally, we have attempted to identify
the overarching concepts that encompass project management as the basis of our specific structure.
From these ground rules we have laid out a concept map of project management, and developed the first
few levels of the structure as a trial. This structure reflects a first level division between Universal
PMKDs of relevance to most projects and those relevant to specific Areas of Project Management
Application (APMA). Universal is then subdivided into seven major entities, while APMA is subdivided
into four classes of product effort that distinguish the ways in which such projects should be managed.

We hope that this paper will engender considerable discussion and progress on the vital issues of scope,
storage and efficient retrieval of project management knowledge. Hopefully, it will also attract the
participation and contribution of representatives from other interested countries.

R. Max Wideman
FICE, FEIC, FCSCE, FPMI

References

1
Wideman, R. M., developer of the Project Management Body of Knowledge of the Project Management
Institute, approved March 1987.
2
Internet URL - http://www.yahoo.com
3
Internet URL - http://www.altavista.com
4
Shenhar, A. J., R. M. Wideman, Toward a Fundamental Differentiation between Projects, PICMET '97
Conference Proceedings, Management of Engineering and Technology Dept., Portland State University,
Portland, Oregon, 1997, p391.
5
Wideman, R. M., A Framework for Project and Program Management, Project Management Institute, PA,
1991, Appendix A: A Historical Perspective.
6
Forsberg, K., H. Mooz & H. Cotterham, Visualizing Project Management, John Wiley & Sons, NY, 1996.
7
Ibid., p22.
8
Duncan, W. R., A Guide to the Project Management Body of Knowledge, PMI, PA, 1996, p28.
9
Abdomerovic, M., Project Management Descriptors, Project Management Journal, PMI, PA, 1992, p42.
10
SemNet Research Group, San Diego State University, 1991
11
Visio Corporation (1990), Internet URL - http://www.visio.com
12
Forsberg, K., H. Mooz & H. Cotterham, Visualizing Project Management, John Wiley & Sons, NY, 1996, p xvii.
13
Ibid., p18.
14
Fayol, H., General and Industrial Management, IEEE Press, NY, Rev. ed. 1984.



Appendix A

Knowledge Structure - Universal Project Management Practice

Note: Existing PMI PMBoK "Managements" are shown starred thus **.

UNIVERSAL PRACTICE [Peer: Provides concepts to Client Environment; Provides practices to
project Integration] & [Has as primary concepts...]

Client Environment [Peer: Determines Area of project management Application; Communicates
requirements as Commitment; includes Uncertainty; Has perpetual impact on Real Time; Has goals
for success] & [Consists of...]

Culture, attitudes, and other limitations of the type of sponsoring organization, location
and country

Vision, business, economics

Impacts and limitations of the technology or technologies vested in the project

Activity-specific vocabulary

Commitment [Peer: Impacts Client Environment; Responds to Uncertainty; Applies to
Management Processes; Imposes constraints on Project Integration] & [Consists of four interactive
variables...]

Project Scope Management** [Peer: Ties to Quality; Time; Cost] & [Has outputs...]

Definition of the project’s products

Changes to the definitions of the project’s products

Project Quality Management** [Peer: Ties to Scope; Time; Cost] & [Has outputs...]

Definition of the Quality ‘Grade‘ of the project’s products, and changes thereto

Conforming to requirements

Project Time Management** [Peer: Ties to Scope; Quality; Cost] & [Has outputs...]

Schedules, milestones, forecasting time to completion, delivery date

Project Cost Management** [Peer: Ties to Scope; Quality; Time] & [Has outputs...]



Estimating, budgeting, cost containment, final cost forecasting, Earned Value, Life-cycle
Costing

Project Integration [Peer: Matches Area of Application; Reports progress as Commitment; Affects
Management Processes; Has management impact on Real Time; Impacts on Success] & [Has
subparts...]

Human Resource Management** [Peer: Ties to Work; Comms; Info] & [Has outputs...]

Temporary team work, e.g. assembling people, team building, motivating, developing
ownership, negotiating, empowering the people responsible for component parts,
resolving conflicts, disbanding team upon completion

Managing the work of the project [Peer: Ties to H/R; Comms; Info] & [Has outputs...]

Assembling material resources, facilitating production, productivity, assuring correct
interfacing (i.e. Scope of Work), method study

Communication Management** [Peer: Ties to H/R; Work; Info] & [Has outputs...]

Listening, directing, reporting, messaging, personal intercommunication, conducting
meetings, fellowship, public relations, disclosure, accord

Information management [Peer: Ties to H/R; Work; Comms] & [Has outputs...]

Data collection, distribution, visibility, storage, and retrieval

Uncertainty [Peer: Creates opportunity for Client Environment; Is perpetual in Real Time; Creates
risk to Commitment] & [Has sub-parts...]

Opportunity Management [Peer: Is reciprocal of Risk] & [Has outputs...]

Market watch, needs analysis, public surveys, creativity

Risk Management** [Peer: Is reciprocal of Opportunity] & [Has outputs...]

Risk identification, assessment, mitigation, response plan

Management Processes [Peer: Applies to Commitment; Impacts Real Time; Uses Project
Integration] & [Has sub-parts...]

Overviewing and ‘Strategizing the project [Has outputs...]

Visioning, developing goals and objectives, identifying a compelling reason, leading,
optimizing project effectiveness and efficiency, performance standards



Procurement Management** [Has outputs...]

External resourcing (Formal, legal contracting)

Internal resourcing (Negotiating internal resource commitments)

Control management [Has outputs...]

Planning, organizing, directing, coordinating, monitoring, analyzing, estimating and
forecasting future states up to the conclusion of the project, corrective action, leading and
supervising

Other techniques and tools

Computer modeling, replacement theory, systems analysis, value management

Real Time (Life Cycle) [Peer: Imposes management sequence on Commitment; Affects Success;
Has sequential impact on Project Integration; Is situational for Management Processes] & [Has
sub-parts...]

Perpetual [Uses...]

Conditions imposed by the sponsoring organization throughout the project

Sequential [Uses...]

Genesis (modes) of project management: First Plan, then Produce

Generic periods (major phases): Concept; Development; Execution; Finishing

Logical or optimal sequence of Programs, projects, phases, stages, milestones, activities and
tasks

Situational or cyclical [Uses...]

Timing determined by management process requirements

Success [Peer: Impacts on Client Environment; Provides goals for Project Integration; Is post-
project in Real Time] & [Responds to...]

Factors implicit in the client’s organization

Capturing and distinguishing between client or sponsor's needs and wants

Identifying measurable indicators of project success as part of the project’s Concept



Matching management people, style and processes to product production

Establishing the ‘Quality Grade’ and content that will engender eventual satisfaction

Effective and efficient transfer of the project's product(s) upon completion



Appendix B

Knowledge Structure - Areas of Project Management Application

AREAS OF PROJECT MANAGEMENT APPLICATION (APMA) [Peer: Affects Client
Environment; Determines Project Integration] & [Has sub-types...]

The following divisions are based on the premise that, for the project to be successful and achieve its
highest potential, the WORK required in the Execution Phases needs to be managed differently
according to the nature of the resulting PRODUCT. These divisions are referred to as ‘Areas of
Project Management Application’ (APMA). The APMA may apply to the whole project, if the project
is relatively simple, or it may refer to the different major elements of a more complex project.
Alternatively, whole projects may be characterized by the work content of the major element, or
elements (i.e. the major work packages that represent the project’s chief emphasis) required to
produce the project’s output or ‘product’.

Tangible-Craft [Peer: Projects whose products are tangible and the result of craft work] & [Has as
examples...]

Building, Engineering Works, Infrastructure Works, Construction generally [Has sub-
parts...]

Impacts, limitations and risks of this technology

Regulatory and safety requirements, etc.

Industry-specific life-cycle phases [Has sub-parts...]

Project-specific stages

Tangible-Intellect [Peer: Projects whose products are tangible and the result of intellect work. The
product is tangible but the main effort is intellectual] & [Has as examples...]

Development of new products in manufacturing [Has sub-parts...]


Economics, safety, competition



Intangible-Craft [Peer: 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] & [Has as examples...]


Plant maintenance shutdown, Updating of a procedures manual [Has sub-parts...]


Urgency, safety



Intangible-Intellect [Peer: 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] & [Has as examples...]

Research work, Developing a new theory, Writing new software, Writing a book [Has sub-
parts...]


Opportunity, competition and copyright




Pm的知识架构

More Related Content

Similar to Pm的知识架构 (20)

Pm的知识架构