Lessons learned to guide project management theory and research

pragmatism and knowledge flow

 

Dr. Mark E. Nissen, Graduate School of Business & Public Policy, Naval Postgraduate School, Monterey, CA, USA

Dr. Keith F. Snider, Graduate School of Business & Public Policy, Naval Postgraduate School, Monterey, CA, USA

Two years ago, at the inaugural Project Management Institute (PMI®) Research Conference in Paris (cf. Slevin et al 2000), some of the top minds in academia and practice came together to confer on research associated with project management. Toward this end, panel sessions were conducted to address two of the fundamental project management research issues: 1) the theory of project management (Pinto et al 2000), and 2) the future of project management research (Cleland et al 2000). Given that this project management research forum represented one of the first of its kind, considerable disagreement emerged through these panel sessions. For instance, in the first session, some panelists cited A Guide to the Project Management Body of Knowledge (PMBOK® Guide) as evidence of project management theory, whereas it was unclear to other panelists and many audience participants whether project management even has theory associated with it. As another instance, in the second session, some panelists viewed project management research as being driven primarily through documentation of practice, whereas others envisioned a stronger role for academics and theoretical development.

We see the emergence of such discourse as a positive step in project management’s development, in that it can lead to an awareness and examination of the intellectual foundations upon which the field is being built. Currently, discussions about various “philosophies of science” or epistemologies that underlie project management are understandably absent, since project management is relatively “young.”Yet these underpinnings exist, albeit in an implicit, taken-for-granted form. We believe it is appropriate at this point in project management’s development to begin to examine these assumptions more consciously and explicitly in order to understand how they are shaping the intellectual trajectory of the field. Further, there are lessons that can be learned through experience with the development of other social science fields. Such lessons offer excellent potential to obviate problematic developments, and by considering the lessons now—before project management research has established huge momentum and been entrapped by its own history—we face a unique opportunity to help shape and condition the field for success in the future.

In this paper, we want to extend the discussion, begun two years ago, of research and theory in project management by focusing on its underlying philosophical foundations. Our method of introducing this focus is to portray project management theory and research as proceeding along a road that represents a particular perspective: positivism.Ahead in the road is a fork that represents an alternative perspective, that of pragmatism.The implications of remaining on the path of positivism or taking the “pragmatic turn” are summarized in the following paragraphs.

Implications of Positivism

Positivism, which may be traced to Auguste Comte and others, assumes that there are discoverable laws, or constant relations, surrounding the order of nature. Positivist science consists of the attempt to formulate these laws of constant relations based on study of observable facts. Part of positivism’s appeal was the assumption that such laws can be developed for the social as well as the physical realm; hence positivism held out the prospect of social progress through science (Stumpf 1966, 347–349).

During roughly the past quarter century however, several authors (e.g., Schön 1983; Miller and King 1998) have noted and commented upon a theory-practice gap in social science fields such as management and business. These authors attribute this gap to a dominant positivist epistemology that tends to separate the roles of researcher and practitioner. Within this construct, researchers take on the role of providing knowledge or science, while the practitioners’ role is to use knowledge and provide needs for further research. These authors argue persuasively that the premise that researchers possess (or should aspire to possess) a body of foundational truths is invalid, considering the contingent nature of knowledge in these fields. Grand theories or definitive bodies of knowledge are poor fits in contemporary professional fields. These fields involve highly complex enterprises that often entail the overlap and interplay of a variety of contexts—management, business, politics, and technology, to name a few— each of which is continually evolving in important ways. Under such conditions, the development of stable theories and bodies of knowledge becomes problematical.

According to this point of view, positivist social science research has not fulfilled its promise of greater predictability and control in, for example, the practice of management. As a consequence, practitioners express frustration with researchers and their inability to produce useful theory, researchers express frustration with practitioners who misunderstand or misapply their findings, and the theory-practice gap widens. Evidence for this condition within many fields may be seen in its various journals and conferences. Scholars rarely read practitioner journals or attend professional conferences, for example, and many practitioners avoid scholarly journals and academic conferences.

