The Framework

R. Max Wideman
Chairman, PMBOK Standards Board

Projects and PMI

The idea of establishing projects, and the consequential need to manage them, has been around for a very long time In fact, since early civilization major projects like the pyramids of Egypt, or the Great Wall of China, or more recently, the Suez and Panama canals, have been successfully implemented. In their day, these were prolonged and complex undertakings and no doubt they exhibited many of the “management” difficulties experienced even at the present time.

The essential feature of these projects, indeed of any project, is to bring about change. That projects are designed to create change is not new. What is new is the rapidity with which change is currently taking place, and which we may confidently expect to continue to take place.

For example, the marvels of modern electronic communications have made almost everyone acutely aware of the disparities which exist between and within communities, countries and continents of the world. Improvements in this situation are only going to be brought about by even more and wide spread change, often with unprecedented degrees of urgency.

Since our resources are clearly limited, be they global or be they local, we must ensure that such change is brought about as effectively and efficiently as possible.

Through its primary dedication of “advancing the state-of-the-art in the management of projects,” the Project Management Institute aspires to improve the effectiveness and efficiency of the management of change for the benefit of all mankind.

The effort to identify and establish standards associated with the Project Management Body of Knowledge (PMBOK) follows naturally from PMI’s primary dedication. It represents a major Institute endeavour and is the PMBOK’s primary purpose. Secondary to this purpose, but equally consistent with PMI’s dedication, is to provide the basis and support for PMI’s professionalism programs, which include Accreditation, Education and Certification. These programs are described in other PMI publications.

Project Management Is Unique

Managing a project is different from managing an established on-going enterprise. To mention but a few of the obvious differences:

• Life in an on-going enterprise is relatively simple and certain for extended periods of time.
• Relatively large quantities of goods or services are produced per given time period.
• Tasks are generally repetitive, continuous or exhibit substantial similarity.
• Roles and relationships are well understood, having developed and adjusted over long periods of time, and
• The work environment is relatively stable.

None of these are true in a project environment. In a sense every project is unique, if only by virtue of its own set of constraints, although indeed there may be many projects of a similar nature. Some typical examples of projects include:

• Launching a new venture
• Developing a new product
• Effecting a change in structure, staffing, system or style in an existing organization
• Turning a poor performance situation into a satisfactory one within a target period
• Designing and producing a new transportation vehicle
• Designing and constructing a building or facility
• Implementing an urban or rural development program

What then are the attributes of these “projects”? What is it that makes them “unique”? Certainly they all involve the creation of change. In fact, to answer these questions is to go to the whole root, meaning and purpose of the PMBOK.

PMBOK Standards

Let us begin by identifying a project. Really, it is any undertaking with an established starting point and defined objectives the achievement of which clearly signify the conclusion of the project. In practice most projects are constrained by limits on the resources available to achieve the required objectives. The whole process of managing such a project is, of course, known as Project Management.

However, project management is merely a catch-all phrase for a number of major sub-functions. It is the very identification and on-going analysis of these functions which establishes the PMBOK. The representation of the PMBOK as a matrix provides flexibility in describing the various function interrelationships. However, the function chart structure contained within each of these functions is presented as a work break-down structure. The major project management functions which have been identified are briefly described below.

Many texts have been written about both traditional and project management. Doubtless many more will be written as our understanding continually advances. Here, therefore, we can only touch on some of the basic reasons for including the present range of functions within the PMBOK Standards.

Basic Project Management Functions

The definition of the project’s objectives together with all the activities involved in their achievement, and the resources consumed, is known as the project scope. Since the scope of a project has the habit of changing during the life of a project, this gives rise to the need for Scope Management.

For a project to be considered effective or successful, certain standards of quality must also be stated or presumed. Establishing and maintaining these standards during the life of the project leads to the need for Quality Management.

Since a project is determinate, it is clearly set in the context of a finite period of time. Unfortunately, time is a completely inflexible resource, so that activities must be carefully planned and scheduled. This is referred to as Time Management.

Because in our society “time is also money,” money is a closely associated resource. Fortunately, it is some-what more flexible. Nevertheless, it too needs careful managing, so we have Cost Management.

Scope, cost, time and quality form the basic core of project management. However, as yet we have not discussed some of the special circumstances which arise in the management of projects.

The Project Life Cycle

To achieve any kind of output or product, an effort is required. In the case of a project, however, the relation between effort and time is very distinctive. To visualize this relationship, consider a curve of effort plotted against time. Clearly the effort starts at zero (before the project has commenced) and ends at zero (when the project has been completed).

In between these two points, the effort-time curve invariably has a very characteristic profile. This may be likened to a pear sliced neatly down the middle, one half of which rests flat face downwards, with the stem at time zero. The vertical profile is then typical of the time-effort relationship.

Moreover, through the work of contributors to PMI, it has been reasonably established that every project, generically speaking, passes through four distinct project phases. These are known collectively as the project life cycle. Individually and according to the area of project application, these four phases may be known by different terms, for example: concept, development, execution and finishing. This happens to be my preference because the sequence C, D, E, F, is very easy to remember. Others may use successively terms such as Initiation, Planning, Implementation and Termination or Commissioning.

