Using Process Theory for Accumulating Project Management Knowledge

A Seven-Category Model

Fred Niederman, Saint Louis University, Missouri, USA

Salvatore T. March, Vanderbilt University, Tennessee, USA

Benjamin Müller, The University of Groningen, The Netherlands; Karlsruhe Institute of Technology, Germany


Process theory has become an important mechanism for the accumulation of knowledge in a number of disciplines. Process theory focuses on sequences of activities, their durations, and the intervals between them, as they lead to specific outcomes. Thus, process theory is particularly relevant to project management knowledge representation and accumulation. We present a seven-category model that specifies different formulations of process theory, explaining how it can be applied and leveraged to accumulate knowledge, specifically within project management research.

“… You simply don't go out and do a piece of work. No, the first thing you do is determine the lengthy sequence of activities necessary even to begin the job. Then you realize that the sequence of preparatory activities is so long you will never get to the intended task. So you go fishing instead.”

Patrick F. McManus (1989, p. 1) “Sequences” in The Night the Bear Ate Goombaw

KEYWORDS: process theory; theory building; knowledge accumulation; risk management

Project Management Journal, Vol. 49, No. 1, 6–24
© 2018 by the Project Management Institute
Published online at


Managing projects is a complicated and challenging endeavor. Humorist Patrick McManus has hit a raw nerve in the field: although project management has long been the subject of research, we have yet to develop a theoretical underpinning for our array of piecemeal understanding (Reich et al., 2103). We contend that conceptualizations from process theory provide a potentially valuable addition to formalizing knowledge accumulation in the field.

Despite project management's significant impact on business and society, there is much room for improvement (e.g., Johnston, 2014; Cerpa & Verner 2009; Shaw, 2012; Widman, 2008; Shenhar & Dvir, 2007). As noted by Padalkar and Gopinath (2016), project management is “an established discipline with well-subscribed bodies of practitioners and commonly accepted methodologies and standards …” that suffers from a “weak theoretic foundation” (p. 1305). Reich et al. (2013) argue that, despite a rich literature, there is a perceived void between the body of successful project management heuristics and the theoretical pantheon of project management research. Project management has yet to develop a theoretical underpinning.

The central goal of research in fields of practice such as project management is to accumulate knowledge that is both conceptually rigorous and useful in application (e.g., Benbasat, 2001; Benbasat & Zmud, 2003; Keen, 1980; Van de Ven, 1989). Against this challenge, the accumulation and dissemination of project management knowledge has long offered multiple promising benefits: (1) increased predictability that the application of particular interventions will generate successful outcomes, (2) increased confidence that the selection of particular interventions will better suit the circumstances being faced, and (3) ensuring that lessons will be learned from experience, with the application of such lessons leading to an upward spiral of increasingly positive outcomes (Crawford, 2006; Diesing, 1992;Keil & Robey, 1999).

To accelerate the realization of these benefits, we must transition from idiosyncratic heuristics to more general statements or “theories” applicable to a wide range of project management efforts. In this way project management can grow from a craft with individual mastery into a well-understood discipline with established knowledge for effective planning and successful execution of projects. This motivation has long been at the heart of project management's key professional bodies and is a critical ingredient to the emergence and evolution of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (Project Management Institute, 2013).

In this article, we propose expanding the use of process theorizing in project management–related research. To support this effort, we examine current instances of process theory, largely in the general management literature, and present additional process theoretical perspectives in a seven-category model. We illustrate the potential application of each category using an extended hypothetical illustration based on project risk management. Subsequently, we address a variety of implications and practical issues involved in the assimilation of process theory in project management research and practice. Finally, we discuss implications of our model for project management research and practice.

Process Theory in and Beyond Project Management

Conceptual Background

Before discussing process theory's potential benefits for project management research, we briefly reflect on the basic concepts of “theory” per se. While the debate on what “theory” is and what role it plays in scholarly work is long-standing and diverse (see, e.g., Bacharach, 1989; Gregor, 2006; Mueller & Urbach, 2013; Weber, 2012), we define theory simply as a set of statements that relate antecedents to consequents.1

In terms of its general role in scholarly work, theory can be understood as a mechanism for accumulating knowledge. It does so by formulating statements in such a way that they can be tested with observations tied to practice or laboratory settings (Lakatos, 1970). By providing a mechanism for stating what is known or believed, theory can be used to describe relationships or patterns that occur and recur in the world in a testable format, with the results of each test being used to support, challenge, or modify prior understanding. Thus, the point of theory in a discipline such as project management is not in finding “absolute truths” as it might be in the natural sciences, but rather in building ever increasing bodies of useful knowledge (March & Smith, 1995). At their best, theories enable practitioners to apply general knowledge to their particular case, and by doing so, increase the probability of achieving desired outcomes (Van de Ven, 1989).

While there are numerous perspectives about theory (see, e.g., Burton-Jones, McLean, & Monod, 2015), two types of theory are frequently differentiated: variance theory and process theory (e.g., Mohr, 1982; Sabherwal & Robey, 1995). Variance theory focuses on co-variation of dependent and independent variables. Although not typically acknowledged as such, it is the most commonly applied paradigm in project management research (see, e.g., Hanisch & Wald, 2011). In contrast, process theory focuses on sequences of activities, their durations, and the intervals between them, as they lead to particular outcomes—both intermediate and final (e.g., Alin, Maunula, Taylor, & Smeds, 2013; Koskinen, 2012). Looking at the basic definition of theory stated above, antecedents in a process theory can include preceding states or other processes (i.e., sequences of activities or actions with intended outcomes), in whole or in part. Consequents can include states (intended and unintended), attributes, or even work products. Each of these types of antecedents and consequents are found in phenomena that are of interest to researchers and practitioners in project management. Part of the attractiveness of process theory for application in project management is that it seeks to explain and predict how and why temporally evolving phenomena “unfold over time” (Bizzi & Langley, 2012, p. 225), a goal we see strongly resonating with project management research.

Thus, process theory is a powerful companion to variance theory, particularly relevant to project management knowledge accumulation; we argue, however, that a fresh look at process theory for work in the project management domain is needed for two reasons:

1. To date, most process theory studies have used retrospective methods to examine the antecedents that were deemed necessary to produce the observed process outcomes. While this approach has yielded valid and useful insights, we maintain that it does not represent the full range of how process theory may be effectively applied; and

2. By emphasizing forward-looking, prescriptive approaches, we hope that a broadened view of process theorizing will enable research that provides a basis for our understanding of project management work and improves our ability to apply this knowledge in practice.

Thus, we propose a model of process theory that highlights and specifies seven different process theory formulations. In a broad sense these can be viewed as progressive in that some categories have more breadth and detail, but each category is self-sufficient in presenting a particular type of process theory—each links particular process formulations with outcomes in a testable framework.

Foundations of Process Theory

In general, process theory focuses on explaining and understanding how particular outcomes (i.e., states) emerge from a sequence of actions (i.e., activities or choices by one or more actors) and events (i.e., planned and unplanned occurrences), taking into account particular inputs (i.e., triggers, context). Depending on the level of abstraction of a specific process, related theory may also specify intermediate states that emerge in such a sequence (both intended and unintended) and how these intermediate states contribute to the progression of events toward the overall outcome—project management outcomes can be the result of a complex network of events. It is important to keep in mind, however, that process theory is not itself a “theory” in a narrower sense, but rather a type of logical meta-model or conceptual framework for theories or for theorizing (Mueller & Urbach, 2013). Thus, process theory can facilitate the development of specific theories (Mueller & Urbach, 2013; Ritzer, 2001). For example, a theory about the effects of stakeholder involvement in project risk management can follow a process theoretic logical structure, but process theory in itself says nothing about risk management or stakeholder involvement.

This general structure retains the fundamental components of process theory (e.g., as presented by Van de Ven & Huber, 1990), which is:

1. Inputs, understood as antecedents or states that precede the beginning of the process;

2. Actions and events occurring in the process, in other words, the activities performed and the resultant intermediate states and the intervals between them, which comprise the process; and

3. Consequents, understood as final outputs, in other words, new states following from performance of the process whether actualized perfectly or imperfectly.

Further, we define actions as activities performed by an actor with the intention of bringing about a new state relative to the phenomenon of interest. In contrast, we define events as state changes that may or may not be brought about (or intended) through the actions of the actor. We note that some actions may change all relevant states, some relevant states, or even none of the relevant states (where such states are viewed as the collection of values relative to multiple attributes). For example, the action of elevating an employee to project manager may change (1) both morale and productivity within a project team; (2) either morale or productivity, but not both; or (3) neither morale nor productivity.