Clearly, events such as the PMI Research Conference Series provide evidence that such condition does not yet affect the project management field, but some observable trends suggest that the field may be moving in this direction. For instance, one can argue that the PMBOK® Guide embodies an inherently positivistic approach to theory development in the project management field. It represents a centralized source of (grand) project management “knowledge”; this source remains relatively static; and the emphasis is almost solely on formalizing explicit knowledge. Alternatively, a substantial portion of the knowledge formalized through the PMBOK® Guide derives from practice, and the number of academics contributing to this body of knowledge remains relatively small with respect to contributions from practice. Thus, project management has not (yet) committed itself to an exclusively positivistic approach.

Implications of Pragmatism

The other perspective is pragmatism. Pragmatism rose to prominence roughly a century ago, mainly through the ideas of C. S. Peirce, William James, and John Dewey. While pragmatism has come to mean in common usage simply “doing what works,” these philosophers originally developed it as a more extensive system of thought. Their central point was that one must look to the practical consequences or effects of ideas, rather than to some underlying foundational truth, if agreement is ever to be reached on what various ideas mean.

According to Dewey, pragmatism deals mainly with “how thought functions in the experimental determinations of future consequences” (1998, 9). Thinking, rather than a quest for truth, is an instrumental attempt to adjust oneself to the environment. Thought guides action, and ideas are plans of action or hypotheses, rather than representations of immutable truths or ends.

Ideas are statements not of what is or what has been but of acts to be performed.... Ideas are worthless except as they pass into actions which rearrange and reconstruct in some way, be it little or large, the world in which we live. (Dewey 1929, 138)

Action guided by thought is thus experimental. One experiments with the environment and experiences consequences, which provides feedback for future conduct. This experimentalism indicates pragmatic science as embracing an open, tentative, and flexible epistemology.

The pragmatist philosophers all emphasized the manner in which pragmatism collapses dichotomies—facts versus values, ends versus means, thought versus action, theory versus practice—that are inherent in other philosophical systems. As Dewey stated, “It is therefore not the origin of a concept, it is its application which becomes the criterion of its value” (1998, 10). Since actions have value in their resolution of some problematical situation, value inheres in action; thus “ends” (values) are inseparable from “means” (actions). Further, thought is not something that happens in isolation from action. Rather, thinking involves the continual reflection on experience, which informs action to resolve and transform problem situations. Thus, thought and action (or theory and practice) function in an integrated way.

Another important implication of pragmatism is that the distinction between theorist and practitioner is blurred, since practitioners are theorists of a practical kind (Miller and King 1998). That is, practitioners use various resources (e.g., their experience, education, consultation with colleagues) to form practical theories about how to tackle dayto-day problems. These theories are constantly tested, reflected upon, refined—though probably in a tacit or implicit way—and perhaps communicated to others. Orr’s well-known account (1996) of the problem-solving processes of copier repairmen illustrates this point well. Thus, any distinction between the academic theorist and the practitioner theorist has more to do with the academic’s “distance” from a problem and the degree of “explicitness” of academic theorizing than with the theorizing function itself.

According to this line of argument, a portion of any field’s bodies of knowledge and theory resides in the tacit, practical theories of its practitioners. This conclusion is borne out by the significant attention paid to tacit knowledge in the literature of knowledge management (cf. Davenport and Prusak 1998). For the field of project management, we suspect this portion is substantial because of project manage-ment’s relative youth and its highly interdisciplinary character. At this point in project management’s development, its knowledge base fits the contextual, evolving, and provisional nature of pragmatism better than the stable theories and law-like generalizations of positivism.

Exhibit 1. Horizontal and Vertical Processes

Horizontal and Vertical Processes

Approach of This Paper

Several authors have revived pragmatic concepts in the contemporary setting under new labels (e.g., “action theory” [Argyris 1982]; “reflective practice” [Schön 1983]; “reflection-in-action” [Senge 1990]). These provide some indications of the research and practice characteristics of a professional field that is grounded in pragmatism. The “theory” of project management is inextricably intertwined with its practice, and it is toward such practice that we look to understand the theory in this paper.