This project life cycle should not be confused with Facility/Product Life Cycle or even Corporate Business Life Cycle. It is of course related to these other life cycles and these relationships are shown diagramatically in Figure 1. It may be noted that in the diagram the project phases are further divided into project stages. Thus stages are subsets of phases.

Like the profile of the pear mentioned above, the time-effort curve starts to rise up in the concept phase, tends to level off during development, rises again sharply to a high peak during execution, and then even more rapidly drops to zero in the finishing phase. This typical profile is shown in Figure 2.

This phenomena is fundamental to the concept and needs of project management. The rapidly changing situation depicted by the time-effort curve through project life cycle places special emphasis and requirements on a number of areas of otherwise traditional management science. For this reason, these areas are considered to be essential knowledge for the effective management of projects.

Other Essential PM Functions

Projects are achieved through people and their respective skills and abilities. But the number of people and their types of skill varies considerably during the project life cycle according to the level of effort required as we have already seen. Consequently, many of these people are required only for relatively short periods of time. Normally there will be a core group referred to as the project team, led by a Project Manager.

Indeed, even the project team is required only temporarily. Thus, careful attention must be given to the assembly of people working together effectively through a clear understanding of their respective roles and responsibilities in a temporary organizational environment. This requires Human Resources Management.

Figure 1 PROJECT DEFINITION

TYPICAL PROJECT LIFE CYCLE compared with CORPORATE BUSINESS and FACILITY/PRODUCT LIFE CYCLE

Often these temporary organizational arrangements take place within a traditional management organizational setting. This introduces the concept of a Matrix Organization.

Projects are only launched for purposes of achieving change through predetermined objectives, or at least they should be! Because of the relative uniqueness of every project and the rapidly changing conditions as depicted by the time-effort curve, both mentioned above, the final outcome of every project is always uncertain.

This gives rise to the need for special and constant attention to the forecast final results in terms of meeting the ultimate objectives, including all resources consumed. Based on this forecast, especially if the forecast is unfavourable, it is possible to modify direction by exercising control.

Control is only achieved if all parties to the project clearly understand their respective roles and responsibilities as a result of careful planning and communication. Moreover, the status of the project at any given time is only apparent through consistent and accurate feedback. Often this feedback can only be fully understood through a proper interpretation of the project environment, both internal and external. Responding to the project environment is usually referred to as Public Relations.

Collectively, these activities come under the heading of Communications Management.

People and communication alone are not enough to implement a project. It is the service that people offer that is needed to execute the project. It is a common experience that a major portion of a project manager’s time must be given over to procuring peoples’ commitment to the objectives of the project. In addition, materials and equipment are also most likely required. The commitment of these goods and services are obtained through Contract/Procurement Management.

Uncertainty was mentioned earlier. Uncertainty is associated with probability and risk. Prudent management will take steps to mitigate the possibility of a less-than-favourable outcome by reducing the project risk wherever this can be achieved cost effectively. This leads to the need for a comprehensive understanding of the nature of the project in the first place, especially if it is a complex and interdisciplinary project. These activities are identified as Risk Management.

Finally, to tie all these PM Functions together, the PMBOK Standards Committee concluded that a further PMBOK section would be required to provide a frame of reference or overview. This section, which is not strictly a project management function, has been given the name Project Management Framework. From an educational standpoint, however, it is another subject area in its own right.

Figure 2 PROJECT LIFE CYCLE FOUR BASIC PHASES

Project Management Framework provides the opportunity in which the concept of a matrix can be developed to demonstrate the interdependences and interfaces between the respective functions. It also provides the opportunity to take an overview perspective of a number of other aspects of project management. Examples include the process of control, typical project life cycles, the need for project integration and inter-face management, and the place and impact of project management in the various public and private sectors.

It can also be the repository of some general project management background and information as well perhaps as some of the more universal tools and techniques of project management.

The PMBOK Setting

It is possible to depict the environment of project management and its related body of knowledge in a number of different ways. Venn diagrams and three dimensional matrices or boxes are all feasible. Figure 3 attempts to show the role of the PMBOK as a vehicle for the creation of change between General Management and Technical Management. The explanation of the diagram is as follows:

The light gray background represents abstract space. Into this space is introduced the top strip which is intended to portray the whole spectrum of knowledge which is required to successfully conduct industry and business. Of course this includes both the public and private sectors. As the diagram shows, this spectrum ranges from the know-how of general management on the left, through project management, to technical management on the right.

NOTE: The overlap areas infer that the project management staff must have sufficient understanding of the various specialist disciplines to appreciate project requirements and issues. They must also be able to communicate appropriate direction and means of conflict resolution to these specialists in order to reach a successful project conclusion.

Figure 3

The next series of strips immediately below are intended to elaborate on the top strip. The central over-lay circle encompasses the process and control that is project management.

The star points to the four key restraints of scope, cost, time and quality. As every project manager knows, these restraints are inextricably intertwined. Scope-quality represents performance, scope-cost represents viability, cost-time represents effort, and quality-time represents competitiveness.