Process theories have been used to propose how and why a consequent state emerges. Researchers have previously developed process theories by analyzing critical incidents (sequences of states, actions, and events) preceding the key consequent of interest through a sort of reverse engineering; that is, analyzing which events and actions preceded the final consequent (state) and then working backward gradually until an initial antecedent or cause (or a set of causes) is identified (see, e.g., Poole, Van de Ven, Dooley, & Holmes, 2000). In this way, process theories develop an in-depth understanding of the states, actions, and events themselves and the conceptual links between them. Thus, the intermediary consequents of preceding events and actions become causes or antecedents for subsequent events and actions, even though such transitions may not be automatic or instantaneous. At the same time, it is important to note that consequents need not be restricted to those that manifest physically (e.g., a work order issued or a document created), but may also refer to latent concepts (e.g., a state of consensus achieved among a group of principal actors). Indeed, such latent states could be much more important in explaining the progressive pattern of a process than any of the manifest outcomes of any one action or event in it.

Figure 1 provides a general depiction of a process theory's logical structure. We note, of course, that actions, themselves, may be complex and that the level of decomposition is determined by the research question addressed. We further note that actions may occur in parallel and that some may cause more than one event, each in turn causing more than one further action to be performed. For simplicity, these actions are not represented in Figure 1. Sample theory statements are (where A, B, and C are activities, E1 through E6 are events, and O1 and O2 are outcomes):


Figure 1: A general view of a process theory's logical structure.

1. Path 1 will lead to (higher, lower) values of O1 than Path 2 or Path 3

2. Path 2 will lead to (higher, lower) values of O1 than Path 3

3. Path 1 will lead to (higher, lower) values of O2 than Path 2 or Path 3

4. Path 2 will lead to (higher, lower) values of O2 than Path 3

Each rectangle represents a single process or “pathway,” where activities are shown as labeled ovals and events (and outcomes) are shown as squares. Arrows indicate sequence of performance and their length indicates an interval of time. The size of the ovals could be used to further show duration of the activity, but are held constant in this diagram to reduce complexity.

Process theories can address processes as “wholes” (black box) or as “parts” (white box). When a process is viewed as a whole, a black box—its elemental sequence of actions, events, and intermediate states—is considered to be integrated and subsumed, constituting a single antecedent. Alternatively, a process may be transparent, a white box—with each action, interval, event, and state occurring during each interval, and their sequence duly reported and available for investigation. Furthermore, a process may be associated with multiple consequents, typically reflecting particular outcomes such as measures of the resultant state or production of deliverables.

At its simplest, a process theory can specify a sequence of events and actions that, in at least one case, lead to a particular outcome. Alternatively, it can specify in detail the nature of various events and actions (suggesting possible alternative ways actions might have been implemented), the attributes of intervening states that may be necessary or helpful for enacting subsequent actions and achieving ultimate outcomes, defining a particular sequence of actions, and possibly describing the timing influencing both chosen and determined intervals between actions. Using such an approach results in the creation of one or more theories, each stated in a testable format. This enables both replication and potential refinement. For example, other projects can follow the process actions to test whether they achieve the same results. Additionally, variations of the process actions can be undertaken to see how robust the original process is to variation and to contrast the varied process alternatives based on their differentiation in outcome created, cost, risk, duration, and the like.

While there may be significant practical value in simply replicating an effective sequence of actions, there is a danger that such prescriptions “[…] are reduced to a series of steps executed by rote (Highsmith, 1999, p. 14).” Such reduction may result in undesirable outcomes, particularly if intermediate states and events are not understood. In such cases, “white box” investigation, decomposing the process into its actions and intervals, can be used to develop greater understanding of intermediate states and explanations of “why” sequences of actions are effective in whole and in part. Such explanations can help shape and improve how each action is implemented and perhaps lead to better alternative processes.

Extant Process Theory in the Project Management Literature

Process theory, as generally conceived in the management and information systems literature (e.g., Bizzi & Langley, 2012; Langley, 2009; Mohr, 1982; Pettigrew, 1990; Pentland, 1999; Sabherwal & Robey, 1993; Poole Van de Ven, Dooley, & Holmes, 2000; Markus & Robey, 1988; Paré, Bourdeau, Marsan, Nach, & Shuraida, 2008; Soh & Markus, 1995) is largely unknown in the project management literature. A search of Project Management Journal® (PMJ), using the term “process theory,” yielded a total of six articles published in the past 20 years (out of 1,079 articles published in that timeframe). Of those, Eskerod and Vaagaasar (2014) did not use process theory in their study but suggested it could be drawn upon in future research. Another study, by Shenhar and Dvir (2007), develops three views of project management research: the strategic/business view, the operational/process view, and the team/leadership view. Although suggesting “process theory” as an underpinning of the operational/process view, the emphasis of that view is on mathematical optimization techniques. Following Shenhar and Dvir (2007), Hanisch and Wald (2011) propose a framework for thinking about project management research and, again, consider “process theory” as a mathematical optimization paradigm, not as a general theoretical paradigm. Baroudi and Metcalfe (2011) take a systems perspective (Burton-Jones et al., 2015), noting simply that problem situations, particularly in projects, can be viewed as transformative processes and use that notion as the basis for interviewing project managers to determine how problems in project prequalification systems were identified and addressed.

Hence, only two articles published in PMJ® over the past 20 years present a theoretical abstraction of project management–related insights based on process–theoretical thinking in a substantive way: Alin et al. (2013) and Koskinen (2012). Using an embedded case study approach, Alin et al. (2013) develop a process-based model of inter-firm process alignment, consisting of three activities: “task sequence alignment, knowledge base alignment, and work allocation alignment” (p. 86), noting that coordination of these three activities is crucial throughout the life of the studied project. They conclude, however, that their model “has limited empirical generalizability: ‘We do not wish to make the argument that all systemic innovation implementation cases in project networks would follow the linear path suggested by our model’ (p. 90).” This, of course, highlights the challenges of testing process theories that have been developed through retrospective analysis, as we discuss below. It also suggests potential value in actively replicating the “linear path” suggested by the model to observe whether the same results are produced.

Koskinen (2012) applies process thinking to organizational learning in project-based companies. We fully concur with the underlying premise of this work (p. 41): “Although a traditional project model [i.e., a variance theory approach] is clearly useful for laying out the patterns of relationships surrounding a project, it does not provide the temporally embedded accounts that enable us to understand how such patterns come to be; therefore, a more extensive process thinking practice is needed.” We extend this work by more generally describing process theory within the context of project management, offering descriptions and prescriptions for its application.2

A further examination of the project management research reveals several examples of nascent process theoretical papers that stop short of proposing fully developed process theories. This is exemplified by Midler and Beaume (2010) who define three approaches or patterns of new automobile development projects (concept cars, derivative projects, and vanguard development projects) and consider more specific actions and events that trigger learning across and within these different project types. More detailed specification of the actions involved in learning, assessment of the amount of learning from different action sequences, comparisons across pattern type, and statements of findings in a testable format would generate a process theory in this context. An example of such a statement, based on their findings might be: “Learning occurs more quickly in a ‘multi concurrent projects’ program than it does with ‘a vanguard project approach’.” In this, it is important to think of the different project types not as a mere dummy variable for one or the other, but to think of these project types as processes consisting of ordered actions and the intervals between them. Such a formulation leads to questions about other approaches to projects, to more detailed specifications of actions, and to reflections on which of these actions is most linked to the desired outcome of learning. It also opens up opportunities for consideration of other outcomes such as cost, duration, and quality of product.

We also find papers in which a process theory can be inferred, but is not explicitly stated within the paper. For example, Keil and Robey (1999) develop a process model of project de-escalation by identifying actors and the actions taken to address troubled IT projects (also see Keil & Montealegre, 2000). This work proposes that de-escalation begins with an actor detecting negative information about a project, communicating that information to another actor “in authority” who then either continues the commitment of resources to the project (escalation) or takes action to redirect or terminate the project (de-escalation). Their contribution provides an implicit process theory, suggesting that in at least some cases a particular outcome—project de-escalation—follows a stated sequence of actions. We consider these findings as “process theory” in that they link a set of actions and events to a particular outcome, even though the deeper conceptual linkages of how and why these are linked across time to produce the desired consequent can only be inferred from the authors' writing.