Specifically, through the lens of pragmatism, we look to orient project management theory through a dynamic model of knowledge flow. In gross departure from the kind of centralized, static and explicit knowledge formalized through the PMBOK® Guide,we instead view theory as decentralized throughout the practice of project manage-ment—reflecting an inherently dynamic concept—that recognizes the importance of tacit knowledge. Such knowledge, by definition, cannot be articulated and formalized through a repository such as the PMBOK® Guide,yet it is both integral and essential to the practice of project management. For instance, one finds such knowledge contained within the minds of experienced project managers, the very kind of people we prefer to assign to lead the most difficult projects. As another instance, one finds such knowledge embedded within the processes and procedures of first-rate project management organizations, the very kind of firms to which we prefer to award contracts for demanding project work. As a third instance, one finds such knowledge constantly changing, the kind of change that makes both individual and organizational learning across different projects so difficult.

This paper makes a contribution to the project management field by continuing the debate begun at the conference two years ago, and it furthers this debate through the articulation of an alternative path for project management research and theory-building. Coming at this point in time, the arguments advanced in this paper offer potential to help the project management field avoid some of the obstacles and pitfalls encountered through other social science disciplines, and it outlines a practical approach to integrating theory and practice. But it is important to understand that we are not arguing against the value of positivistic theory such as currently formalized through the PMBOK® Guide.Rather, we view pragmatism and the knowledge-flow perspective as complementary to the PMBOK® Guide, oriented toward gaining from knowledge and learning from lessons that may be too diffuse, dynamic, or tacit for capture through the PMBOK® Guide.

In the balance of this paper, we first provide discussion of a dynamic knowledge-flow model. We then instantiate this knowledge-flow model in the subsequent section to characterize project management in the Defense domain, and we close the paper with summarization of key conclusions and an agenda for future research along these lines.

A Model of Knowledge Flow

Using a pragmatic lens, the theory of project management is contained within its practice. Thus, the traditional model of knowledge flow—which is generally described as beginning with academic discovery and being transferred for practical application through education—is not unique in terms of project management. Rather, project management knowledge flows through a complex web of processes—processes that are distinct from, yet related to, the flow of work on projects. In this section, we draw from current knowledge management literature to describe a multidimensional model of knowledge flow. We first discuss interrelationships between the flow of work and the flow of knowledge through an enterprise. We then outline a knowledge-flow model, from current theory, for application to project management.

The Flow of Work and Knowledge

Building upon prior research (Nissen 2002), we begin to characterize a powerful interaction between the flow of work (i.e., workflow; cf. Georgakopoulos et al 1995) and the flow of knowledge (i.e., knowledge flow) in an enterprise. Following Oxendine and Nissen (2001), we refer to these respective flows as horizontal processes and vertical processes, as conceptualized in Exhibit 1. Briefly, the two horizontal directed graphs in the figure delineate separate examples of a work process (e.g., steps 1–6 as performed at different points in time, space, organization). The graph at the top of Exhibit 1 represents one particular example (e.g., project work performed at a specific point in time, location, organization) of this notional process, and the graph at the bottom represents a different example (e.g., project work performed at a separate point in time, location, organization).

Exhibit 2. Notional Knowledge-Flow Vectors

Notional Knowledge-Flow Vectors

Both horizontal graphs represent the flow of work through the enterprise. The vertical graph represents a complementary set of processes responsible for the flow of knowledge.The key is, knowledge is not evenly distributed through the enterprise, yet enterprise performance is dependent upon consistency and effectiveness across various workflows. The associated knowledge (e.g., process procedures, best practices, tool selection, and usage) flows across time, space, and organizations. Such cross-process activities are seen as driving the flow of knowledge—as opposed to the flow of work—through the enterprise. Indeed, Nissen and Espino (2000) identify seven vertical processes (e.g., training, personnel assignment, information technology support) that interact in a complex manner that is not reflected by the simple, linear flow depicted in the figure.