As stated in the note below the diagram, for the project team to function effectively, “PM staff must have sufficient understanding of the various specialist disciplines to appreciate project requirements and issues. They must also be able to communicate appropriate direction and means of conflict resolution to these specialists in order to reach a successful project conclusion.” One might add the corollary that, because of their particular bias, specialists frequently have difficulty in becoming good project managers.

This “sufficient understanding” is represented by the “fingers” which reach from the central project management circle into the areas of general management on the left and technical management on the right. Further, if these fingers are traced horizontally, then each depicts a typical functional management area which itself ranges from the general application on the left to the specific technical application on the right. Perhaps the best example is the strip ranging from Information Systems in general to Communications in particular.

Clearly, the Project Management Body of Knowledge cannot possibly encompass the whole know-how continuum. Nor would it be appropriate because Project Management has its own unique special area of expertise. This is shown by the white area within the bottom strip in the diagram. The two “overlap” areas of gray on this strip reflect the extent to which this knowledge must necessarily extend into the two areas on the left and right of the diagram.

I would add that the gray area on the left is knowledge that every project manager should have. The gray area on the right, on the other hand, is specific to the technical field. This is what makes an individual project manager a specialist in a given area of application.

Thus, sound project management is what enables general management to come together with technical management for purposes of managing progress and change effectively and efficiently for the benefit of all.

Linn C. Stuckenbruck, Ph.D.
Institute of Safety and Systems Management
University of Southern California

This report is a summary of the discussions at one of the individual tracks of the Project Management Body of Knowledge workshop held in conjunction with the 1985 PMI Seminar/Symposium at Denver, Colorado. This particular track was charged with the task of taking an overview perspective of the existing project management body of knowledge. The thoughts expressed in this report were developed as a result of the extensive discussions, interactions, and some consensus among the workshop task members.

This track produced very stimulating discussions, and was a rewarding experience for all the participants. The author apologizes for any liberties which he may have taken with the thoughts expressed at the work-shop. This report is essentially a rethinking of the thoughts coming out of the track meeting plus a number of inevitable afterthoughts and revisions which have occurred as a result of feedback from other concerned PMI members.

Introduction

The process of developing and obtaining agreement on the content of the body of knowledge referred to as project management was initiated by PMI as a portion of the job assigned to the Ethics, Standards and Accreditation (ESA) Project. The project members, led by the Southern Ontario Chapter, with Matt Parry serving as the project manager, made tremendous strides in advancing project management as a profession. They began by recognizing that an accepted “profession” must have a unique, well-defined body of knowledge (BOK) that can be studied and learned through formal education. Their initial efforts left no doubt that there definitely was such a unique body of knowledge. However, defining exactly what should be included in this BOK has proved to be considerably more difficult, and therefore has continued to be an on-going effort.

PMI Project #121, and its workshop held in conjunction with the Denver Seminar/Symposium, was conceived specifically for the purpose of continuing the process of defining this project management body of knowledge (PMBOK). During the workshop planning period it was recognized that it would be desirable to have one of the workshop tracks review the PMBOK from an overview perspective.

This article was prepared to report the results of these discussions which, during the workshop, became oriented towards refining the overview model or common frame-of-reference for the PMBOK.

Status of the Project Management Body of Knowledge

The original ESA Project, in approaching the PMI goal of fostering the professionalism of project managers, has taken the initial step in the definition of exactly what is in the project management body of knowledge. This resulted in a “Baseline” which provides an outline of the PMBOK. The ultimate objective was to extend this outline to provide standards for the profession of project management. This “Baseline Concept” divided project management into the following six basic functions:

• Human Resources Management
• Cost Management
• Time Management
• Communications Management
• Scope Management
• Quality Management

Each of these functions is further broken down into topics and subtopics in the manner of a Work Break-down Structure (WBS). Each level of the WBS was clarified by glossaries which defined all of the terms used. It was proposed by the ESA Project group that this WBS would provide the Institute and its members with a model or “Baseline” for future discussion and agreement. It was in the spirit of building on this existing recorded effort that the present task group carried out their overview perspective of the project management body of knowledge.

Limitations of the WBS Model

The Baseline Concept provides a one-dimensional model following the branching of a Work Breakdown Structure. It is very appealing in its simplicity, particularly to project managers who feel very comfortable with the WBS structure as a management tool. However, the members of this PJ #121 Workshop Overview track felt that there was a definite need to review the WBS model and to determine whether there might be other more applicable models. In pursuing this avenue, the track members reached general agreement on the following points:

(1) There appeared to be a need to scope out or put boundaries on the PMBOK. There are obviously large portions of other disciplines which can be directly incorporated into the PMBOK. However, there must be limits if this body of knowledge is to be kept within manageable boundaries. If this body of knowledge is to be recognized as unique to the project management profession, it must not appear to consist primarily of blocks of knowledge and tools appropriated from other disciplines.

(2)There appeared to be difficulties in incorporating some very important real-world aspects of the project manager’s job into the six existing project management functions. There is a need for a special subject area in which the essential project management functions of project integration and interface management could be addressed.