In another example, we find a relatively sophisticated implicit process theory. Gallivan and Keil (2003) conclude that “despite the appearance that the project manager and the developers did everything right in terms of ensuring high levels of user participation, the resulting system never achieved true acceptance, because several essential stages of user–developer communication failed to occur in an effective manner” (p. 38). Implicit in this statement is a process theory: that a particular set of actions, taken in a particular order should lead to a desired outcome; in this case, actions taken to achieve high levels of user participation should lead to user acceptance. However, the authors' findings suggest either that some of the actions did not include the appropriate sub-tasks, that the actions were not fully implemented, or that the actions, while undertaken properly did not lead to the necessary intermediate event required for subsequent activities to be in a position to produce intended outcomes. Phrased in terms of explicit process theory, such findings would be more transparent for further investigation into what content would best serve each step, in what sequence these actions would be best performed, and whether achieving precursor states may be equally or more important than following the actions per se.

This idea is reinforced by Majchrzak and Beath (2000) who argue that “user participation,” per se, is not the critical factor, but rather it is the process of user participation (negotiation, collaborative learning, and cognitive elaboration) that leads to positive project management results. This type of theorizing makes it clear that process theory strives to go beyond processes as a black box, as noted, by decoding which of the actions or events in a sequence truly contributed to the emergence of a desired outcome and why so. Markus and Mao (2004) underline that a process theoretical approach is valuable for theorizing phenomena such as user participation and its impact on project success. They argue that the relationships between participation activities and outcomes are emergent and mutually influential, rather than necessary or deterministic. We concur; phenomena in which humans are active, intentional participants rather than passive objects, will always retain some measure of agency and thus a degree of unpredictability in the outcomes that follow.

This conceptualization resonates with many professional domains and the project management domain in particular. Over the last decades, project management has witnessed a perhaps unparalleled professionalization through the systematic gathering and synthesizing of best practices. The resultant PMBOK® Guide – Fifth Edition (Project Management Institute, 2013) is a rich documentation of recommended practices, often detailed as a set of activities ordered in a particular sequence, which are at least implicitly thought of as promoting successful execution of projects. We argue that, while such a collection of recommended or even good practices is an invaluable resource for the professionalization of project management, a more formal theoretical foundation is needed (Reich et al., 2013).

We argue that process theory can help to provide this foundation in two ways: First, by formalizing a maturing process through which extant project management knowledge can be extended to link to full-blown theory. Second, by identifying the various facets that theory needs to deliver if it is to be valuable in its application in practice. For this, however, we contend that the extent of process theory application does not yet match its potential for positive contribution to the field. Thus, we propose a set of extensions to process theory, described using a seven-category model presented in the next section.

Process Theory for Project Management Research

To illustrate the utility of process theory for project management research, we propose a novel model that breaks the overall concept of process theory down into seven categories summarized in Table 1. This model expands the traditional process theory conceptualization as described above and illustrated in Figure 1 by providing a refined perspective. The model's refinements are derived from examining the various components of a process from a systems perspective (initial conditions, transformation through an action sequence, and overall outcomes), where the system is evaluated in terms of the output produced. Each category is designated in parentheses in Figure 2. The initial, baseline category views a process as a “black box” that has been shown to produce a particular result (output), considered as a whole, with a single performance measure, under the given (input) conditions examined by the researcher. This is illustrated in Figure 2 as the Input consisting of a Fixed Initial State (prescribed or observed by the researcher), a Black Box Process and a Fixed Single State the Output; in other words, one factor (labeled [1] in Figure 2). Subsequent categories expand that perspective first by recognizing that outcomes are not monolithic. Multiple outcomes and performance measures may need to be considered (labeled [2] in Figure 2). Next the “black box” is opened in a variety of ways: variation of actions within a process, variations of action sequences, variations in intermediate states (events) and in the intervals between actions (labeled [3] through [5] in Figure 2), and the potential of intermediate states to influence subsequent ones (labeled [6] in Figure 2). Finally, we consider extension of the theory across multiple or larger domains; in other words, a “wider system” model (labeled [7] in Figure 2). Each category, we argue, is rightly titled theory, because it links antecedents with consequents.

In Table 1 we describe each category and how a particular theory could be developed and stated within each category. Following this overview, we illustrate the use of this model through a discussion of its application in project risk management.

The Seven Categories

We propose a “category one” process theory (Figure 2) based on the relationship between a process defined as a set of steps and the observation that at least one instance following this process has led to a particular outcome (see Table 1). In general, this can be specified as: “Process X can lead to Outcome A.” In some instances of practice, particularly when dealing with innovative or exploratory domains, knowledge that a process can create a particular result is of significant value. Knowing, for example, that using an agile development process can create positive outcomes doesn't ensure that it will in the next particular instance, but does demonstrate that it has potential. This can be motivating for individual companies or project managers to experiment with new techniques. By the same token, we can see that this is a relatively “sparse” theory, because we have not shown that implementing this process necessarily increases the probability of successful outcomes, that it can be repeated, or what sort of complementary actions or environmental states are necessary for it to be effective. From a more abstract perspective, we have not begun to explain how such a process might create its intended outcomes.

Category Theoretical Focus General Theoretical Statement
1 Feasibility A process has produced a specific result in at least one case
2 Outcome trade off A process produces multiple results
3 Action variability Variations in process actions result reliably in the same or systematically varied outcomes
4 Sequence variability Variations in process action sequences result in the same or systematically varied outcomes
5 Interim state identification A sequence of actions is associated with a related set of intermediate states
6 Interim state requirements Achieving particular intermediate states is necessary for achieving a particular overall outcome
7 Transferability A process produces particular results across a range of domains
Table 1: The seven categories of process theory.

Figure 2: Process theory facets: Related category in parenthesis.

A “category two” process theory adds the differentiation of multiple outcome measures. Such a process theory adds acknowledgment of the tradeoffs that derive from instituting a process. In general, this can be specified as: “Process X can lead to Outcomes A and B.” In some instances of practice, this can provide particularly important information for organizations in assessing whether they want to commit to a new process. For example, using an agile development process is likely to show that functionality can be added quicker and with more likely user acceptance (outcome A), but at a cost of less scalability, security, and documentation (outcome B). This can indicate the sort of applications where an organization would or would not want to use this method in its own context. Customer facing applications for example, may benefit from such an approach more than would platform or infrastructure projects. Clearly, while there can be benefit in either context, the added richness of seeing tradeoffs shows the potential for this type of process theory to present more leverage for organizational decision making. It seems quite likely that researchers could build this level of theorizing upon extant category one theory or, conceivably, develop category two theory by attentive measurements of multiple outcome dimensions directly in a single study. It is conceivable that a particular process will have only one positive (or negative) outcome, but considering multiple outcomes adds conceptual theoretical value.

A “category three” process theory shows how varying the characters of actions in the process produces different results. Such a process theory adds acknowledgment that there are options regarding the nature of each step. In general, this can be specified as: “Process X consisting of actions 1, 2, and 3 will produce better Outcomes A and B than will Process Y consisting of actions 1, 2, and 3.” For example, let us suppose that we observe alternate ways to enact one particular step. We may use these alternatives to define contrasting processes. In a simple example, we could substitute screen mock-ups for working prototype screens in a business intelligence project. In this way we can contrast the outcomes of processes X and Y in terms of our defined outcomes (e.g., comparing system quality or user satisfaction working for screen mock-ups versus prototype screens). In some instances, we might find only one net outcome variable (resembling category one) but often in practice we can build on multiple outcome variables (following category two). Note that we might find that screen mock-ups take less time, but result in lower user satisfaction and buy-in, although the quality of the resultant system could be the same. All of this provides information for establishing statements about the contrasted effects from related processes where the method of enacting a particular step differs.

We observe that each step in each process is subject to countless possible variations in execution. This results in a combinatorial explosion of possible cases to test. We recognize that it is likely impossible to test all cases; thus we may never have certainty of optimal processes. However, with time, our knowledge base can grow and move toward stronger accumulation of knowledge. That is the benefit of using theory to represent knowledge: the theory can be used by other researchers to confirm, refute, or modify the knowledge base. An appropriate strategy would be to (1) document the actual actions invoked in a process instantiation; (2) vary actions where improvements or differentiation in outcomes appear logical relative to the existing base of knowledge; and (3) create awareness of how differences in outcomes may be accounted for by differences in context or other influential factors. Contrasting the outcomes of these with organizational norms can produce new insights, for example, robustness of the process, or particular circumstances where alternative processes show better results. This process can be augmented with efforts to understand the “why” or “how” of each step, thus providing input to the next iteration. Such explanations can lead to (1) elimination of actions unlikely to produce the desired intermediate states and (2) creation of new actions that create intermediate desirable states even if not formally prescribed in the theory statements. Note that such explanatory knowledge should be fed back into the formulation of the theoretical statements. As explained by Lakatos (1970), it is possible to think of research programs rather than individual studies, considering each individual study as the best possible thinking that incorporates past experience with the expectation of future improvement with continued observation, comparison, and judgment.