Alternatively, the flow of knowledge influences the flow of work, and the flow of work influences the flow of knowledge. In a pragmatic view, both flows constitute the development of theory, and the process of building theory—long viewed as the exclusive (i.e., positivistic) domain of academic research—is enmeshed in the complex web of dynamic interactions between horizontal and vertical processes. In the project management domain, substantial attention has been paid to horizontal processes. However, it is upon the vertical process flows that we concentrate in this research.

Knowledge Flow in Four Dimensions

Nissen (2002) builds upon the seminal work of Nonaka (1994) to develop a model of knowledge flow with four dimensions: 1) explicitness, 2) reach, 3) life cycle, and 4) flow time. The explicitness dimension represents the degree to which knowledge in some domain can be articulated. This dimension is characterized as a continuum with explicit knowledge and tacit knowledge as extremes. Explicit knowledge can be formalized through artifacts such as books, letters, manuals, standard operating procedures, and instructions, whereas tacit knowledge pertains more to understanding and expertise contained within people’s minds (cf. Polanyi 1967).

The reach dimension depicts the extent to which knowledge is shared with others in the enterprise (e.g., individuals, work groups, formal departments, divisions, business units, firms, business alliances, or networks). This dimension can also be characterized as a continuum (e.g., operationalized as the number of people affected by a particular chunk of knowledge), but we find it more informative to use organization-based aggregations of people (e.g., individual, work group, organization, interorganization).

Exhibit 3. Positivist Knowledge Flow

Positivist Knowledge Flow

The life cycle dimension derives from Nissen et al (2000) and characterizes the flow of knowledge through six discrete phases as it is managed in the enterprise: 1) creation, 2) organization, 3) formalization, 4) distribution, 5) application, and 6) evolution. Nissen et al note that only three of these six phases (i.e., organization, formalization, distribution) are supported well by information technology at present, whereas the other three phases (i.e., application, evolution, creation) are generally performed manually.

Finally, because knowledge flow represents an inherently dynamic concept, we include the dimension flow time to characterize the length of time required for a particular chunk of knowledge to complete its flow through an enterprise. Early results from empirical research (cf. Nissen 2001 for research agenda) suggest that knowledge flow times can vary by several orders of magnitude in the modern enterprise, so we operationalize the corresponding scale using highly-granular temporal markers (e.g., hours, days, months, years).

In Exhibit 2, we note a few, notional, knowledge-flow vectors for illustrating and classifying various dynamic patterns of knowledge as it flows through the enterprise. For example, the simple, linear flow labeled “P&P” depicts the manner in which most enterprises inform and train employees through the use of policies and procedures: explicit documents and guidelines that individuals in the organization are expected to memorize, refer to and observe. As another example, the cyclical flow of knowledge labeled “KMLC” in the figure reflects a more complex dynamic than its simple, linear counterpart. As a third example, Nonaka’s (1994) dynamic theory of knowledge flow, which is delineated in this space by the curvilinear vector sequence K-S-E-C-I (i.e., corresponding to the processes he labels “create,” “socialize,” “externalize,” “combine,” and “internalize,” respectively), can also be visualized through this model. Notice that we append the vector V (i.e., for evolution), which is not part of Nonaka’s theoretical model but reflects practical experience captured by the life-cycle dimension.

In terms of theory, the knowledge-flow dynamic is more complex. As seen with the vector sequence C-R-O-D-A in Exhibit 3, knowledge flow as delineated through the positivist perspective follows a helical trajectory. Beginning with the “creation” of knowledge plotted at the origin (i.e., Point C), such fundamental truth is seen as independent of people’s research or practical activities (i.e., it just is and awaits discovery). Scientific research (i.e., Point R) represents the deliberate actions of academics—generally working in groups—to formalize knowledge and make it explicit through theory. Such explicit knowledge is then organized (i.e., Point O) by the academy of a particular field (e.g., through journal publication, citation, critique), at which point it is deemed to be suitable for dissemination (i.e., Point D) beyond the academy. This represents the point at which knowledge is seen as flowing from theory to practice (e.g., through education) and becoming ready for practical application (i.e., Point A) at the individual level. Notice, once formalized through research, knowledge in this perspective remains explicit.