(3) There appeared to be difficulties encountered in the use of the WBS model in adequately describing the necessary interdependencies and interrelationships between the six project management functions. For instance, project schedule, cost and quality (performance) management are not separate tasks or functions; they are integrated functions and the planning and control tools must tie them together and recognize their inter-dependencies.

(4) There appeared to be a potential for a great deal of overlap and/or repetition in trying to adequately expand each function into the more detailed levels of the body of knowledge. Therefore, the original WBS model was evidently too restrictive for the purposes of representing the PMBOK as a whole.

Scope of the Project Management Body of Knowledge

As noted earlier, the task group recognized very early in the discussions that there was a need to put limits or boundaries on the body of knowledge. It was also recognized that project management is a complex multidisciplinary profession which has considerable over-lap into many other disciplines and professions. The degree of overlap is also greatly dependent upon which particular industrial sector, field or other application is using the project management approach. The three major points of overlap are in the areas of: (1) general management (2) the technical area(s) in which the project is involved, and (3) the supporting or service areas which are also crucial to project success. This overlap can be depicted by a Venn diagram in which each circle represents a particular body of knowledge and the shaded areas represent the overlaps (Figure 4).

The four circles will have considerable overlap, but how much depends on the ground-rules set to determine the scope of the PMBOK. In order to develop some logical ground rules, it is useful to determine what kinds of knowledge are in each of the bodies of knowledge that impact on project management.

Considerable controversy can immediately be generated concerning what portions of the general (or business) management body of knowledge should be included in project management. There is no argument, however, that the general management body of knowledge consists of the following types of knowledge:

• Business policy
• Business strategy
• Planning and controlling
• Financial management
• Accounting
• Business economics
• Information systems
• Organizational behaviour
• Organizational development
• Staffing
• Personnel development
• Marketing and sales
• Problem solving
• Decision making

The question that must be answered, therefore, is what portion of these areas of knowledge should be included in the PMBOK?

Supporting or service disciplines are often essential for the success of project management, and parts of some of the following disciplines (or service departments) might also be included:

• Quality Assurance (Quality Control, Statistical Quality Control, etc.)
• Configuration Management
• Logistics (Integrated Logistics Support)
• Contract Administration
• Procurement (Purchasing)
• Personnel Administration
• Facilities (Industrial) Engineering
• Legal
• Computer Programming

On the other side, the technical body of knowledge is somewhat more difficult to generalize since it is not truly represented by one single circle in the Venn diagram. It really should consist of a number of circles each representing one of the many different industries, technologies, and professional areas in which project management is applied. Each has a large body of knowledge, much of which impacts in some manner on the project manager’s job.

Figure 4

The problem is to determine what portions of these technical bodies of knowledge should be included in project management. Indeed, further studies may be necessary to determine whether there are aspects of the project manager’s job which are different depending on the particular industry or technology involved.

Project management is widely used in many types of industries or technolgies, each of which may consist of many different disciplines. For example:

• Aerospace
• Banking
• Computer Systems
• Construction
• Defense
• Education
• Energy & Utilities
• Government and Civil Service
• Information Systems
• Pharmaceuticals
• Resource Industries
• Telecommunications
• Transportation

Figure 1 suggests that the following ground rules would be appropriate for scoping the project management body of knowledge:

(1) Much of the general management body of knowledge should be recognized as a given or prerequisite for project management and not included in the PMBOK unless aspects of this knowledge are an integral part of the project management process.

(2) The PMBOK should not include major areas of other disciplines, professions or detailed knowledge particular to a specific industry unless this information is also an integral part of the project management process.

(3) The PMBOK should not contain knowledge, technology, techniques or skills which are primarily useful in only one industry or technology. That is, it should not contain such items unless they are broadly useful in almost any application of project management.

(4) The PMBOK should not include major portions of supporting or service disciplines unless they are generally applicable to most projects. Such disciplines stand on their own feet and are principally utilized as tools of project management. Only those specific applications which reinforce the job of the project management team should become part of the project management body of knowledge.

(5) The PMBOK should emphasize knowledge, skills and techniques which are either unique to project management or are fundamental to carrying out the project management process.

(6) There is a definite need for the overlaps in the various bodies of knowledge as indicated in Figure 1. Project managers and their PM teams have a great need for an expertise in general management as well as considerable need for knowledge and expertise in the particular project field.

The Need for a Model

Thus, the Overview track recognized that there was a definite need for a framework for the PMBOK to serve the purpose of “gluing it all together”. This track felt that the most appropriate way to accomplish this task was to develop a sound structural framework or model, firstly to organize and classify the body of knowledge and secondly to make certain that is is complete. To adequately accomplish these goals and to be useful to the membership of PMI, the model must do the following things:

(1) Clarify the overall scope and extent of the comprehensive project management body of knowledge.

(2) Break up the body of knowledge into logical and understandable categories or divisions.

(3) Utilize and build on the work accomplished by the PMI ESA Project.

(4) Indicate the interrelationships between the various categories into which the project management body of knowledge can be subdivided.

(5) Take into account the complexities of project management and the integrating nature of the project manager’s job and of his or her supporting team.