A “category four” process theory addresses whether variations in the sequential order of actions in the process leads to varied results. Such a process theory will only be possible when each step is not fully dependent on its predecessors. For example, we cannot paint the lines on a road that is not yet paved; however, other actions may be conducted in a particular order out of initial trial and error followed by inertia without knowledge of whether or not the particular sequence provides distinct advantage relative to (largely untested) alternatives. In general, this can be specified as: “Process X consisting of actions 1, 2, and 3 will produce better Outcomes A and B than will Process Y consisting of actions 1, 3, and 2.” We can also use this approach to test the outcomes of parallel versus sequential action taking. In general, performing independent tasks simultaneously shortens time to completion, however, it may also increase the number of resources, particularly laborers, needed during the action taking which may or may not be constrained by available resources. These general principles, however, may be forced to yield in light of the specifics of particular action combinations. For example, where coordination is automatically generated by sequence, performing actions in parallel has the potential to create problems in fitting together non-aligned action deliverables. We see this in information systems (IS) development, where breaking a program into modules allows simultaneous creation of modules but may result in added work reintegrating these components into a full system.

A “category five” process theory identifies and defines states that can be associated with intervals between actions. Such a process theory will identify interim results at a minimum but provide thresholds of states required for further actions to provide more predictive or prescriptive theory. In this theory type, initially interim states are observed to exist between actions. For example, if the first step in scheduling is producing a work breakdown structure or list of tasks, a logical second step would be estimating durations for each task, followed by a third step of identifying dependencies and transforming the list into a network representation. Note that between each step we can identify measurable states that will exist, though particular thresholds required for successful execution of subsequent steps need not be specified. For example, following the identification of tasks, there exists a state of “completeness” of the said list; following estimation of duration there exists a state of “exactitude” relative to the individual estimates and their collected totals; and following the transformation to a network there may be states of complexity or calculable by-products such as its critical path. Note that the first key to this category is the specification of these states. However, the quality with which tasks are conducted can, in principle, be calculated for each interim state, for example, identification of tasks is complete, durations are reasonably accurate, and dependencies are identified or selected (since some may be due to preference rather than physical requirements). These identified characteristics may be measurable during the interval states between tasks and their level may lead to (1) ability (or inability) to perform the next task; (2) quality enablement or constraint of subsequent tasks; and or (3) observations of alternative sets of actions or pathways toward completion of the ultimate objective. In general, this can be specified as: “Step 1 in Process X leads to State 1; step 2 can (or must) be preceded by State 1; step 2 leads to State 2; step 3 can (or must) be preceded by State 2.” Ideally, a category five process theory will specify all actions and intermediate states, however, we do not assume that early observation would necessarily fill all gaps between actions with state specifications nor that all attributes of the interim situation will be relevant or helpful.

A “category six” process theory identifies and defines actions, states during intervals, and/or particular action sequences that are required between actions to create particular results. The key notion of this category revolves around the essential nature of the action, interim state, or sequence. It is likely that such knowledge, while it may originate in a retrospective study, will not be highly supported until testing can show that alternative actions, states during intervals, and/or action sequences do not work to produce the intended results. For example, in the context of software testing within IS development projects, we can project a reasonable sequence where unit testing must be completed to a threshold of a bug-free code before integration testing can effectively begin; where integration testing must be completed, similarly, to a threshold of operation, before customer usability testing begins. Note that this seems a reasonable possibility, but without testing in practice we cannot know if it is always the case, usually the case, or filled with exceptions of various kinds. It is exactly the purpose of process theory to identify and propose such formulations and advocate their testing and from which we expect our accumulation of knowledge to grow. In general, this can be specified as: (1) To be effective, process X must include steps a, b, and c; (2) to be effective, process X must produce interim results of a defined threshold between steps a and b and between steps b and c; and/or (3) to be effective, process X must proceed in steps a, then b, then c, in sequence. Note that with even more information, these can be combined into more complex statements ultimately of the form: (4) to be effective, process X must include steps a, b, and c; producing defined thresholds of accomplishment between each, and can only be done in that order.

A “category seven” process theory extends the specificity of a particular domain to one or more additional domains. For example, the process of risk management for projects pertaining to information technology development might be extended (perhaps with modification if found to be necessary) to R&D projects, organizational transformation projects, and perhaps even construction projects. Such extension could result, in principle, in theory that addresses all situations when a future-looking management of potential adverse effects is relevant. The value of such theory would be in allowing each application to address current known problems within the range of domains. It would also provide a starting point for any new situations, perhaps resulting from new affordances of future technology evolution, where risk management would be of potential benefit. A general formulation of a theoretical statement illustrating this category can be built from any prior theoretical category. For example, using a category one formulation, “Process X can lead to Outcome A for information technology and R&D projects.”

Application of the Seven-Category Model to Risk Management

Consider the following hypothetical process for addressing project risk. First, we construct a list of all imaginable independent risks. Second, we assign a probability to each. Third, we assign a likely cost should the risk materialize (exposure). Fourth, we multiply the probability times the cost for each identified risk to produce the expected cost of each risk. Fifth, we sort the list of risks from the highest to lowest expected cost. Sixth, we devise a backup plan for the top third of the list in anticipation that the risk is manifest. Seventh, we keep the middle third closely at hand for routine monitoring. Eighth, we drop the bottom third as being of less value to monitor than to simply adjust to if necessary. Finally, ninth, we progress through the project eliminating from our list those that do not manifest, quickly implementing backup plans for the top third if they occur, and watching for the middle third for ad hoc response if they occur, until the project is finished.3 To evaluate the process, we check the realized cost, duration, and quality of the resultant product against those that were anticipated.

As a “category one” process theory (Figure 3) this might be specified as: “Risk management can lead to positive net project outcomes” (where risk management is not to be seen as a monolithic construct, but as part of the aggregate, but black-box, sequence described above and confidence in ability to prioritize risk is viewed as a positive project outcome). Presumably, this nine-step process has been purposefully designed and executed in the hopes of creating positive outcomes or has been developed by “reverse engineering” a successful project. Such a theory signals that risk management, as defined by this sequence of actions, has the potential to stimulate positive outcomes. Where there aren't many alternatives, this may be enough to trigger proactive managers to begin using this process and adapting it for their own unique circumstances.


Figure 3: Feasibility that in at least one case the process will create a particular positive outcome.

Considering a “category two” process theory, we might find that a benefit of this risk analysis process is a net time savings, but at the price of investing in some options that are not used (Figure 4). This could result in a revised theory that states, for example: “Risk management can create substantial cost savings when negative events transpire, but with offsetting costs when such negative events do not happen.” This can be considered a “category two” process theory because it adds multiple outcome measures and gives a richer sense of the range of outcomes produced by a particular process. For example, we might put a deposit on items from multiple suppliers in case the primary supplier fails to deliver or delivers materials that are in poor condition, thus allowing a quick shift to the second supplier. In such a case, the shift to the backup supplier might remarkably speed up the remediation process (with associated theoretical cost avoidance). On the other hand, should the original plan work smoothly enough, we may lose the second deposit. The net result is an extraordinary savings in the worst (perhaps unlikeliest) case but some additional cost in the better case. Over time one might assess the net cost across projects of lost deposits versus quick recovery—clearly this depends on individual risks, the cost of preparing for remediation, the cost of ad hoc remediation, and the frequency with which such negative events occur.


Figure 4: Outcome trade off shows that the same process may create varied outcomes.

Considering a “category three” process theory, we might contrast two risk management processes that follow essentially the same actions, but where estimates of risk manifestation costs and probabilities for each risk are assessed by a Monte Carlo simulation versus estimation using the average scores from an expert panel (Figure 5). We may find that the simulation provides more accurate integration of results given accurate initial estimates and probabilities, but that the expert panel provides more nuanced insight into triggers for the early detection of adverse incidents and of varied potential responses at different times, should an adverse incident occur. Such an outcome would suggest contingencies under which using simulation versus using expert panels should perform better or at least with more alignment to preferred outcomes. We may formulate such a finding with a theoretical statement such as: “The general risk management process, when using simulation for calculating probabilities and potential costs will provide more accurate estimations; however, the general risk management process when using an expert panel provides explanation and alternative remediation strategies though with less accurate estimation.” This can be considered a category “three” process theory because it adds nuanced a view or comparison of the nature of the actions involved in the process.


Figure 5: Action variability shows how substitution of actions may create different results.