Exhibit 4. Pragmatic Knowledge Flows

Pragmatic Knowledge Flows

In contrast, the flow of knowledge associated with the pragmatic perspective is delineated in Exhibit 4 through multiple vector sequences, with each sequence corresponding to a specific vertical process. To avoid cluttering the diagram, we show only five selected vectors for illustration in this figure. The first vector, C-R-O-D-A, represents the same, positivist knowledge flow delineated above; that is, the pragmatic perspective also allows for knowledge to be acquired and transferred in the positivist tradition, but it includes other flows as well. For instance, the vector, E-F-T-A (illustrated with dashed vector arrows), reflects a pragmatic view of how formal training courses are developed; that is, the knowledge flow begins with individual experience that evolves through time (i.e., Point E). To develop a training course, a group of individuals—generally those with considerable experience and highly evolved knowledge—will formalize the evolved knowledge of select individuals to produce explicit training materials (i.e., Point F). Such materials are in turn disseminated through the organization via formal training courses (i.e., Point T). Knowledge acquired by students in such courses is then applied—in tacit form— by individuals in the organization (i.e., Point A’). Notice, this tacit application of individual knowledge differs from the explicit notion reflected by the positivist knowledge flow vector. Notice also how the training vector delineates knowledge flowing from tacit to explicit forms and then back again to tacit. This provides further contrast with the positivist flow schema.

Alternatively, the pragmatic perspective envisions several knowledge flows that are entirely tacit. For instance, the cyclical vector labeled “OJT” is used to represent the kind of onthe-job experience that is highly valued in most enterprises. Notice, this knowledge flows solely at the individual level as it cycles from knowledge creation through evolution via repeated OJT. Similarly, the cyclical vector labeled “CoP” is used to represent the kinds of communities of practice that tend to form among professionals in many fields. Notice, this knowledge flows solely at the group level as it cycles from knowledge creation through evolution within a particular community. Both the OJT and CoP flows are tacit and remain at a single reach level as they span the life cycle dimension through time.

Exhibit 5. Project Management Knowledge Flows

Project Management Knowledge Flows

Conversely, the vector labeled “Conferences,” while also entirely tacit, spans several levels of reach and life-cycle phases; here, the vector in the figure depicts the exchange of knowledge by various individuals and communities of practice through interorganizational conferences. Knowledge flows corresponding to other vertical processes can be delineated in our vector-space representation in similar fashion, but this should suffice to convey the key ideas and contrast the pragmatic and positivist perspectives.

Project Management Knowledge Flows

To make these ideas concrete, we illustrate the dynamic interplay between the complementary flows of work and knowledge pertaining to a software development project. Many different methods (e.g., waterfall, incremental, spiral) of software development have been developed and employed through practice, and given that software retains a considerable flavor of art and craft (STSC 2000), as well as engineering, it represents a good example for instantiation of our knowledge-flow model. We then discuss the implications of this example in terms of project management theory.

Software-Development Example

For illustration, consider a simple, linear development (i.e., the waterfall model) through five, sequential phases: 1) requirements, 2) architectural design, 3) software design, 4) coding, and 5) test. In terms of the workflow, it is straightforward to describe this process in terms of precedence relations; that is, in this example, software requirements precede architectural design, which precedes software design, and so forth. Again for illustration, we neglect more complex processes involving multiple iterations of and overlaps between phases. Also in this example, each phase culminates in a formal document (e.g., requirements specification, architectural design document) as output, with such output from one phase (e.g., requirements) providing the input to the subsequent phase (e.g., architectural design).