(6) Provide a breakdown of the project management body of knowledge into categories which can readily be utilized for storage and retrieval of all elements of project management, i.e. functions, processes, activities, tools and techniques.

(7) Be sufficiently simple and understandable to be useful (i.e. saleable) to present and potential project management practitioners.

(8) Be consistent with the course content of project management educational programs (particularly with the PMI sponsored program at Western Carolina University).

Rationale for a Matrix Model

A variety of models were considered after it had become apparent that a one-dimensional model was not completely satisfactory. The suggestion that a multidimensional matrix might better depict the complexities of the project management body of knowledge came from a number of workshop participants including the Pittsburgh Chapter and David Morton. The Overview track also decided that a matrix would ameliorate all of the previously listed limitations of the WBS model.

The development of the rationale began by a consideration of the three basic project management functions or elements of every project, namely schedule, cost, and technical performance (Figure 5). In addition, it was recognized that the integrative project management functions are quite independent of, and cut across, all these basic functions. The applicability of a two-dimensional matrix then became obvious; one dimension consisting of the basic project functions or elements, and the other dimension consisting of the integrative project management functions.

Figure 5

The necessity or desirability of a third (or even fourth) dimension can be debated at length. A very good case can be made for making additional dimensions for the project life cycle, the system environmental level, the system technical environment, or even a breakdown into processes, activities, tools and techniques (Figure 6). For completeness the PMBOK might well be described by a three- or four-dimensional matrix. However, it was felt that more than two dimensions would add unnecessary complexity to the model and to the resulting descriptions of the project management body of knowledge. Further it was felt that the significance of these additional dimensions may be minor from a practical point of view, and their existence can be recognized in future descriptions of the detailed blocks of knowledge.

Figure 6

For instance, does the job of the project manager and PM team change significantly during the different stages of a project life cycle? Certainly the project and the project manager’s duties will change greatly during the life of a project; however, for the most part the differences are seen as changes in emphasis. For example, during the startup of a project the project manager will be preoccupied with planning while at the end of a project the emphasis will primarily be on termination. However, all projects, by definition have these characteristics and both are clearly a part of the PMBOK. The basic fundamentals of good project management are common to all projects, and are the heart of the project management body of knowledge.

The Model

It was apparent that the greatest difficulty would be to obtain concensus on the specific breakdown of the two dimensions of the matrix - the project elements and the project functions. Starting with the three basic project elements of cost, schedule, and technical performance, there was considerable disagreement as to whether other elements were needed to complete the picture. Although it was argued that project scope and environment could fall under technical performance, they were added to the basic project elements to obtain concensus.

There seemed to be an almost unlimited number of management functions which might be included in the matrix; however, the seven included in Figure 7 were selected as the most important. Certainly a number of others could be added.

The matrix model’s usefulness is most evident in the flexibility by which the PMBOK can be organized and reviewed. At each intersection in the body of the matrix is a “box” representing a particular block of knowledge definded by the two dimensions of the matrix. Each “box” or block of knowledge consists of the relevant knowledge, skills, processes, activities, techniques and tools consistent with the particular dimensions. Thus, individual blocks of knowledge can be clearly defined, and interrelationships or overlaps between them can be readily identified.

Conclusions and Recommendations

The Overview workshop track began with the recognition that there was a need for a fresh look at the model el for the project management body of knowledge. The limitations of the WBS model led the group rather logically to a consideration of a matrix model since it evidently provides a flexible and useable tool for identifying the PMBOK.

The membership of PMI in their future effort to identify and expand project management as a profession will find the matrix to be a much more flexible and useful framework on which to build. The group, therefore, recommends that the two-dimensional matrix model be adopted to provide a new framework and overview perspective of this rapidly growing unique project management body of knowledge.

Figure 7 Project Management Matrix Model

Part 3 An Integrative Model

Philip C. Nunn, PMP
DeVry Institute of Technology

Abstract

This is a progress report on the portion of the Project Management Body of Knowledge project known as the PMBOK Framework. Although the framework of the PMBOK has been implicit in the development of the definition of the functional components of the PMBOK, its explicit definition has lagged that of its components. Through the published efforts of Max Wideman and Linn Stuckenbruck we have become aware of the need to define the overall framework of the PMBOK. This report documents development of the Framework to this point, describes available materials, and proposes a course of action for the further development of the PMBOK Framework.

The Need For A PMBOK Framework Model

The need for a Framework model of the Project Management Body of Knowledge is evidenced by the most difficult question we are asked about Project Management, “What is Project Management?” Our inability to give even a consistent answer to this question demonstrates our need.

The Framework model of Project Management should:

Describe how project management is different from other types of management

Establish criteria for determining what constitutes a Functional Component

Identify the present components of Project Management and their dynamic interaction

Describe the appropriate applications of Project Management and its benefits

Provide an authoritative lexicon of the technical terms of Project Management

The time is ripe for development of the Project Management Framework Model. When coping with the unknown, we most often start developing new ideas from the base of what we already know. The PMBOK is no exception. We now have a sufficient definition of the more specific components of Project Management so we can begin the work of defining the integration of these. The Framework Model is the tool which helps answer our most difficult question.