Considering a “category four” process theory, we might contrast hybrid approaches that use both bottom-up and top-down risk identification (Figure 6). We might contrast processes that (1) begin with a top-down approach, in which managers create a list that is then assessed bottom up by team members looking for additional risks; (2) continue with a bottom-up approach of team members, creating an initial task for managers to look for additional risks; and (3) develop bottom-up and top-down lists in parallel, then add the step of integrating the lists. We might assess outcomes in terms of the number of risks identified, the potential costs of ones that are missed in each approach, and the time cost for the development of each list. One might speculate that team members going first would spend more time (at fewer dollars per hour) and, if the end lists were equivalent, this would represent the lowest cost alternative. One might project that having both managers and team members independently create the initial lists, then integrating them, might identify more total risks but at the cost of more time spent and, thus, more personnel costs. We may formulate such a finding with a theoretical statement, such as: “The general risk management process when using top-down preceded by bottom-up analysis will yield equivalent numbers of risks being identified as the reverse (bottom-up preceded by top-down analysis), but at lower cost of time spent; parallel identification of risks followed by integration of the lists will take more labor time and cost, but identify a larger number of risks, which present more costs if adverse incidents are manifest.” This can be considered a category “four” process theory because it contrasts processes that use the same set of tasks but in a different order or sequence.


Figure 6: Sequence variability tests whether or not alternative sequencing of actions creates different results.

Considering a “category five” process theory, we would examine the intermediate states between risk management actions (Figure 7). If the first step is identifying risks, the first intermediate state might be defined by the existence of a list, which can be described by various attributes including completeness, size, and utility. The second step might target estimation of probability and cost of associated adverse events. Correspondingly, the second intermediate state might be defined by the existence of multiple lists showing risks from the most to the least costly (if things go wrong), most to least probable of going wrong, and most to least problematic (as defined by the product of potential cost and probability). Examining a risk management process at this category of detail is likely beyond the scope of most, if not all, project managers during the heat of project delivery. Examination of such a process in the research context, however, may unearth the tradeoffs in cost and benefit between partial and total completeness of specifications as well as whether or not additional analyses of possible costs and probabilities of occurrence of negative events really pays for itself across many projects and portfolios. Extending the example further, examining a micro process of this sort may seem overly “nitpicky,” but consider the effort to advance a risk management process into organizational acceptance. The actions involved are likely to include developing or acquiring a specification for analysis of individual projects; staffing and funding for personnel to perform this activity (if not within the project team, training and practice if within the project team); interaction with senior and sponsoring management to endorse such a program; and on-going evaluation of the program's costs and benefits. Consider the states between such actions, including the interval between a decision to move forward and the selection of a consultant to install the system or the state after a small number of instances of use (when the full benefits of an organizational approach may not have been achieved) and creating the momentum to continue using the approach.


Figure 7: Interim state considers the necessary thresholds required between actions.

Considering a “category six” process theory we would specify a series of states that a successful risk management process must follow, with appropriate thresholds (Figure 8). For example, this might be something like: obtaining a satisfactorily complete list of risks, adequately estimating the likelihood of each risk, and the quality of the severity assessment. This provides assurance that the process has achieved intermediate results linked to the desired outcome. It would not be essential to prove that such a sequence of intermediate states is the only way to achieve particular results, but rather that its instantiation leads more often than not to particular outcomes and/or that it is superior to alternative formulations.


Figure 8: Transferability to different domain.4

Considering a “category seven” process theory we would specify a set of domains across which findings pertinent to risk management would apply (see Figure 8). In the earlier categories, as illustrated above, this might specify different sets of project types; it might extend from projects to on-going business processes such as risk management for investment in assembly lines or transportation routes. We would expect that the specific risks identified would vary greatly by task or goal, but that the process by which management of risk occurs might be more consistent in how actions, sequences, and intervals are associated with particular outcomes.

The purpose of recognizing and distinguishing these seven categories of process theory is not to create barriers or controversy about what sort of process theory might be proposed. Rather, it is intended to provide guidance to future researchers about varied, developmental targets for the creation of new knowledge guided by theory in the domain of project management. We hold out the possibility that future scholars will observe distinctions within each of these categories that may be better served by splitting them into different categories, or that other forms of process theory may emerge from research practice not yet anticipated.

Implications of Process Theory for Project Management

Process Theory and the PMBOK® Guide

The idea of processes as the nucleus for the integration and synthesis of knowledge is already evident in the PMBOK® Guide – Fifth Edition, which recognizes 47 major processes, organized into five Process Groups, which are not necessarily applied sequentially (Project Management Institute, 2013). For example, the PMBOK® Guide describes stakeholder engagement as a fundamental process and explains in detail how this process is embedded into an overall project management approach. We argue that such a description provides an opportunity to probe further. The most basic formulation of stakeholder engagement activities can be represented as a “category 1” theory, holding that the use of such a formulation should result in observed positive results. By testing and integrating the results of such tests, this essential theory may evolve into greater understanding of the various results produced by such a process, including the effects of variations in the actions, their intervals, and their sequence. Ultimately such a process may include understanding of the range of actions from which to choose, the states that are likely to reside in the intervals between them, and a chain of likely causes and effects that can guide the selection of actions and anticipation of results by project managers regarding stakeholder engagement. Such a process aims to supplement appreciation for processes and likely outcomes with an understanding of their variations and why such outcomes are achieved.

One approach to such an analysis might use reverse engineering of a successful project, for example, to show, hypothetically: (1) agreement that the project outcomes are satisfactory (result); (2) preceded by a process that examined the master set of requirements as specified by each stakeholder; (3) preceded by a careful description of execution actions relating to particular requirements submitted by the stakeholders; (4) preceded by implementation decisions accounting for tradeoffs among assembled requirement lists; and (5) preceded by individual meetings with each stakeholder, which (6) originated in the project manager's intention to conduct stakeholder management. Given this set of activities, process theories might propose how each activity and their order influence key intermediate states and facilitate additional actions.

In this way a process theoretical view of the micro level will advance our knowledge regarding the “how and the why” of project success, which resonates well with Blomquist, Hällgren, Nilsson, and Söderholm (2010) who promote the analysis of micro-processes. They suggest that, on the micro level, actions in project management can be enacted in multiple ways, each of which may result in different outcomes. A process theoretical perspective would focus on evidence-based knowledge and understanding to supplement the intuition and implicit knowledge of individual project managers across a wide range of project management activities. This represents a significant opportunity to expand the conceptual basis for project management knowledge, opening up opportunities to develop the broader theories of project management—even though scholars including Reich et al. (2013) and Blomquist et al. (2010) are skeptical as to whether or not any overarching formal theories of project management are possible.

Other Approaches to Temporality

Our discussion of process theory focuses on processes as sequences of events and actions with intervals between them. We acknowledge that there are other views of dynamic phenomena that resemble but are not exactly the same as process theory (see for example Van de Ven and Poole, 1995). One of these views pertains to stages and stage models. Some stage models are relatively passive in that they simply occur with the passage of time. For example, these would include moving from adolescence to adulthood (certainly from a physical perspective, although emotionally this might be more nuanced). In contrast, there are maturity models in which residence in a given stage may be permanent and the transition between stages is not assured. We suggest that managers who wish to move from one categorical maturity state to another may use a process to do so. That is, they may use a sequence of actions that may include changing policies, providing training, and institutionalizing new routines such that a follow-up investigation demonstrates a different overall maturity level. The link between such stages—whether more active or more passive—and processes is that the stages represent states or positions at a point in time (perhaps in some situations acting like a dependent variable in others as an independent variable), whereas processes represent mechanisms for moving between states with the recognition that the effort to implement a particular process may or may not create the desired results.

Another temporal issue involves timing. The optimal time to take an action may be as important as whether or not it is taken (or which action is taken). We see the common notion of sequential dependencies in project management parlance and note that some are rather straightforward. For example, a road must be paved and dried before the process of painting the lines begins (although, technically, the lines could be painted before the road is dried, but typically with such poor results that it is effectively infeasible). But there are more subtle examples. Upon seeing the accumulation of cues suggesting the initial stages of a negative event, when should a manager enact a planned intervention? When is it best to inform the project sponsor of a potential threat? Communicating too early may result in wasted resources addressing potential threats that do not actually materialize, whereas waiting too long may result in committing additional resources to a doomed project (e.g., Keil & Montealegre, 2000; Keil & Robey, 1999). These issues may not be amenable to a straightforward definition of interval as a particular amount of time rather than as the observation of a particular indicator.