In terms of the knowledge-flow model, we delineate two distinct flows in Exhibit 5 using three dimensions: 1) explicitness, 2) reach, and 3) flow time.Here, we substitute the flow time dimension for its life-cycle counterpart (i.e., depicted in Figures 3 and 4) to highlight the dynamics of knowledge flow through this project example. The first flow, labeled R-A-D-C-T in the figure, depicts knowledge flowing in the highly explicit form associated with formal documents. Such explicit knowledge results as a direct product of the work flow. Referring back to the terminology introduced above, explicit knowledge associated with software documentation is formalized through the horizontal process corresponding to software development. The second flow, labeled r-a-d-c-t in the figure, depicts the complementary flow of knowledge acquired through vertical processes such as education, training, and work experience. We explain the plot positions for these knowledge-flow vectors in the following paragraphs.

Beginning with the explicit knowledge associated with software documentation, briefly, at every phase of software development, such formalized knowledge is highly explicit (i.e., plotted at the extreme end of the explicitness axis), and assuming that the customer receives the software documentation, such knowledge flows across organizations (i.e., plotted at the interorganization level along the reach axis). The only variation in plot position manifests itself through the dimension flow time, as flows associated with some project phases (e.g., requirements, architectural design) are illustrated as being accomplished in a matter of weeks, whereas others can require months (e.g., software design) and even years (e.g., coding, test). Clearly, however, this flow deriving from the horizontal process does not capture all of the knowledge required to effectively perform the software development project.

Alternatively, the complementary vertical-process flow of knowledge reveals a very different dynamic. The first flow pertains to requirements knowledge, which is plotted as Point r in the figure. Remember, this is the knowledge required to identify software requirements, not the work associated with articulating and documenting them. How is requirements knowledge acquired? Generally, a customer organization must develop good understanding of its business processes, objectives, and limitations in order to identify potential opportunities for improvement through software. Presuming that this takes place at the group level (e.g., a management team) in terms of reach, such knowledge is clearly very tacit, and we plot this flow at the magnitude of years in terms of flow time; that is, it generally takes relatively senior managers many years to acquire sufficient organizational experience and understanding to identify software needs. The other flows are plotted by following a similar logic.

Take the architectural design flow (i.e., Point a), for instance. Again, we refer to the knowledge required to design software architectures, not the work associated with creating such architectures. Such high-level design knowledge generally requires an advanced degree in computer science or related field, along with many years or even decades of experience with software development. Further, such knowledge is tacit and acquired by individuals. As another instance, software design knowledge (i.e., Point d) is similar, except that it has a more explicit component (i.e., plotted higher along the explicitness dimension) and a common knowledge base is required to be established across the design group (i.e., plotted at the group level along the reach axis). As with architectural design, software engineers may require degrees in computer science and many years of programming and design experience to acquire sufficient knowledge to produce quality designs (i.e., plotted at the years magnitude in terms of flow time). The other points (i.e., c and t) correspond, respectively, to explicit knowledge, acquired by individuals over a period of many months (or years) in terms of coding knowledge, and partially-explicit knowledge, shared by members of a testing group, that similarly requires several months (or years) to acquire.

Project Management Theory Implications

In terms of project management theory, several implications merit discussion. First, using a software development project for illustration, we identify two flows of knowledge through the enterprise that both enable and interrelate with the complementary flows of work associated with the software product. Because such knowledge flows are critical in terms of the corresponding workflows, the project manager should be just as concerned about the project knowledge as he or she is about the project work. But where in project management theory do we find such concerns addressed? For instance, is there a work breakdown structure associated with the knowledge flow to correspond with standard project management practice of developing such structures to organize workflows? What about similar development of Gantt Charts and Program Evaluation and Review Technique (PERT) networks? This appears to represent a “Greenfield” opportunity in terms of developing project management theory.