Current Structure Of The Framework Model

In recent months, the membership of PMI has been quite productive in making suggestions on the nature and structure of the PMBOK Framework Model. Contributions from Lew Ireland, Phil Nunn and Lloyd Rogers were published in August 1986. Linn Stuckenbruck’s report in August 1986 recommended an alternative model.

The purpose of a model of the Project Management Body of Knowledge is to help us organize this knowledge so that we can examine and evaluate the scope of our profession. It also helps colleges and universities to structure programs for training Project Managers and conducting research. These tasks are formal parts of PMI’s primary objective which is to advance the state-of-the-art in project management.

To arrive at a more specific Framework Model, the examples already submitted and published were reviewed to identify commonality in their structures. This was a tricky operation because the Framework model should not disturb any of the existing models of the PM Functions. The resulting PM Framework Model, which is intended to integrate the whole of the PMBOK, is shown in Figure 8.

As an integrated whole, it has some characteristics which are unique to it and not shared with the PM Function models. In familiar terms, “The whole is greater than the sum of its parts.” This concept of an integrated whole allows us to examine such topics as Types and Applications of Project Management, the Benefits and Limitations of Project Management, and the External Interfaces of Project Management.

Max’s model displayed in Figures 3 is an example of a model of one of the External Interfaces of Project Management. It is a workable presentation of the management knowledge environment within which Project Management is imbedded. Although management knowledge is not the only environment for project management that we must consider, it is a particularly difficult one to understand. It is a nebulous abstraction with no direct concrete outcomes. As the cognition theorist. Art DeLong, has said, “The whole foundation of mankind is based on how we humans learn by acquiring knowledge.” Some specific environments for Project Management are listed in Figure 8.

Figure 8 Function Chart Project Management Framework Model

The Types and Applications of Project Management are the domain of the Framework model. Individually, we do not usually recognize the existence of configurations for projects. This may be due to our limited experience with only one or a few businesses, industries, or governmental activities. When I start asking questions of people from other lines of work, I start appreciating that there probably are many types of project management. These need to be examined, defined and compared. The Framework is the place to start this effort, although it will filter down into the PM Function models.

When we try to explain the benefits and limitations of Project Management, we are operating at the level of the Framework model. This is where we compare Project Management as an integrated whole to other methods of management. It takes all of the Functional Models combined and then some to be able to make these comparisons.

Under each component in the PM Framework break-down structure, example items have been listed. These lists are not complete, nor are they necessarily accurate. There probably are some intervening levels of break-down needed for most of the Framework components. This is work that still needs to be done.

Many of the components of the Framework model are shared with the PM Functional Models. These relationships are only hinted at by the Cross Impact Matrix shown in Figure 9. Where X’s do not appear at all, that Framework Component is overwhelmingly focused at the Framework level.

Some of the Framework Components of Figure 9 display relationships with only some of the PM Functions. This is the case for the Active Direction component, which is indicated as having a relationship with only Human Resources and Communications & Information. Active direction of a project is a human activity. Its focus is on the human Functions. This is not necessarily to the exclusion of the other Functions, but the extent of their direct participation is low. For example, Time Management’s participation in Active Direction is to provide some of the information communicated, but Active Direction is a human to human activity while schedules are inanimate data.

Two characteristics missing from the Cross Impact Matrix of Figure 9 are the extent of participation by each PM Function, and the dominant direction of the participation. With regard to the direction of participation, the PM Function models will contribute to the Internal Interfaces of the Framework Model. On the other hand, the Functional Models will get their guidance on Life Cycle from the Framework Model. Clearly, there is more work to be done on these characteristics.

For the bored practitioner, I offer this solace: You are right! The examination of abstract models has little practical use unless the model leads us to a usable organization of our knowledge. Just as you suspected, there is no “right” model for the task of organizing our knowledge. There are also no “wrong” models. There are, in fact, as many models as there are people willing to develop them. However, there is no question that some models facilitate the organization of our knowledge better than others.

The present Framework Model, Figure 8, can be elaborated on, but that should be a controlled academic exercise. Otherwise, we can become so embroiled in the comparison of knowledge models that we lose sight of our purpose. The Framework Committee’s purpose must be to establish a model to organize the Project Management Body of Knowledge so that education programs can continue to be developed and PMI’s certification program can continue to grow without losing its coherence.

Future Action

Over the next year, I propose that the PMBOK Framework Functional Committee be thought of as a working group. To reinforce this practical and productive focus, I will probably refer to it as the Framework Working Group.

The Framework Working Group, like all task forces and project teams, needs objectives. My proposed objectives for the Framework Working Group for the next year are therefore to:

1) Elaborate The Framework Model

This work will put the Function Models of the Project Management Body of Knowledge in perspective with each other, that is within an integrating frame-work. This is a target rather than an objective because it must be recognized that this is a pioneering effort. There is little precedent and few guides. The rate of accomplishment is going to be quire variable. The importance is placed on development toward the target and making progress.