Organizational routines similarly pertain to sequences of actions; however, organizational routines are repeatedly and consistently undertaken. In contrast, projects are characterized by customization and uniqueness of each instance. At the margin, some activities may be repeated, but at possibly differing intervals that require some amount of unique activity (e.g., planning an annual conference or the quadrennial Olympic games). Pentland and Feldman (2005), for example, point to the complex and nuanced interplay between routines as abstract sets of actions versus how they are instantiated in specific instances. These variations can be highly informative regarding how to design, execute, and evaluate such repeated practice. It is an open question as to whether or not (or which) lessons pertaining to organizational routines may be usefully applied to projects. Artifacts and boundary objects are another element of concern to organizational routines and may be applicable to projects as a scaffolding of processes pertaining to programs and portfolios as well as individual project instances.

Inventing Actions Versus Following Actions Specified by Others

A key potential concern regarding the use of process theories in project management is the degree to which such theories can be followed in practice. A series of questions might investigate whether and when (1) the creation of the process affects the ability or quality of the project team to create positive outcomes; in other words, when does receiving a given process theory aid in affecting positive project outcomes and when does it restrict creativity or engagement? Reflecting on this question is consistent with Pettigrew's (1990) emphasis on the importance of the environment in shaping actions and their impacts. (2) Are the specifications of the actions and intermediate states within a process theory sufficient for it to be followed by all or some project teams; in other words, are there design principles by which the action specifications can be improved to enable their implementation and, thus enable project teams to gain value from them? And (3), how does the balance between following the theory and varying from it influence the ability of project teams to take advantage of process theories?

Methods for Building/Testing Process Theory

Any standard research method can in principle be used to build or test instances of process theory—as long as it supports process theory's attention to actions and events over time (Langley, Smallman, Tsoukas, & Van de Ven, 2013; Poole et al., 2000). However, it is not clear that all methods are equally well-suited for such studies. Some methods would seem to lend themselves more effectively to the description and testing of sequences of actions and their effects. Case studies and multiple case studies carefully documenting the detailed nature of actions as well as their sequence, along with the observation of effects, are logical sources of data for the development and testing of process theories (Radeke, 2010). In close relation, narrative data also lend themselves well to the development of process theory (Pentland, 1999). Note, however, that a gap may exist between the description of a case and the conceptualization of the general principles that can be projected from the particulars of the studied instance or instances—a differentiation generally recognized by separating incidents (manifest, empirically observable instances) and events (their conceptual counterparts) (Poole et al., 2000). This, of course, leads to the difficult philosophical question of whether the uniqueness of each instance is too idiosyncratic for generalization to ever be reliable. While this issue has been discussed extensively from a more philosophical perspective (Lee & Baskerville, 2003; Lee, Briggs, and Dennis, 2014), we argue that even if not all factors can be accounted for, the effort to make such generalization provides important, if imperfect, guidance and offers the opportunity for continual improvement, thereby providing guidance based on growing knowledge and confidence.

Action and design science research seem particularly appropriate for illuminating the content and process of the conception, development, installation, and use of a particular artifact or project products (Hevner, March, Park, & Ram, 2004; Järvinen, 2007; Sein, Henfridsson, Purao, Rossi, & Lindgren, 2011). Observations from such studies may focus on content or process. Content observations may be used to describe sequences of actions and events in the domain that produce particular outcomes, whereas process observations may be used to delineate actions taken by designers and implementers that pertain across multiple implementation activities. Action and design research approaches may be particularly useful from a theoretical perspective if they are combined with approaches seeking to build theory grounded in the observations and experiences they create while engaging with the field (Mueller & Olbrich, 2011).

Similarly, surveys, particularly if used with measures repeated over time or directly inquiring about actions, intervals, and sequences of actions, may be used in principle to advance process theory. Recent attention to longitudinal quantitative research highlights the potential of this approach to enrich the temporal structures of the more qualitative methods discussed above (Kehr & Kowatsch, 2015). We would particularly see a role for archival research in which investigators were privy to records of completed projects and can extract information about processes and outcomes. Simulation and game theoretic experiments can be used to pose “what-if” questions to investigate the results of processes across various conditions, given defined sets of constraints and goals. These are powerful tools for the cross-sectional replication of cases. When carefully designed, laboratory experiments may also be used to target the effectiveness of particular actions (perhaps in alternative formulation) and varied arrangements of process actions. These are already used broadly for examination of group interactions and could be adjusted to specify the sequences of actions with measures for interim results and ready opportunity to test the differences in outcomes based on differences in processes.

Additionally, various types of modeling can be used to represent states and the (sub-)processes leading to transitions between them (Recker, Rosemann, Indulska, & Green, 2009). It is quite possible that projects themselves can be represented in terms of the various activities from this perspective. For example, moving from a “state” of adequate progress on work packages to one of troubling or highly problematic progress (and the reverse transitions to a more productive state) may also lend themselves to being shaped as a “state diagram” corresponding to categories three through six in the seven-category model. In both projects and organizational routines, the centrality of actions, the intervals between them, and outcomes have resemblances, which may lead to efficiencies in investigating each while learning about both.

Challenges in Effectuating Process Theory Studies in Project Management

Despite the potential value of adding a substantial process theoretical component to the project management literature, we realize that in order to do so, individual researchers and the field as a whole will need to grapple with a number of difficult issues. Among these are:

1. Choosing the unit of analysis (a task, an action, a sequence, a routine, a process, a project, a program). This problem follows from the hierarchical nature of actions, processes, and projects as a whole, much like that of systems. A research study may consider processes in fairly large chunks—stakeholder engagement, risk analysis, work breakdown activities—or may consider these same “chunks” as processes themselves comprised of a set of processes (i.e., black box versus white box). We expect that careful and explicit delineation of the particular “chunks” of interest, consistency in their description, and reasonably equivalent treatment in their size and duration might comprise a first step to addressing this issue.

2. Similar, but subtly different from issues of unit of analysis, will be identifying and describing units of action and intermediate periods, particularly in circumstances where the flow between activities is very rapid or where subsequent activities are likely to start before prior ones are completed. Possible approaches to this will likely focus on maintaining careful records of ‘sub-activities’ and care in their clustering and definition of actions, working closely with partners to check how actions are viewed in the practitioners' own terms, and recognizing the variability intrinsic to projects.

3. Identifying and substantiating logical and temporal sequences, particularly as they apply to creating benchmark processes that can be tested in the project management environment. In many cases, it may be irrelevant whether risks are identified first by managers then by workers or vice versa as long as these are reconciled. In a group meeting environment, however, the disclosure of management views might have a chilling effect on workers revealing their preferences (or on a rare occasion vice versa). In other words, coming up with starter processes to begin the testing and refinement sequence may be tricky to create and justify.


We have argued that a process theory conceptualization—because of its focus on actions, intervals between actions, and the sequence in which they are performed—is an appropriate mechanism for the accumulation of project management knowledge. We have presented a seven-category model representing ways in which process theory can further knowledge gathering related to project management. We conclude that such an approach has significant promise for transitioning much of what have been collected as ‘lessons learned’ and anecdotal knowledge in project management into a more rigorous and testable theory base.

Given the large number of practices in project management, it is obviously impractical to test each accepted belief at once. Rather, we advocate wise prioritization of key processes that are believed to represent major turning points for the success or failure of projects or that represent areas where current knowledge is viewed as equivocal or subject to varied interpretations. This is consistent with the growing observation that without a strong theoretical base, project management education is over reliant on techniques that “have a ‘motherhood’ flavor rather than much predictive value” (Reich et al., 2013, p. 938).

In our view the use of process theoretical thinking can serve as a means of extending and enhancing existing project management knowledge as represented, for example, by the PMBOK® Guide. We see these as complementary and mutually useful. We see extensions such as: (1) providing a basis for gathering evidence regarding existing processes and micro-processes; (2) providing a basis for increased nuance and contingency—for example, differentiating stakeholder analysis prescriptions based on factors such as level of innovation of the product/service of the project, project size, and scope, or industry; (3) providing a basis for the investigation of existing micro-processes or the invention of new ones; and (4) providing deeper and fuller descriptions of intermediate states between actions and understanding of the “why” as well as “how” processes create the outcomes they do.

We anticipate that at least some process theories will link directly to activities and recommendations documented in the PMBOK® Guide (e.g., deliberate interventions of a project manager, utilizing risk management techniques, and so forth). A process theoretical underpinning, in addition to providing a basis for testing and elaboration, can provide direction in considering the interaction among processes and how the residual state following one process may affect or create the environment for another that follows. Process theory can also begin to address some multi-level issues, including the relationship between the success of process components (or sub-processes) and the accumulation of their effects within the scope of larger processes within which they are included. In building these links, process theories would not only posit that a particular sequence and timing of activities is important for project success, but would also aim at developing an understanding of why these activities and sequences are important and how and why they contribute to project success.