Second, we observe two, very different knowledge flows through our software-development example. In the case of explicit knowledge associated with formal documents, the flow is simple, linear, and confined to a single level in terms of both explicitness and reach. Such document-based knowledge derives from the horizontal processes associated with software development work itself, and we note that the output documentation of one project phase serves as the input documentation of the subsequent phase. Formal documentation along these lines is clearly important for project management, as such documentation is called for—and paid for—in most “well-managed” projects and represents “standard practice.” But notice that formal knowledge such as documentation results from the work, whereas the (more) tacit knowledge flows associated with the vertical process enable the work to be accomplished in the first place. In other words, the vertical-process knowledge flow (i.e., r-a-d-c-t) enables the software-development work to be accomplished, and such work produces the horizontal-process knowledge flow (i.e., R-A-D-C-T). Understanding the relations between vertical and horizontal flows of knowledge and work represents another “Greenfield” opportunity in terms of developing project management theory.

Third, returning to our pragmatic view of project management theory, one would have to conclude that at least part of the theory associated with the management of software projects is inherent in the practice, so our delineation of knowledge flows and work flows serves to highlight different aspects or modalities of such pragmatic project management theory. In other words, if the theory is reflected in the practice, and the practice is defined by the complementary flows of work and knowledge, then understanding such flows is central to developing theory. Yet how many project management researchers explicitly investigate such flows as a means to theory building? Only two (i.e., ourselves), we would submit.

Finally, by introducing this pragmatic, knowledge-flow perspective of project management theory, what implication does this have in terms of the theory-practice gap noted above? Recall that one of the motivations for considering pragmatism is to reduce—or even eliminate—this gap between scholars and practitioners, as theory can be built through practice as well as what most people would consider “normal science.” But few practitioners are even familiar with knowledge flows associated with vertical processes— much less active in managing such flows and processes—so the gap does not appear to be closing. Indeed, by introducing this pragmatic perspective and the associated knowledge-flow model, we may be widening the theory-practice gap. Alternatively, with every practical innovation and theoretical advance, it takes time for the corresponding new knowledge to diffuse through and be accepted by the many practitioners and scholars required for such innovation or advance to take hold. Our publication and presentation of this paper represents a first step toward such diffusion.

Conclusions and Future Research

A fork in the road lies ahead for project management research. On the one side, efforts such as formal theoretical research and the PMBOK® Guide reflect an inherently positivistic view of theory, and development of explicit knowledge in this manner enables all members of the field to view it in the same way. But theory-practice gaps have emerged in many “older” social science disciplines, with such gaps resulting in large part because of the positivistic approach to theory building. On the other side, a pragmatic view offers potential to eliminate this gap between theory and practice, but this latter view is far messier and more complicated in terms of what constitutes theory and how it is developed.

Learning lessons from other disciplines in the social sciences, this paper discusses a pragmatic view of project management theory and uses a multidimensional knowledge-flow model to articulate its practical and theoretical implications through examination of a software development project example. New insights into distinctions and interrelations between the flows of project work and complementary flows of project knowledge are introduced, and we use such insights to outline several overlooked issues for project management professionals, along with framebreaking topics for project management research.

Where does project management research go from here? We have identified some promising directions and contributed some new theoretical machinery to help researchers make the journey. However, the potential of such directions and efficacy of this machinery depend on how this work impacts other researchers in the field. To the extent that we are practicing what Kuhn (1970) refers to as “normal science” (i.e., the cumulative accretion of knowledge by researchers within an accepted paradigm; e.g., Newtonian physics), then these ideas should be easily understood and readily integrated into other work being undertaken by project management researchers. Alternatively, to the extent that we are discussing what Kuhn refers to as “revolutionary science” (e.g., as exemplified by the “paradigm shifts” from Newtonian to Einsteinian physics, or from Ptolemaic to Copernican astronomy), then the field may have to wait until theories comprising the current paradigm collapse under their own weight of inadequacy before these ideas get accepted, built upon, and integrated into the project management mainstream. Only scholarly discussion and practical application will determine the outcome. We are very pleased to begin such discussion and application through this paper.

References

Argyris, C. (1982). Reasoning, Learning and Action: Individual and Organizational.San Francisco: Jossey-Bass.

Cleland, D., R. Gareis, B. Hobbs, T. Kloppenborg, P. Morris, and M. Nissen. (2000, June). Future of project management research. Panel Disucssion. PMI Research Conference 2000 in Paris, France.