The PMBOK Framework as an integration model, will focus on those ideas which tie the components together. It will also attempt to identify the processes by which the components work together in practice. This will be the effort to carry out Harvey Levine’s charge to “Tie a ribbon around each of the six packages.” And, an effort will be made to avoid reinventing the wheel. Time spent on evaluating alternative models to the ones already presented will be limited. Most of the work will be placed on elaborating and clarifying the existing models. New and alternative models will be examined only where a gap in the organization of our knowledge prevents work from progressing. In summary, this will be a disciplined design effort rather than a daydreaming session.

Note: X indicates a strong relationship between the PM Function and the Framework Component A blank indicates a lesser contribution and hence focus at the Framework level

Figure 9

Cross Impact Matrix Model PROJECT MANAGEMENT FRAMEWORK

I am convinced that this effort to organize the Framework of the PMBOK is needed at this time to stabilize the gains we have already made and provide a firm base for solid development of the PMBOK in the future. I do agree with those who think it is more fun to bite off new ideas than to digest what we already have. However, without this period of digestion, we will lose our direction and sense of purpose as new ideas are presented to us in the future.

This will be a group effort. Several people are being contacted to contribute specifics to this work but anyone willing and able to manipulate abstractions will be welcome.

2) Collect Together The PM Glossary

We shall be seeking help to pull together a complete, concise and understandable glossary of Project Management terminology. We need to combine the several efforts of the many previous contributors, and make a first authoritative publication.

3) Develop Certification Questions

The Framework Working Group needs to develop a pool of questions about the components and topics unique to the Framework Model. Also questions relating to interfacing among the Function Models need to be developed. Guidance for the format and content of these questions will be provided by the appropriate PMI committee

This task will necessarily have to start at least half way through the year because the group working on the Framework Model itself will be the best suited to write the questions. But, they must be given time to get the Framework Model refined well enough to provide guidance for question writing.

Part 4 Glossary of General Terms

Functional Definitions

Project Management Institute (PMI): A non-profit organization dedicated to advancing the state-of-the-art in the profession of project management.

Project Management (PM): It is now generally accepted by the PMI that project management is an established discipline which can be defined as follows:

Project Management is the art of directing and coordinating human and material resources throughout the life of a project by using modern management techniques to achieve predetermined objectives of scope, cost, time, quality and participant satisfaction.

Project Management Body of Knowledge (PMBOK): is defined as all those topics, subject areas and intellectual processes which are involved in the application of sound management principles to the collective execution of any types of effort which qualify as projects.

Project Management Framework: The idea of setting out to achieve certain predetermined objectives in several concurrent areas presupposes the application of discipline and control through sound management practices. This in turn requires delegation of effort to various specialized “functional” management areas in which the separate objectives are to be achieved.

However, each of these functions must contribute to the successful overall achievement of the project’s objectives and assist the control effort through systematic processes appropriate to the particular function.

Through its work in examining the body of knowledge which is the discipline of project management, the Institute has now identified nine areas of concentration. This generic Project Management Body of Knowledge consists of a Project Management Frame-work which in turn encompasses eight major PM functions, namely the management of: scope; cost; time; quality; human resources; communications; contract-procurement (including materials and equipment); and risk.

Note that this list includes only those functions which are generally applicable to any type of project, whether it be in construction, defence, aerospace, hi-tech, pharmaceuticals, education and so forth. Not included are the many technical functions which are necessary, but which are specific to each particular field of project endeavour.

In defining each PM function, it is useful to identify the processes (i.e. specific series of activities) which are involved in the function, and which are necessary to achieve the required function output. Therefore, they can be defined as follows:

Scope Management: is the function of controlling a project in terms of its goals and objectives through the processes of conceptual development, full definition or scope statement, execution and termination.

Cost Management: is the function required to maintain effective financial control of the project through the processes of evaluating, estimating, budgeting, monitoring, analyzing, forecasting, and reporting the cost information.

Time Management: is the function required to maintain appropriate allocation of time to the overall conduct of the project through the successive stages of its natural life-cycle, (i.e. concept, development, execution, and finishing) by means of the processes of time planning, time estimating, time scheduling, and schedule control.

Quality Management: Quality itself is the composite of material attributes (including performance features and characteristics) of the product or service which are required to satisfy the need for which the project is launched. Quality standards may be attained through the sub-functions of Quality Assurance and Quality Control.

Quality Assurance (Management): is the development of a broad program which includes the processes of identifying objectives and strategies, of client inter-facing, and of organizing and coordinating planned and systematic controls for maintaining established standards. This in turn involves measuring and evaluating performance to these standards, reporting results and taking appropriate action to deal with deviations.

Quality Control (Technical): is the planned process of identifying project established system requirements and exercising influence through the collection of specific (usually highly technical and itself standardized) data. The basis for decision on any necessary corrective action is provided by analyzing the data and reporting it comparatively to system standards.

Human Resources Management: is the function of directing and coordinating human resources through-out the life of the project by applying the art and science of behavioral and administrative knowledge to achieve the predetermined project objectives of scope, cost, time, quality and participant satisfaction.

Communications Management: is the proper organization and control of information transmitted by whatever means to satisfy the needs of the project. It includes the processes of transmitting, filtering, receiving and interpreting or understanding information using appropriate skills according to the application in the project environment. It is at once the master and the servant of a project that it provides the means for interaction between the many disciplines, functions and activities, both internal and external to the project, and which together result in the successful completion of that project.