We argue that a transformation of project management knowledge into process theories will not only advance the science of project management, but will also help strengthen the link between theory and practice. First, we concur with Lewin (1945) and Van de Ven (1989) that there is nothing quite as practical as a good theory. Understanding project management from a process theoretical point of view can help managers better understand the varied nuances that might go into explaining how and why a certain outcome results from their interventions, following the seven categories we proposed above. This can not only help in selecting and arguing for certain interventions, but will also help the reflective process through which the project management practice has evolved and improved since the introduction of “formal” project management in the early 1950s. To this end, we imagine that post-mortem analyses and project reviews would stand to profit from the logical underpinnings process theory can provide.

Second, especially related to the idea of selecting and assessing interventions, we believe that appropriately assessing different theories is important for managers. Rather than accepting some idea just because it is published in a scientific journal, the ability to scrutinize any knowledge provided is of paramount importance. In this, we agree with Christensen and Raynor (2003) that in order to appropriately assess theory executives would benefit from a sound understanding of what a theory is and what it means. We hope that the various levels of process theory we introduced above will help project managers recognize the general principles surrounding the application of processes. We further hope that it allows greater application of the theory to their particular problem instances, thus facilitating learning and abstraction. Understanding the structure of the theoretical categories themselves can help practitioners better situate their expectations regarding expected outcomes from the particular theory to be invoked in particular instances.

Third, we argue that a process theory, as conceptualized above, can facilitate the knowledge transfer between the “art and science” of project management. To this end, the logic of process theory develops a sort of language that allows practitioners to frame their valuable experiences in a way that will make them accessible to further scrutiny by science. At the same time, a process theoretical framing of scientific insights can help managers to assess and select theory (as argued above) and, thus, put scientific theory to their own use. This way, process theoretical thinking provides a common ground for a mutually beneficial, constructive discourse between theory and practice in the project management discipline.

Process theory per se remains relatively underdeveloped in social science research, in general and in project management research in particular. We argue that the refinement and extension thereof presented in this article hold significant potential for the project management discipline that can be exported to other fields as well.


Alin, P., Maunula, A. O., Taylor, J. E., & Smeds, R. (2013). Aligning misaligned systemic innovations: Probing inter-firm effects development in project networks. Project Management Journal, 44(1), 77–93.

Bacharach, S. B. (1989). Organizational theories: Some criteria for evaluation. Academy of Management Review, 14(4), 496–515.

Baroudi, B., & Metcalfe, M. (2011). Prequalification: Using systems to problem dissolve. Project Management Journal, 42(2), 51–62.

Benbasat, I. (2001). Editorial notes. Information Systems Research, 12(2), iii–iv.

Benbasat, I., & Zmud, R. W. (2003). The identity crisis within the IS discipline: Defining and communicating the discipline's core properties. MIS Quarterly, 27(2), 183–194.

Bizzi, L., & Langley, A. (2012). Studying processes in and around networks. Industrial Marketing Management, 41(2), 224–234.

Blomquist, T., Hällgren, M., Nilsson, A., & Söderholm, A. (2010). Project-as-practice: In search of project management research that matters. Project Management Journal, 41(1), 5–16.

Blomquist, T., Hällgren, M., Nilsson, A., & Söderholm, A. (2010). Project-as-practice: In search of project management research that matters. Project Management Journal, 41(1), 5–16.

Burton-Jones, A., McLean, E. R., & Monod, E. (2015). Theoretical perspectives in IS research: From variance and process to conceptual latitude and conceptual fit. European Journal of Information Systems, 24(6), 664–679.

Cerpa, N., & Verner, J. M. (2009). Why did your project fail? Communications of the ACM, 52(12), 130–134. doi: 10.1145/1610252.1610286

Christensen, C. M., & Raynor, M. E. (2003). Why hard-nosed executives should care about management theory. Harvard Business Review, 81(9), 66–74.

Crawford, L. (2006). Developing organizational project management capability: Theory and practice. Project Management Journal, 37(3), 74–86.

Diesing, P. (1992). How does social science work? Reflections on practice (1st ed.). Pittsburgh, PA: University of Pittsburgh Press.

Eskerod, P., & Vaagaasar, A. L. (2014). Stakeholder management strategies and practices during a project course. Project Management Journal, 45(5), 71–85.

Gallivan, M. J., & Keil, M. (2003). The user–developer communication process: A critical case study. Information Systems Journal, 13(1), 37–68.

Goles, T., & Hirschheim, R. (2000). The paradigm is dead, the paradigm is dead … long live the paradigm: The legacy of Burrell and Morgan. Omega 28, pp. 249–268.

Gregor, S. (2006). The nature of theory in information systems. MIS Quarterly, 30(3), 611–642.

Hanisch, B., & Wald, A. (2011). A project management research framework integrating multiple theoretical perspectives and influencing factors. Project Management Journal, 42(3), 4–22.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1), 75–105.

Highsmith, J. A. (1999). Adaptive software development: A collaborative approach to managing complex systems, (1st ed.). New York, NY: Dorset House.

Järvinen, P. (2007). Action research is similar to design science. Quality and Quantity, 41(1), 37–54.

Johnston, C. (2014). Kickstarter project spent $3.5M to finish a working prototype - and ended in disaster. Retrieved from

Keen, P. G. W. (1980). Reference disciplines and a cumulative tradition. First International Conference on Information Systems (ICIS 1980), Philadelphia, PA.

Kehr, F., & Kowatsch, T. (2015). Quantitative longitudinal research: A review of IS literature, and a set of methodological guidelines. In 23. European Conference on Information Systems (ECIS 2015), Muenster, Germany.

Keil, M., & Montealegre, R. (2000). Cutting your losses: Extricating your organization when a big project goes awry. Sloan Management Review, 41(3), 55–68.

Keil, M., & Robey, D. (1999). Turning around troubled software projects: An exploratory study of the deescalation of commitment to failing courses of action. Journal of Management Information Systems, 15(4), 63–87.

Koskinen, K. U. (2012). Organizational learning in project-based companies: A process thinking approach. Project Management Journal, 43(3), 40–49.

Lakatos, I. (1970). Falsification and the methodology of scientific research programs. In Criticism and the growth of knowledge, Proceedings of the International Colloquium in the Philosophy of Science, London, 1965, Volume 4, Edited by Imre Lakatos and Alan Musgrave, Cambridge University Press, pp. 91–196.

Langley, A. (1999). Strategies for theorizing from process data. Academy of Management Review, 24(4), 691–710.

Langley, A., Smallman, C., Tsoukas, H., & Van De Ven, A. H. (2013). Process studies of change in organization and management: Unveiling temporality, activity, and flow. Academy of Management Journal, 56(1), 1–13.

Lee, A. S., & Baskerville, R. L. (2003). Generalizing generalizability in information systems research. Information Systems Research, 14(3), 221–243.

Lee, A. S., Briggs, R. O., & Dennis, A. R. (2014). Crafting theory to satisfy the requirements of explanation. 47th Annual Hawaii International Conference on System Sciences (HICSS 2014), Kauai, HI, pp. 4599–4608.

Lewin, K. (1945). The research center for group dynamics at Massachusetts Institute of Technology. Sociometry, 8(2), 126–136.

Majchrzak, A., & Beath, C. M. (2000). Beyond user participation: A model of learning and negotiation during systems development. In Conference on Redefining the Organizational Roles of Information Technology in the Information Age, R.W. Zmud (ed.). Norman, OK, USA.

March, S. T., & Smith, G. F. (1995). Design and natural science research on information technology. Decision Support Systems, 15(4), 251–266.

Markus, M. L., & Mao, J.-Y. (2004). Participation in development and implementation-updating an old, tired concept for today's IS contexts. Journal of the Association for Information Systems, 5(11–12), 514–544.

Markus, M. L., & Robey, D. (1988). Information technology and organizational change: Causal structure in theory and research. Management Science, 34(5), 583–598.

Midler, C., & Beaume, R. (2010). Project-based learning patterns for dominant design renewal: The case of electric vehicle. International Journal of Project Management, 28(2), 142–150.

Mohr, L. B. (1982). Explaining organizational behavior: The limits and possibilities of theory and research, (1st ed.). San Francisco, CA: Proquest Info & Learning.

Mueller, B., & Olbrich, S. (2011). The artifact's theory—A grounded theory perspective on design science research. 10th Internationale Tagung Wirtschaftsinformatik (WI 2011). Zurich, Switzerland, pp. 1176–1186.