Davenport, T. H., and L. Prusak. (1998). Working Knowledge: How Organizations Manage What They Know.Boston, MA: Harvard Business School Press.

Dewey, J. (1998). The Essential Dewey, Vol. 1. Edited by L. A. Hickman and T. M. Alexander. Bloomington: Indiana University Press.

Dewey, J. (1929). The Quest for Certainty.New York:Minton, Balch.

Georgakopoulos, D., M. Hornick, and A. Sheth. (1995). An overview of workflow management: From process modeling to work-flow automation infrastructure. Distributed and Parallel Databases 3 (2): 119–153.

Kuhn, T. S. (1970). The Structure of Scientific Revolutions, 2nd ed. Chicago: University of Chicago Press.

Miller, H. T., and C. S. King. (1998, March). Practical theory. The American Review of Public Administration 28: 43–60.

Nissen, M. E., and J. P. Espino. (2000). Knowledge process and system design for the coast guard. Knowledge and Process Management Journal 7 (3): 165–176.

Nissen, M. E., M. N. Kamel, and K. C. Sengupta. (2000). Integrated analysis and design of knowledge systems and processes. Information Resources Management Journal 13 (1): 24–43.

Nissen, M. E. (2001). Toward a program of research on knowledge flow in the very-large enterprise. Naval Postgraduate School NPS Technical Report NPS-GSBPP-01-003:Monterey, CA.

———. (2002). An extended model of knowledge-flow dynamics. Communications of the Association for Information Systems 8: 251–266.

Nonaka, I. (1994). A dynamic theory of organizational knowledge creation. Organization Science 5 (1): 14–37.

Orr, J. (1996). Talking about Machines: An Ethnography of a Modern Job.Ithaca, NY: IRL Press.

Oxendine, E., and M. E. Nissen. (2001). Knowledge process and system design for the naval battlegroup. Journal of the KMCI 1 (3): 89–109.

Pinto, J., K. Artto, E. Larson, R. Lundin, K. Snider, and A. Stretton. (2000, June). Theory of project management. Panel Disucssion. PMI Research Conference 2000 in Paris, France.

Polanyi, M. (1967). The Tacit Dimension. London: Routledge and Keoan Paul.

Schön, D. (1983). The Reflective Practitioner. New York: Basic Books.

Senge, P. M. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization.New York:Doubleday.

Slevin, D., D. Cleland, and J. Pinto, eds. (2000). Project Management Research at the Turn of the Millennium: Proceedings of the PMI Research Conference 2000.Newtown Square, PA: Project Management Institute.

STSC. (2000). Guidelines for Successful Acquisition and Management of Software-Intensive Systems.Hill AFB: Software Technology Support Center.

Stumpf, S. E. (1966). Socrates to Sartre: A History of Philosophy.New York: McGraw-Hill.

Proceedings of PMI Research Conference 2002

Advertisement

Advertisement

Related Content

  • PM Network

    Moment of Truth member content open

    PM Network queries the project management community about lessons learned.

  • PM Network

    El momento de la verdad member content open

    PM Network consulta a la comunidad de gestión de proyectos sobre las lecciones aprendidas.

  • PM Network

    Momento da verdade member content open

    PM Network consulta a comunidade de gerenciamento de projetos sobre as lições aprendidas.

  • Project Management Journal

    Major Knowledge Diffusion Paths of Megaproject Management member content locked

    By Wu, Hengqin | Xue, Xiaolong | Zhao, Zebin | Wang, Zeyu | Shen, Qiping | Luo, Xiaowei This article integrates social network analysis and main path analysis to investigate progress in megaproject management (MPM) from the perspective of knowledge diffusion. After measuring three…

  • PM Network

    10 Lessons of the Most Influential Projects member content open

    By Prashara, Sunil There are many lessons to be found in the Most Influential Projects. We've pulled out 10 of them from the Top 50 list. We encourage you to consider (and even circulate) your own lessons. What's…

Advertisement