Contract-Procurement Management: is the function through which resources (including people, plant, equipment and materials) are acquired for the project (usually through some form of formal contract) in order to produce the end product. It includes the processes of establishing strategy, instituting information systems, identifying sources, selection, conducting proposal or tender invitation and award, and administering the resulting contract.

Risk Management: is the art and science of identifying, analyzing and responding to risk factors through-out the life of a project and in the best interests of its objectives.

Function Chart Structure: Each of these PMBOK management functions is depicted by a Work Break-down Structure (WBS) Chart broken down as follows:

Other General Definitions

Activity: A task or series of tasks performed over a period of time.

Area of Project Application: The environment in which a project takes place, with its own particular nomenclature and accepted practices e.g. facilities, products or systems development projects (to name a few).

Baseline: Management plan and/or scope document fixed at a specific point in time in the project life cycle.

Baseline Concept: Management’s project management plan for a project, fixed prior to commencement.

Commitment: An agreement to consign or reserve the necessary resources to fulfill a requirement until expenditure occurs. A commitment is an event.

Concept: An imaginative arrangement of a set of ideas.

Control: The exercise of corrective action as necessary to yield a required outcome consequent upon monitoring performance.

Corporate Business Life Cycle: A life cycle which encompasses phases of policy-planning and identification-of-needs before a project life cycle, as well as product-in-service and disposal after the project life cycle.

Cost Effective: Better value for money, or the best performance for the least cost.

Effort: The application of human energy to accomplish an objective.

Environment: The combined internal and external forces, both individual and collective which assist or restrict the attainment of the project objectives. These could be business or project related or may be due to political, economic, technological or regulatory conditions.

Facilities/Product Life Cycle: A life cycle which encompasses phases of operation and disposal as well as, and following, the project life cycle.

Feedback: Information (data) extracted from a process or situation and used in controlling (directly) or in planning or modifying immediate or future inputs (actions or decisions) into the process or situation.

Forecast: An estimate and prediction of future conditions and events based on information and knowledge available at the time of the forecast.

Function: (PM Function) The series of processes by which the project objectives in that particular area of project management, e.g. scope, cost, time, etc, are achieved.

Interface Management: The management of communication, coordination and responsibility across a common boundary between two organizations, phases, or physical entities which are interdependent.

Management: The process of planning, organizing, executing, coordinating, monitoring, forecasting and exercising control.

Matrix: (PMBOK matrix) A two-dimensional structure in which the horizontal and vertical intersections form cells or boxes. In each cell may be identified a block of knowledge whose interface with other blocks is determined by its position in the structure.

Matrix Organization: A two dimensional organizational structure in which the horizontal and vertical intersections represent different staffing positions with responsibility divided between the horizontal and vertical authorities.

Mitigation: The act of revising the project’s scope, budget, schedule or quality, preferably without material impact on the project’s objectives, in order to reduce uncertainty on the project.

Monitoring: The capture, analysis and reporting of actual performance compared to planned performance.

Plan: An intended future course of action.

Process: The set of activities by means of which an out-put is achieved.

Project: Any undertaking with a defined starting point and defined objectives by which completion is identified. In practice, most projects depend on finite or limited resources by which the objectives are to be accomplished.

Project Environment: See Environment.

Project Integration: The bringing together of diverse organizations, groups or parts to form a cohesive whole to successfully achieve project objectives.

Project Life Cycle: The four sequential phases in time through which any project passes, namely: concept; development; execution (implementation or operation); and finishing (termination or close out). Note that these phases may be further broken down into stages depending on the area of project application.

Project Manager: The individual appointed with responsibility for project management of the project.

Project Organization: The orderly structuring of project participants.

Project Phase: The division of a project time frame (or project life cycle) into the largest logical collection of related activities.

Project Risk: The cumulative effect of the chances of certain occurrences which will adversely affect project objectives. It is the degree of exposure to negative events and their probable consequences. Project risk is characterized by three factors: risk event, risk probability, and the amount at stake.

Project Stage: A sub-set of Project Phase.

Project Team: The central management group headed by a project manager and responsible for the management and successful outcome of the project.

Public Relations: An activity designed to improve the environment in which an organization operates in order to improve the performance of that organization.

Responsibility: Charged personally with the duties, assignments, and accountability for results associated with a designated position in the organization. Responsibility can be delegated but cannot be shared.

Schedule: A display of project time allocation.

Scope: The work content and products of a project or component of a project. Scope is fully described by naming all activities performed, the resources consumed and the end products which result, including quality standards. A statement of scope should be introduced by a brief background to the project, or component, and the general objective(s).

Status: The condition of the project at a specified point in time.

System: A methodical assembly of actions or things forming a logical and connected scheme or unit.

Technique: Skilled means to an end.

Uncertainty: See Project Risk.

Work Breakdown Structure: A task-oriented “family tree” of activities which organizes, defines and graphically displays the total work to be accomplished in order to achieve the final objectives of the project.