Mueller, B., & Urbach, N. (2013). The why, what, and how of theories in IS research. 34th International Conference on Information Systems (ICIS 2013). Milano, Italy.

Padalkar, M., & Gopinath, S. (2016). Are complexity and uncertainty distinct concepts in project management? A taxonomical examination from literature. International Journal of Project Management, 34(4), 688–700.

Paré, G., Bourdeau, S., Marsan, J., Nach, H., & Shuraida, S. (2008). Re-examining the causal structure of information technology impact research. European Journal of Information Systems, 17(4), 403–416.

Pentland, B. T. (1999). Building process theory with narrative: From description to explanation. Academy of Management Review, 24(4), 711–724.

Pettigrew, A. M. (1995). Longitudinal field research on change: Theory and practice. In Longitudinal field research methods: Studying processes of organizational change, G. P. Huber and A. H. Van de Ven (eds.) (pp. 91–125). Thousand Oaks, CA.

Pentland, B. T., & Feldman, M. S. (2005). Organizational routines as a unit of analysis. Industrial and Corporate Change, 14(5), 793–815.

Pettigrew, A. M. (1990). Longitudinal field research on change: Theory and practice. Organization Science, 1(3), 267–292.

Poole, M. S., Van de Ven, A. H., Dooley, K. J., & Holmes, M. (2000). Organizational change and innovation processes: Theory and methods for research. Oxford, UK: Oxford University Press.

Popper, K. (1980). The logic of scientific discovery. London, England: Unwin Hyman.

Popper, K. (1992). Conjectures and refutations: The growth of scientific knowledge (Routledge Classics) (Volume 17) 5th edition. London, England: Routledge.

Project Management Institute (PMI). (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

Radeke, F. (2010). How to rigorously develop process theory using case research. In 18. European Conference on Information Systems (ECIS 2010). Pretoria, South Africa.

Recker, J., Rosemann, M., Indulska, M., & Green, P. (2009). Business process modeling: A comparative analysis. Journal of the Association for Information Systems, 10(4), 333–363.

Reich, B.H., Liu, L., Sauer, C., Bannerman, P., Cicmil, S., Cooke-Davies, T., Gemino, A., Hobbs, B., Maylor, H., Messikomer, C., Pasian, B., Semeniuk, M., & Thomas, J. (2013). Developing better theory about project organizations. International Journal of Project Management, 31(7), 938–942.

Ritzer, G. (2001). Explorations in social theory: From metatheorizing to rationalization. London, England: Sage.

Sabherwal, R., & Robey, D. (1993). An empirical taxonomy of implementation processes based on sequences of events in information system development. Organization Science, 4(4), 548–576.

Sabherwal, R., & Robey, D. (1995). Reconciling variance and process strategies for studying information system development. Information Systems Research, 6(4), 303–327.

Sein, M. K., Henfridsson, O., Purao, S., Rossi, M., & Lindgren, R. (2011). Action design research. MIS Quarterly, 35(1), 37–56.

Shaw, K. (2012). Lessons from a billion-dollar project failure. Retrieved from

Shenhar, A. J., & Dvir, D. (2007). Project management research—The challenge and opportunity. Project Management Journal, 38(2), 93–99.

Soh, C., & Markus, M. L. (1995). How IT creates business value: A process theory synthesis. 16. International Conference on Information Systems (ICIS 1995), G. Ariav, C. Beath, J. I. DeGross, R. Hoyer, and C. F. Kemerer (eds.), Amsterdam, The Netherlands: Association of Computing Machinery, pp. 29–41.

Van de Ven, A. H. (1989). Nothing is quite so practical as a good theory. Academy of Management Review, 14(4), 486–489.

Van de Ven, A. H., & Huber, G. P. (1990). Longitudinal field research methods for studying processes of organizational change. Organization Science, 1(3), 213–219.

Van de Ven, A. H., & Poole, M. S. (1995). Explaining development and change in organizations. Academy of Management Review, 20(3), 510–540.

Weber, R. (2012). Evaluating and developing theories in the information systems discipline. Journal of the Association for Information Systems, 13(1), 1–30.

Widman, J. (2008). IT's biggest project failures—and what we can learn from them. Retrieved from—and-what-we-can-learn-from-them.html.

Dr. Fred Niederman serves as Shaughnessy Endowed Professor at Saint Louis University, St. Louis, Missouri, USA. He earned his PhD from the University of Minnesota, Minneapolis, Minnesota, in 1990. He serves as an editor for Project Management Journal. Additionally, he serves as senior editor for the Journal of AIS, and on the editorial boards for DATABASE, Communications of AIS, Human Resource Management, and Journal of International Management. His areas of research interest include philosophy of science applied to IS, IS research methods—particularly qualitative ones, IS project management, effects on IS of mergers and acquisitions, global IS, IS personnel, and group collaboration and teams, especially in the project management context. He served as co-program chair for the 2010 ICIS conference in St. Louis, Missouri, has served as the first official “facilitator” for the AIS “senior scholars,” and is proud to be counted as a member of the “circle of compadres” for the KMPG PhD Project. He can be contacted at

Salvatore T. March is the David K. Wilson Professor of Management at the Owen Graduate School of Management, Vanderbilt University, Nashville, Tennessee, USA. He received a BS in Industrial Engineering and MS and PhD degrees in Operations Research from Cornell University, Ithaca, New York, USA. His primary teaching interests are in data management, accounting information systems, and business analytics. His primary research interests are in the areas of design science, data management, conceptual modeling, and the Internet of Things. He can be contacted at

Dr. Benjamin Müller is an Assistant Professor of Information Systems and Change Management at the University of Groningen, the Netherlands, and an Associate Researcher at the Karlsruhe Institute of Technology, Germany. His research and teaching focus on how advanced information and communication technologies transform organizations. He pays particular attention to mechanisms through which individuals augment their work with technology and the corresponding organizational benefits. His research has been published in influential journals including, for example, Journal of Management Information Systems, Journal of the Association for Information Systems, Business & Information Systems Engineering, and Information & Management. He can be contacted at

1We realize that such a definition is congruent with a “positivist” tradition exemplified by Popper (1980, 1992) and detailed by Goles and Hirschheim (2000) but do not wish to suggest that such a definition is the only definition or even the best definition. Many in the interpretivist community consider theory in terms of rich descriptions of possibly unique and complex phenomena. We value such positions, appreciate the alternate definitions, and see these as complementary rather than conflicting worldviews.

2It is important to note that, while these two are the only papers we found that explicitly refer to process theory as the basis for their theoretical contributions (i.e., explicit enough to be discoverable in the literature databases we used), we acknowledge other authors may have implicitly engaged process theoretical thinking in their work. Such implicit use of process theory leads to two challenges: First, it is possible that the understanding and use of process theory varies across studies and that, therefore, the integrative potential of drawing on the same theoretic logic has not been realized in project management theorizing. Second, authors might not be aware of each other's process theoretical thinking, which runs counter to the ideal of a cumulative tradition of knowledge and progress in theory development.

3This particular process focuses largely on the first portions of the PMBOK® Guide risk management approach (Project Management Institute, 2013, pp. 309–354) representing a particular instantiation of the initial phases including planning, identifying risks, and performing analysis. Arguably identifying and responding to variance from expected progress represents a distinct and also important process.

4The upper diagram represents project risks and the lower diagram represents risks in auditing, portfolio management, IS operations, or any of many domains where risk may be managed.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.



Related Content

  • PM Network

    Don't Be Alarmed member content locked

    By Fewell, Jesse At a recent PMI networking meeting, someone asked me: "Now that the PMBOK® Guide has 'gone agile,' should those of us leading non-agile projects suddenly change course?" Tension filled the room. The…

  • PM Network

    DevOps Goes Mainstream member content locked

    DevOps keeps gaining ground. And it's no wonder: The benefits of the IT services delivery approach have become clear. For example, the 2017 State of DevOps Report from Puppet found high-performing…

  • PM Network

    Choosing the Right Path registered user content locked

    PM Network asks the project management community how to decide upon the project delivery approach to take.

  • PM Network

    Design, Build, Debate registered user content locked

    By Rockwood, Kate When the Gov. Mario M. Cuomo Bridge opened late last year in New York, USA, the US$3.9 billion state government-sponsored project was at the center of a political debate. Budget overruns and…

  • PM Network

    Across The Spectrum registered user content locked

    By Rockwood, Kate For years, Michael Thompson, PMP, brushed off suggestions from other project professionals that he try agile approaches. "I was a hardcore waterfall guy for a long time and just not interested,"…


Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.