What Dispute Systems Design Can Learn from Project Management

Several challenges face the so‐called second generation of dispute systems design (DSD). These include, but are not limited to, defining a design's purpose and scope, promoting client self‐determination, and developing designs that are sustainable (Costantino 2009). Dispute systems design could address some of these challenges by learning from and adopting the formalized approach to projects of the Project Management Institute (PMI), which trains and accredits project management professionals (PMPs).¹ This approach emphasizes the use of repeatable, reliable, and standardized processes and procedures, regardless of industry or business. Project management (PM) is traditionally used in industries with large‐scale initiatives, but can be applied in any setting in which a structured approach is desired.

Although DSD literature prescribes taking a somewhat “linear” approach similar to project management, DSD practitioners often use (and prefer) a more “fluid,” less staccato process. While there is value in design fluidity, “everything that we do is a process which can be defined” (Wheeler and Morris 2001: 4). According to project management principles, even defined processes call for adaptability, and good project managers understand how to manage that change to ensure that the design does not stray from its intended goals.

Many DSD practitioners may already use certain project management principles and tools. This article is intended to define those PM concepts that the DSD world already uses and to introduce a new subject matter discipline to those practitioners who wish to enhance their skill set, and possibly their effectiveness. Specifically, this article will examine how integrating principles and practices from four key areas of project management could enhance the process of dispute systems design. These key areas are stakeholder management, scope management, risk management, and quality management.

We will first describe the core concepts of both dispute systems design and project management, delineating their similarities and differences. We will then address how organizations might apply project management to DSD through two case studies: General Electric's (GE) classic and often‐cited early dispute resolution (EDR) program and Chevron's DSD process in the Niger Delta region. The GE case provides an example of a dispute system designed solely by internal corporate stakeholders. Chevron provides a case study of the complexities involved when a corporation designs with external community stakeholders. Finally, we will summarize what dispute systems design can learn from project management and suggest additional areas for study.

Dispute systems design is the practice of intentionally creating standardized processes to manage or mitigate conflict. This process has been applied to resolve the disputes and manage the conflicts between individuals, within groups, organizations, and communities, and at a global level. The design process is neither random nor arbitrary. While most DSD literature to date has tended to emphasize a somewhat mechanical or linear model, practitioners know that there is a distinctly fluid component to DSD (not represented in either Table One or Figure One). Related disciplines, such as organization development, explicitly recognize models of change that are less mechanical and more organic, including biological models (growing over time) or ecological models (providing balance) (Morgan 1998).

Table One illustrates the four‐stage DSD process described in the recent textbook, Designing Systems and Processes for Managing Disputes (Rogers et al. 2013).

Figure One illustrates an earlier approach that comprised six phases applicable to conflicts that occur within organizations (Costantino and Merchant 1996).

The first phase is “entry and contracting.” Here, the designer determines which stakeholders should be involved in the process, whether the designer has the necessary power, authority, and institutional support to proceed, and if so how to begin the design.

The second phase is “organizational assessment,” which occurs after the designer and the client reach agreement regarding the scope of the work and the client's expectations. The designer solicits stakeholder input on the organization's mission, its culture, the nature and number of disputes, the durability of any resolutions, satisfaction with outcomes, and the expected goals of the design.

The third phase, goals and evaluations, focuses on identifying objectives and often also focuses on managing expectations and establishing metrics to measure effectiveness and impact. Based on the output from the evaluation process, the design can then be revised as necessary.

At the fourth stage, design architecture, the designer looks at whether, when, and how any new or revised system should be developed (Costantino and Merchant 1996). Questions a designer might ask include the following: Is a new system necessary or does the old system simply need revision? Do stakeholders express dissatisfaction or frustration with the existing dispute resolution processes? If so, which part(s)? What type, if any, of alternative dispute resolution (ADR) process best addresses the concerns expressed?

The fifth stage provides training and education for those who will use or manage the system. Training addresses how to access the system and explain the dispute options available, as well as the benefits of each option.

Usually, it is only after these five steps are complete that the designer will move the system toward stage six, implementation. There, the design can be tested through a pilot program, ideally with top‐level organizational support or a “champion.” The degree to which a design is pretested depends on available resources, organizational support, and stakeholder availability.

Project management is a systematic approach that can be applied in many arenas and used to manage many different types of issues. Project management is the “application of knowledge, skills and techniques to execute projects effectively and efficiently” (PMI 2015). The goal of PM is to define the desired result, methodically structure the work into manageable pieces, and provide a framework of business and technology processes that enable organizations to achieve the desired result efficiently and economically.

Project management is traditionally used in industries undertaking large‐scale initiatives, but its principles can also be applied in any situation in which there is a need for repeatable and reliable processes, performance, and standardization. Project management is commonly used in the information technology, engineering, construction, and pharmaceutical industries. Additionally, government agencies often use PM to ensure that projects are completed on time and funding is spent appropriately.

In 1987, the Project Management Institute (PMI) published the first “Project Management Body of Knowledge” (PMBOK) to document generally accepted PM best practices, creating a uniform lexicon and consistent structure for PM professionals (PMI 2012).² Soon thereafter, the institute began offering the “Project Management Professional” (PMP) certification to individuals who demonstrated expert competency in the field of project management, equipping them with the PM “toolbox”: a method for analysis, tactics to accomplish a project, and a common understanding of project management principles.

Before explaining the principles and processes of project management, we must first define the “project” and the key players. A project is defined by the PMI as a “temporary endeavor undertaken to create a unique product, service, or result” (PMI 2013a: 3). A program is defined as a “group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually” (PMI 2013a: 9). In the context of DSD, a “project” might be to develop a dispute resolution system within a company to handle workplace disputes. Once the design is complete, the implemented dispute resolution system would be a “program,” and each workplace dispute that filters through the program would qualify as another “project.”

The main participants on any project are the project manager, the project sponsor, the project team, and the stakeholders. The distinction between project manager and project sponsor is important. The project manager is assigned by the performing organization — or the design team — “to lead the team responsible for achieving the project objectives” (PMI 2013a: 16). In contrast, the project sponsor is the person, group, or organization (either within or outside the project manager's organization) who provides resources and support for the project and enables its success (PMI 2013a: 32). Although it is possible for either the project manager or the project sponsor to be a “champion,” the project sponsor and project manager will never be the same person. In the DSD context, the designer of the dispute system will function as the project manager, and the client or organization that hires the designer and/or funds the project will function as the project sponsor. The project team works with the project manager to deliver the product. And, finally, a stakeholder is any “individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project” (PMI 2013a: 30).

Project management processes are organized into five activity groupings (called PM process groups) for every project: (1) initiating, (2) planning, (3) executing, (4) monitoring and controlling, and (5) closing.

• The initiating process comprises activities “performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase” (PMI 2013a: 49).

• The planning process includes those activities required to establish the project's scope, objectives, and “course of action required to attain th[ose] objectives” (PMI 2013a: 49). This is the only process group in which the activities are performed in sequential order.

• The executing process comprises activities “performed to complete the work defined in the project management plan” (PMI 2013a: 49).

• The monitoring and controlling process includes activities “required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes” (PMI 2013a: 49).

• The closing process group comprises activities necessary “to finalize all activities across all Process Groups to formally close the project or phase” (PMI 2013a: 49).

Figure Two illustrates the relationship between the PM process groups throughout a project's life cycle (PMI 2013a).

We note two important characteristics of project management. First, the PM life cycle is cyclical: the processes are designed to constantly incorporate feedback. Although “the process groups are typically performed in the same sequence on each project,” these phases are not automatically linear (PMI 2013a: 50). The process groups are linked through their “dependencies,” meaning that “the result or outcome of one process becomes the input to another process” (PMI 2013a: 52). Second, monitoring and controlling activities, which include validating metrics and testing quality, take place continuously throughout the project life cycle and often occur simultaneously with the other processes.

Project management applies ten areas of specialization (“knowledge areas”) to each phase of the life cycle. These areas are integration, scope, time, cost, quality, human resources, communications, risk, procurement, and stakeholder management.

Each knowledge area comprises a set of concepts, key words, and activities specific to that area. In the next section, we will discuss four project management knowledge areas that we believe hold particular promise as tools that could address some of the gaps in DSD practice and theory. These four areas are stakeholder management, scope management, risk management, and quality management. This article touches only on these four areas because we believe that DSD can benefit most immediately from these project management principles and practices. Table Two outlines activities occurring in the four knowledge areas discussed in this article mapped across the five process groups in a project life cycle (PMI 2013a).

Stakeholder management aims to create and maintain relationships between the project team and stakeholders to meet project goals and requirements. The following are the four activities of stakeholder management: (1) identify stakeholders, (2) plan stakeholder management, (3) manage stakeholder engagement, and (4) control stakeholder engagement. The project manager must identify all internal and external stakeholders who will participate and influence the project's outcome. This information is documented in a “stakeholder register” along with the stakeholders' major requirements and expectations for the project. Managing and controlling stakeholder engagement can require a great deal of the project team's time and energy. Managing the stakeholders requires that the project manager communicate and work with them “to meet their needs/expectations, address issues as they occur, and foster appropriate stakeholder engagement in project activities” (PMI 2013a: 391). The project manager “controls” the stakeholders' engagement and influence throughout the project by evaluating their participation, reassessing the stakeholder register, and refining engagement strategies as necessary.

Scope management is the process of ensuring that “the project includes all the work required, and only the work required, to complete the project successfully” (PMI 2013a: 105, emphasis added). Project scope is “[t]he work performed necessary to deliver a product, service, or result with the specified features and functions” (PMI 2013a: 105). Scope management is arguably one of the most important components of project management because failing to monitor this stage closely can lead to “scope creep,” or “the uncontrolled expansion” of the project without properly accounting for its impact on time, cost, and resources (PMI 2013a: 136). Scope creep can often signal the death knell for projects because sponsors typically lack the additional funding needed to cover associated cost increases or, if the schedule slips, they may decide they no longer need the project.

Scope management involves six activities. First, before starting the project, the project manager creates a “scope management plan” that describes “how the scope will be defined, developed, monitored, controlled, and validated” (PMI 2013a: 562). Adhering to the scope management plan throughout the project prevents scope creep, keeps the project team focused on the project's requirements, and reduces risk.

Second, the project manager identifies the project requirements by “defining and documenting stakeholders' needs to meet the project objectives” (PMI 2013a: 112). Project requirements are the “condition[s] or capability[ies] that [are] required to be present in a product, service, or result to satisfy a contract or other formally imposed specification” (PMI 2013a: 112). The six categories of project requirements are business requirements (e.g., business issues/opportunities and purpose of a project); stakeholder requirements; solution requirements (e.g., product data, reliability, performance, retention); transition requirements (e.g., training requirements); project management requirements (e.g., quality control processes, such as normal distribution versus standard deviation, or risk diagramming techniques); and quality requirements (e.g., deadlines, metrics).

To determine requirements, the project manager relies on a requirements management plan “that describes how requirements will be analyzed, documented, and managed throughout the project life cycle” (PMI 2013a: 110). He or she tracks the collected information in a “requirements traceability matrix,” which is a chart or table that “links product requirements from their origin to the deliverables that satisfy them” (PMI 2013a: 118; see  Appendix Two, Requirements Traceability Matrix). This allows the project manager to analyze the impact of scope changes and ensure all requirements are met at project closeout.

Third, the project manager defines the project's scope based on information obtained from the project charter, requirements documentation, and lessons learned from previous projects. The project manager consults with stakeholders, subject matter experts, and industry groups to define the scope. Once the scope is established, it is submitted to the project sponsor for approval.

Fourth, the project manager creates a “work breakdown structure” (WBS) by “subdividing project deliverables and project work into smaller, more manageable components” (PMI 2013a: 125–126). A snapshot of the approved scope statement, the WBS, and its associated WBS dictionary is then captured in a scope baseline, which is used to measure the project's progress.

Fifth, the project manager validates the proposed project scope by reviewing the completed project deliverables with the project sponsor to ensure that they are accurate and satisfactory.

Finally, the project manager controls the scope by actively monitoring all change requests. While any stakeholder may request changes, the project manager or project team verifies that all revisions or expansion in scope are documented in the change management system, and are either approved or rejected by the change control board, that is, a “formally constituted group of stakeholders responsible for reviewing, evaluating, approving, delaying, or rejecting changes to a project” (PMI 2013a: 96).

Project risk management focuses on “increas[ing] the probability and impact of positive events, and decreas[ing] the probability and impact of negative events in the project” (PMI 2013a: 273). To identify potential risks and develop strategies to address them, the project manager will examine the lessons learned from previous, similar projects, as well as activity cost and duration estimates, scope baselines, and stakeholder registers. He or she will also consider “enterprise environmental factors,” which are those conditions, “not under the [immediate] control of the team, that influence, constrain, or direct the project” (PMI 2013a: 29), and “organizational process assets,” which are an organization's “plans, processes, policies, procedures, and knowledge bases” (PMI 2013a: 27). An example of a risk factor might be a project constraint, such as inadequate personnel and/or resources, with a resulting risk that affects cost, schedule, or performance. Once the project manager identifies all potential risks and analyzes root causes, the information is documented in a risk register.

Project quality management includes processes and activities that “determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken” (PMI 2013a: 189). Quality is “planned, designed, and built into” the project from the beginning; quality is “not inspected into the project's management and the project's deliverables” (PMI 2013a: 229, emphasis added). A critical requirement of the initial project planning is the selection of clear metrics and acceptable tolerances, or “allowable variations to the metric,” for measuring whether goals have been achieved (PMI 2013a: 242). These metrics also help the project manager to control the project's cost and schedule throughout the project life cycle. They should also be repeatable and explicit (to avoid the loopholes that would enable participants to “game the results”) (Kendrick 2009). The project team works together to identify and prioritize the metrics that will be used, which are then documented and distributed for regular data collection, evaluation, and reporting.

A comparative analysis of four of the key knowledge areas of project management — stakeholder management, scope management, risk management, and quality management — illustrates some important similarities and differences between PM and DSD.

Two important principles of both dispute systems design and project management are that stakeholders should be involved from the beginning and their input should be captured in the initial assessment stage. Practitioners in both fields also emphasize that the keys to working with stakeholders are effective communication and transparency; these ensure that stakeholders have a voice in the process.

When stakeholders feel included, it improves the design in two ways. First, they are more likely to assist and support the designer and help with project tasks. Second, they can dramatically affect the success of a project (i.e., positively if proactively and constructively engaged, negatively if not). A recent PM industry report revealed that among high‐performing organizations — those that complete 80 percent or more projects on time, on budget, and within goals — effective stakeholder communications had the greatest impact on complex projects (PMI 2013b).

The disciplines diverge, however, in two major areas: collecting stakeholder input and managing stakeholder participation. Project management approaches stakeholder management in a more formalized and methodical manner than does DSD. First, project managers learn how to identify the stakeholders, analyze project impact or influence, and develop a stakeholder management strategy. Because PM training focuses on complex, multiparty projects, project managers become experienced at managing hundreds of stakeholders whose levels of interest, influence on the project's success, and resistance to change will vary. Second, stakeholder input is thoroughly documented to take into account different or conflicting objectives. Table Three illustrates a typical PM “stakeholder matrix” that identifies all stakeholders, weighs their influence, describes their level of interest and expertise, and suggests options for managing each stakeholder.³

In contrast to the methodical and hierarchical approach employed by PM, DSD does not manage stakeholders at all. Rather, in DSD, the emphasis is often on designing with stakeholders and not for them. The DSD Venn diagram in Figure Three, unlike the PM stakeholder matrix in Table Three, contains no information on how stakeholder concerns could or should be weighed or addressed. This suggests an implicit assumption in the DSD arena that all stakeholder input has equal weight and importance.

Both dispute systems design and project management stress the importance of early assessment and thorough planning prior to implementation. Additionally, both fields recognize that planning should begin only after the contract (or project charter) has been approved (although this may be less explicit in the DSD arena) and all stakeholders have been identified. Despite this commonality, the most salient difference between the two disciplines is the degree of rigor and attention paid to managing scope and expectations. Figure Four illustrates the salient differences and the overlaps between the PM and DSD approaches to defining and managing a project's scope.

Project managers are trained to flesh out requirements in a methodical way. It is a well‐recognized PM principle that 68 percent of projects fail because of unclear requirements (Jonasson 2008). The PMI places so much importance on the requirements development process that a review of requirements occurs in all five processes of a project — from project initiation until completion. By following this rigorous method, a project manager can ensure that the requirements are accurately defined, and consequently that the design is both achievable and sustainable.

Once the requirements and scope are established, project managers carefully manage any requested changes. Because changes to the project plan are costly (in terms of time, money, and opportunity), monitoring revisions closely is crucial to project success. For these reasons, according to PMI principles, any requested changes must be documented and measured against the scope management plan. Scope changes may proceed only if explicit permission is granted through formalized change control board procedures. In the absence of such approval, any uncontrolled or unapproved changes are considered “project scope creep.”

In contrast to the formalized PM approach, DSD literature rarely discusses managing or monitoring scope creep (although some DSD practitioners may watch for and account for this). Rather than constricting change, DSD often encourages change, emphasizing the importance of incorporating flexibility to adapt or expand the design as new or previously unknown needs and interests arise.

It is significant that DSD does not have a direct corollary to project management's risk management process. The closest that DSD comes to managing risk is to build consideration of system restraints and constraints into the assessment and implementation phases. And similar to PM's focus on identifying both the negative and positives risks, DSD recognizes that constraints can pose opportunities. But while DSD may identify restraints and constraints, it does not manage risk in the way PM does. A project manager not only understands risk but also explicitly calculates the project benefits that can arise from comprehensively managing risk, such as the following:

• reducing costs and preventing chaos by identifying earlier root causes of problems;

• gaining buy‐in from project sponsors when risk is thoroughly anticipated;

• justifying budget reserves to the project sponsor;

• increasing communications about “problem areas” and creating opportunities for the project team to avoid risk; and

• generating useful information that can serve as the basis for negotiations or project modifications with project sponsors over cost and scope.

Project management and DSD also differ in how each practice defines and uses metrics and in when evaluation occurs during the life cycle of a project or design. Dispute systems design has, at times, struggled with incorporating evaluation protocols into conflict management or dispute resolution systems. Lawrence Susskind and Jeffrey Cruikshank (1987) measured a dispute resolution project's success by factors such as “fairness, efficiency, stability, and wisdom of outcomes,” and William Ury, Jeanne Brett, and Stephen Goldberg (1988) emphasize “satisfaction with the outcome” and “relationships among the disputants,” while others (Costantino and Merchant 1996) have recommended the use of quantitative metrics focusing on efficiency and “effectiveness (e.g., durability, nature of the outcome, and effect on the organizational environment)” (Smith and Martinez 2009: 127–128).

We suggest that the DSD process might benefit significantly by adopting aspects of the project management framework for evaluation, and that such an enhancement could make DSD metrics more descriptive, analytical, standardized, and useful. One PM maxim is that “the things that get measured are the things that get done.” Thus, a critical initial project planning requirement is that metrics are selected that make goals measurable and allow the designer to control cost, schedule, and measure quality throughout the project life cycle. Items to be measured in the PMBOK include “on‐time performance, budget control, defect frequency, failure rate, availability, reliability, and test coverage” (PMI 2013a: 242). The Project Management Institute also advises that, in addition to being quantifiable, metrics be repeatable, narrowly defined to minimize differing interpretations and loopholes to “game the results,” and include clearly defined units of measurement, which are then prioritized and agreed upon by the project team (Kendrick 2009).

The project manager and the project team monitor, evaluate, and reevaluate the metrics throughout the entire project life cycle. In contrast, DSD often considers metrics only at the end of the process (although increasingly design practitioners are suggesting that metrics be addressed as part of the goal‐setting stage). Project Management, however, teaches that metrics must be continuously evaluated because any project changes, such as scope of work or stakeholder register modifications, are “inputs” that may affect the final deliverable.

Having looked at the basic principles of DSD and PM and the similarities and differences between the two, we turn now to the example of General Electric to see how project management principles were used (whether knowingly or not) or might have been used in an early, often‐cited, and successful DSD project involving internal stakeholders. General Electric's early dispute resolution (EDR) system has been studied extensively as one of the first and most classic examples of the use of alternative dispute resolution by an organization to reduce and control litigation costs.

When P. D. Villareal was the counsel for litigation and legal policy at GE in 1995, he was asked to improve the company's ad hoc response to lawsuits. Costs had skyrocketed and tremendous amounts of company time and energy were devoted to litigation activities, often at the expense of business and workplace relationships (Wheeler and Morris 2001). Villareal recognized that GE needed a more systematic approach to conflict management. Given a broad mandate, Villareal seized upon principles from the growing field of alternative dispute resolution and from GE's latest corporate initiative, the “Six Sigma Method,” which emphasized enhancing organizational performance by thoroughly understanding underlying processes and reducing or eliminating defects and waste.

The Six Sigma Method was first developed as a quality measurement tool by Motorola engineers in the mid‐1980s. General Electric's Six Sigma solution required “careful definition of each element of a process, devising statistical measures to track performance, then crafting and piloting solutions, and finally monitoring success in very precise terms” (Wheeler and Morris 2001: 3). Although Six Sigma began as a quality measurement tool at GE in the manufacturing department, its application soon evolved into a company way of doing business, championed by GE's chief executive, Jack Welch, who realized: “Everything that we do is a process which can be defined” (Wheeler and Morris 2001: 4).

Welch's enthusiasm spurred change within the company, ultimately leading Villareal to apply the Six Sigma framework to improve GE's litigation management strategy. The Six Sigma quality initiative focused on reducing resolution costs and uncertainty in the outcome, lowering the average length of time that it takes to complete a step or set of steps to resolve a conflict, and maintaining relationships with stakeholders (Wheeler and Morris 2001). To meet these goals, Villareal implemented a form of ADR known as early dispute resolution (EDR), a three‐tiered approach involving both the legal department and the personnel closest to the dispute.

Those people closest to the dispute handled it at the first phase, “Level 1,” “by pursu[ing] business‐to‐business discussions and initiat[ing] informal negotiation” (Wheeler and Morris 2001: 5). If those efforts failed, the dispute moved on to “Level 2,” during which a dispute resolution team, consisting of an attorney and a manager, evaluated the case, adopted a dispute management strategy, and documented the matter in an ADR log (Wheeler and Morris 2001). Level 2 activities were highly collaborative and required both departments to work as a team on every matter. If the case evaluation revealed that the matter could not be resolved except by litigation, only then did the matter move to “Level 3” (Wheeler and Morris 2001).

Six Sigma and project management are similar in many regards, but differ in the scale of their approach. Project management is a micro‐level strategy that provides structure and a detail‐oriented approach, while Six Sigma is a macro‐level strategy focusing on overall leadership and performance. Despite these differences, Six Sigma and PM complement one another in many respects. The Six Sigma management method incorporates many PM processes and tools. Likewise, PM recommends Six Sigma as a quality improvement initiative (an activity that falls within the quality management knowledge area) (PMI 2013a). Viewing GE's EDR program through a PM lens reveals how DSD generally, and GE's EDR program specifically, used, or might have used, PM principles.⁴

To analyze GE's initiative using PM principles, it will help to first define GE's “projects,” “programs,” and stakeholder “roles” within the context of PM nomenclature. Here, the first project is the EDR system design (Project 1). After implementing the EDR system, every dispute that is processed through the EDR system is an independent project (Project 1A) within the EDR program. General Electric and its officers are collectively the project sponsor in both examples because the corporation has the ultimate authority over funding the project, deciding what system is implemented, and determining how litigation will be handled. In this case, Villareal would have been the project manager for designing the EDR system (Project 1). Once that system is implemented, the EDR coordinator, who championed implementation of the process, will also be a project manager for that individual dispute (Project 1A).

General Electric's EDR system was a model of successful stakeholder management because it focused heavily on incorporating stakeholders in case evaluations. At Level 1, the operations personnel engaged directly with the disputants in informal negotiations. This guaranteed that the disputants had a chance to be “heard” before the company made any major litigation decisions, and it gave both parties an opportunity to salvage the relationship. At Level 2, in‐house lawyers and managers worked as a team to evaluate each dispute and plan for how it would be handled. By involving personnel knowledgeable about the dispute's history as key stakeholders in the legal strategy, the design encouraged managers' buy‐in and avoided communication gaps between the litigation department and GE employees and managers.

Additionally, the company's education program for in‐house counsel and managers provided an effective way of communicating with stakeholders about changing a corporate culture that seemed tilted toward litigation. Project managers often use training programs to manage communications with stakeholders. By stressing the importance of the EDR system and training employees on how to effectively access and utilize it, GE guaranteed that stakeholders were both engaged and informed.

Before settling a dispute or engaging in litigation, GE's EDR system required “careful measurement and evaluation, a hallmark of Six Sigma processes generally” (Wheeler and Morris 2001: 7). The purpose was to avoid the “trap of incremental decision making” or “scope creep” in project management vernacular. General Electric's careful evaluation was also in line with PM's teachings on scope management. Using Project 1A as an example, each case that was processed through the EDR system required the litigation team to document the EDR strategy (i.e., project plan) in the ADR log, including information on each case's objective (e.g., preserve customer relationship with XYZ, Inc.).

It is unclear from the GE case study whether the EDR process established something akin to a “requirements matrix” or a “change control plan.” If it did not, GE might have benefited from documenting such information. The company may have had difficulty gleaning requirements from the “project charter” if the defined product was too broad or too generic (i.e., “streamline” litigation). Without more specific guidance, Villareal would have needed to rely on stakeholder input to define requirements. Once the requirements had been defined, a change control plan could have been developed. In the EDR design initiative, change control is most relevant for Project 1A (an individual case strategy entered into the EDR system), which would determine if and when approval was necessary to change the strategy.

General Electric's risk management process was analogous to that recommended by project management. The company's early case evaluation, conducted every time a dispute reached Level 2, is similar to PM's risk mitigation plan because each team identified, among other things, the best case/worst case scenarios and probability of each, GE's and the disputants' goals and objectives, and important principles or precedents at stake. Additionally, GE captured this information in the ADR log, and periodically reviewed the entry for each dispute. The company's process also included documenting and reevaluating risks throughout the project life cycle, which is a PMI best practice and a critical component of effectively managing risk. As GE recognized, lessons could also be learned from reviewing the ADR log that could then inform other case evaluations in the future (i.e., “feedback”).

Like many DSD projects, it appears that GE's approach to capturing metrics and managing quality might have benefited from a PM approach. Villareal projected that the EDR program produced actual savings close to $40 million (Wheeler and Morris 2001: 9). However, Villareal struggled to institutionalize the metrics that could prove the program's success. One suggestion was to set aside litigation reserves based on an exposure assessment, and reward the dispute resolution teams if they were able to negotiate lower settlements as defendants or higher settlements as plaintiffs. GE's accounting department was concerned, however, that “the S.E.C. and private analysts might regard aggressive liability reserves as a way of masking income,” and it “would also mean a corresponding loss of resources available to managers planning budgets and future investments” (Wheeler and Morris 2001: 8–9). Others voiced concern that the proposed new metric encouraged managers to game the system.

Using a PM framework, GE might have solicited stakeholder feedback on acceptable metrics at the start and then established a means for tracking and managing quality before implementing the EDR program. Indeed, the ADR log would have been a prime place to track the project metrics. When the design team (akin to a project team) attempted to conduct an ex post evaluative analysis of the EDR system, however, other stakeholders apparently pushed back (with legitimate concerns); this may have ultimately prevented the gathering of verifiable metrics. General Electric might also have considered other types of measurements besides cost savings. A project manager might have established other quantifiable, traceable metrics, such as measuring time variances between the projected time and the actual time spent to resolve a dispute, or whether disputants were “return buyers,” which would be a metric for determining the system's impact on customer relationships.

A survey conducted by the accounting firm Ernst and Young in 2002 found that a majority of senior executives at Global 1000 companies believed that corporate social responsibility (CSR) “is one of the most important non‐financial influences on corporate value” (PR Reporter 2002). Corporate social responsibility is defined as “the continuing commitment by business to contribute to economic development while improving the quality of life of the workforce and their families as well as of the community and society at large” (Watts and Holme 1999: 3). In this section, we will use Chevron's work in the Niger Delta region to illustrate how a project management approach could help a corporation design and implement processes to manage conflict with communities as part of a larger initiative to promote CSR. In contrast to the GE dispute resolution system designed solely by internal corporate stakeholders, Chevron provides a case study on the complexities involved when a corporation works with external community stakeholders in the design process.

Chevron has had business interests and infrastructure in the Niger Delta region for many years. The company has made numerous investments and improvements in communities, including the construction of schools and hospitals. In 2003, Chevron closed a number of its facilities for nearly eighteen months and evacuated its personnel because of regional instability. During the so‐called Warri Crisis, a series of riots and clashes between two ethnic groups centered around the Nigerian city of Warri, Chevron “suffered more than $1 billion worth of damage to company infrastructure, as well as the destruction of social projects intended to benefit the community” (Hoben et al. 2012: 4). Despite the investments Chevron had made in the community, some local stakeholders saw Chevron as a source of oppression and unmet expectations. Before 2003, some of Chevron's community development projects had failed to garner local support, in part because stakeholders perceived that they had not been given the opportunity to participate in decision making.

After the uprisings, Femi Ajibola, the managing director of the New Nigeria Foundation, a Nigeria‐based nongovernmental organization (NGO), worked with communities and Chevron to restart stalled negotiations. As a third‐party neutral facilitator who had worked extensively in the Niger Delta, he explained the stakeholder issue in a video produced by the Corporate Social Responsibility Initiative at Harvard's Kennedy School of Government. “The unfortunate thing,” he said, “is that, number one, you cannot sit down and decide the needs and requirements of others for them. Number two, you cannot prioritize for them. Number three, even if you get it right, that is you are able to identify what they need, it is extremely important that they own the process and they own the structures in place” (Phillips and Stott 2011).

Recognizing that “[i]t was time to look at things in a more comprehensive and holistic manner,” Chevron outlined five key principles to guide its new community development initiatives: (1) community leaders, the communities, and Chevron should be mutually accountable for the CSR projects; (2) the community should have a sense of ownership; (3) the processes should be transparent; (4) Chevron and the communities should work in partnership; and (5) participants should speak through a single platform for dialogue (Hoben et al. 2012: 5–6).

These represented two major changes to Chevron's approach. First, this represented a transition from making piecemeal agreements with each community to implementing multiyear agreements with blocks of communities (regional development councils). Second, it introduced a community‐led decision‐making process (Hoben et al. 2012). As a result of the revised approach, four hundred individual community agreements were replaced by eight block agreements.

Chevron also adopted a general memorandum of understanding (GMOU) outlining its community development governance model and its commitments to the communities. Stakeholders became more involved in decision making about development projects and resource allocation. Despite this enhanced participation, some stakeholders still perceived a lack of transparency and a power imbalance. They mistrusted the model outlined in Chevron's GMOU because it gave them only limited opportunity for consultation and oversight (Hoben et al. 2012).

In the Chevron initiative after 2003, the first project is the revised approach to designing the GMOU model (Project 1); the ongoing implementation of the GMOU framework then becomes a program. Each GMOU multiyear agreement with the regional development communities to support community development activities and social investment (e.g., building a new school) would then be an independent project within that program (Project 1A).

Chevron is the project sponsor because all funding comes from the corporation. The project manager in both projects (1 and 1A) could be from Chevron, although a non‐Chevron project manager could help alleviate the perceived power imbalance and lack of transparency. The third‐party facilitator, Femi Ajibola, could be the project manager for the negotiation of the initial GMOU agreement (Project 1). He might also be the project champion if the project manager was from Chevron. The project manager for planning and developing an independent project (Project 1A) would probably be a regional development council representative. In addition to internal Chevron stakeholders and the communities, external stakeholders include the Nigerian government, civil society, and NGOs.

Chevron's CSR initiative in the Niger Delta region illustrates the complexities of managing a multiethnic, multistate stakeholder community. Here, stakeholders included more than four hundred separate communities and more than 850,000 people (Hoben et al. 2012: 3). According to project management principles, “stakeholder management is about creation and maintenance of relationships between the project team and stakeholders, with the aim to satisfy their respective needs and requirements within project boundaries” (PMI 2013a: 400). In the Chevron case, the relationship with stakeholders was critical to project success.

It appears that, at the outset, local stakeholders perceived that Chevron did not actively engage them: “Community leaders said they felt Chevron had pushed the new approach upon them, rather than creating it with them. Community leaders were also suspicious of Chevron oversight within the GMOU model and sought greater autonomy from the oversight structures” (Hoben et al. 2012: 7). If true, this may have led to community mistrust and ultimately stalled the GMOU negotiations after the 2003 crisis. Although a number of improvements were made to encourage stakeholder engagement, subsequent evaluations suggest that women and the elderly still did not feel fully engaged in the process (Hoben et al. 2012).

In project management, excluding or marginalizing any portion of a stakeholder community can create information deficiencies that bias and hamper the project. The feeling among women and the elderly that they were marginalized may have arisen from what PM calls “enterprise environmental factors,” which are not within the project team's control, such as patriarchal societal norms (PMI 2013a: 29). Project managers account for these uncontrollable enterprise environmental factors as “inputs” to the project planning process because of the significant influence they can have on participants and outputs, and ultimately on project “success.”

Several PM tools can help mitigate enterprise environmental factors. In situations in which stakeholders might fear retribution, focus groups are useful because facilitators can group together stakeholders with similar “interests.” For example, to encourage candor, a designer might want to separate those who have less power in the community from community leaders. Anonymity of responses and/or agreements that assure that statements will not be attributed to a particular individual can also be helpful. When vocal stakeholders threaten to commandeer the conversation, planners can utilize the nominal group technique for brainstorming, which uses a voting process to prioritize the most useful ideas, and the Delphi technique for group decision making in which the facilitator solicits anonymous feedback and the responses are recirculated to the group for review and ranking (PMI 2013a).

Once the project manager has identified all the stakeholders and collected their input, the information is documented so the project manager can plan how to effectively work with the stakeholders going forward. The Niger Delta's complex stakeholder environment makes it a fruitful case for comparing and contrasting the DSD stakeholder interest map with the PM stakeholder matrix model. Figure Five illustrates a DSD stakeholder interest map for Chevron that a designer might develop.

The DSD model informs the designer of how stakeholder interests might overlap. The map shows that the Nigerian government, local communities, and NGOs are interested in schools, health care, jobs, and access to clean water, but all five stakeholder groups are interested in regional stability. Visualizing the overlaps, which are similar to zones of possible agreement in negotiation theory, helps the designer recognize mutual or exclusive interests and consensus‐building opportunities. It does not, however, help the designer determine what weight to assign to each interest or how to manage stakeholders. For this, project management is instructive. Table Four is a stakeholder matrix that a project manager might develop.

The PM stakeholder matrix tracks not only interests, but also each individual stakeholder's or stakeholder group's role, influence, impact, attitude, and communication requirements. Methodically tracking communications requirements is especially important in a CSR initiative such as this because of the challenging dynamics posed by multiethnic, multistate, multilingual, nonmonolithic stakeholders. Nigeria “is one of the most linguistically diverse countries on earth” with more than five hundred official languages (Hoben et al. 2012: 3).

The project team cannot expect to communicate with every stakeholder, but more importantly the project team does not need to communicate with every stakeholder (PMI 2013a). Rather, PM would identify representative stakeholders to be contacted throughout the project. The stakeholder matrix would account for any technological deficiencies (e.g., e‐mail unavailability, phone service limitations, language preferences) that might affect communications. Also, because stakeholder management is an iterative process, the project manager for the CSR initiative would reassess the stakeholder matrix on a regular basis and evaluate whether the communication strategy was still effective (PMI 2013a). In addition, because it documents more nuanced information than the DSD interest‐mapping model, a PM stakeholder matrix allows the project team to manage multiple stakeholders and identify coalitions and possible spheres of influence.

Chevron's initiative might have benefited from enhanced scope management. This PM tool ensures that the project includes only the work required to complete it successfully. This is critically important in a region such as the Niger Delta, where allegations of corruption and lack of transparency are common. Before the GMOU was signed, some stakeholders were skeptical of how contracts for development projects were awarded to local businesses and how decisions were made on certain Chevron community projects (Hoben et al. 2012). By developing a requirements matrix, which would clearly define the scope of work and help the project manager monitor the project, Chevron might have more closely aligned its ongoing decision making with the ultimate purposes of its CSR initiative.

For example, one of the community stakeholders might submit a change request to the GMOU model design's (Project 1) source selection criteria used to rate or score vendors' proposals for constructing a community project, such as a school or clinic. Legitimate source selection criteria might be the vendor's management approach, financial capability, past performance, references, cost, and risk management procedures (PMI 2013a). Making changes to the source selection criteria after proposals have been submitted could be perceived as a sign of corruption if it were seen as helping a bidder who would not otherwise have won the bid. Moreover, the impact on costs and schedule could be substantial. A change control board, therefore, would likely reject the request to modify the source selection criteria, thus preventing possible damage to credibility and transparency.

A PM change control plan would also ensure that, once the project requirements and scope were agreed upon, Chevron (the project sponsor) and the change control board would choose which modifications to approve. Although as project sponsor Chevron has the ultimate authority to sign off on any proposed plans, it might consider including community stakeholders in the change control process to promote transparency, boost community ownership, and diminish any perceived power imbalance. While Chevron might understandably have concerns about ceding control, the risk is not necessarily financial because funding could be capped at the pre‐allocated yearly funding. Additionally, Chevron could limit its risk exposure by continuing to control the voting majority on the board (if indeed, the change control board were to adopt a governance model that utilizes a traditional voting model for decision making as opposed to agreement by consensus).

In complex operational environments, a thorough risk management plan and a risk register are essential to mitigate negative risks and enhance positive opportunities (PMI 2013a). It is unclear from publicly available materials what formal steps Chevron took to identify and manage risk in the CSR initiative, although the company clearly did do a number of things well with respect to managing risk. First, it took proactive steps to mitigate ownership risks by involving individuals who had a “connection” with the local community and who were perceived as neutral third parties, such as Ajibola. Second, Chevron invited vocal community members to participate in preliminary planning efforts and sought their continuous input. Finally, Chevron used a participatory evaluation method to obtain feedback.

Project management promotes communicating potential risks to key stakeholders and decision makers at appropriate intervals to allow them to assist the project team in either mitigating or positively exploiting those risks. Another PM risk‐management method is to keep key stakeholders apprised of important deadlines and explain how those time lines could be affected by intervening risk factors. In the Chevron case, for example, the building of schools or clinics in a particular year could be delayed due to stalled negotiations over the terms of the GMOU. Communicating this risk might motivate influential stakeholders to attempt to minimize the risk through coalition‐building, informal facilitation, or mediation to reinvigorate the talks.

The CSR initiative might also have benefited from a “risk register” that documented the cause, impact, and likelihood of different risks affiliated with the project. A register would also illustrate interconnected relationships between multiple risks based on “outputs” obtained from qualitative and quantitative risk analyses. Qualitative risk analysis helps the project manager develop “assessments of probability and impacts for each risk, risk ranking or scores, risk urgency information or risk categorization, and a watch list for low probability risks or risks requiring further analysis” (PMI 2013a: 333). Quantitative risk analysis assigns a numerical value to the risks identified as most likely to substantially impact the project's competing demands (PMI 2013a). Table Five is a hypothetical example of how Chevron might track risk on the GMOU projects.

Chevron also used a “participatory evaluation” tool to get feedback about the GMOU after four years. The evaluation process assembled more than one thousand individuals into multiple in‐person community focus groups to collect feedback “to determine what was working and how it might be improved” (Hoben et al. 2012: 7). This helped create buy‐in from the stakeholders for the next phase of the CSR initiative, and the feedback created a baseline of core issues to be addressed in renegotiating the GMOU (Hoben et al. 2012). Overall, the evaluation tool used was effective in this operational environment in which success depended largely on the end users' satisfaction (a qualitative metric). Moreover, actively involving stakeholders in the evaluation process increased the community's sense of ownership of future development projects.

The public documents suggest that participatory evaluation efforts focused mostly on qualitative feedback. From a PM perspective, the development or extrapolation of stakeholder‐derived quantitative metrics might have added value (if, in fact, none were used). Establishing quantitative metrics for CSR initiatives is inherently difficult because success is based on whether the community values the project and whether it stays within budget. Measuring community satisfaction can be a challenge — to overcome it, a project manager might glean metrics from interests documented in the stakeholder matrix (see Figure Five and Table Four). For example, jobs may be a priority for both Chevron and the communities; thus, a project manager might measure the change in employment rates. Where transparency is a priority, survey questions that measure changes in stakeholders' awareness of proposed or approved development projects could be a metric. Other survey questions could test the communities' understanding of how the GMOU processes worked or how projects were approved.

We have looked at two corporate DSD case studies: GE, in which the design was developed solely by internal organizational stakeholders; and Chevron, in which the design was developed jointly with external community stakeholders. After using those case studies as a platform to compare DSD and project management approaches, we respectfully suggest that there are five key lessons that DSD can learn from project management.

Project management offers DSD a useful framework that clearly defines and delineates differing roles, such as project sponsor, project manager, change control board, and stakeholder, to name a few. Attention to these specific roles could benefit DSD practitioners by helping them manage participants' expectations about the various players in the design and reducing the possibility of role‐blending by the designer.

Project management approaches both stakeholder assessment and stakeholder management in a more methodical and disciplined way than most DSD interventions. Stakeholder registers and stakeholder matrices could be integrated into many designers' work. A stakeholder matrix would identify roles, influences, impacts, attitudes, interests, and communication requirements to help the designer manage both the process and the stakeholders. This could be particularly useful in large, multiparty, multicultural, or nonmonolithic design initiatives.

The formalized and disciplined approach to scope management provided by project management can help prevent some of the unratified design “creep” that can occur in DSD. The presence of a project manager and a change control board ensure that the scope is explicit, understood, and approved before being revised.

Project management offers DSD the opportunity to identify, manage, and maximize risk opportunities in the context of the design process. Using a risk register, a risk management matrix and a stakeholder management matrix can keep the DSD practitioner focused on ways to create value, build consensus, maximize coalitions, meet deadlines, and control cost.

Project management contemplates both qualitative and quantitative metrics chosen in collaboration with the project sponsor and the project manager, as well as with the project champion and stakeholders. This PM tool can assist DSD to address the need for metrics early in the design process and to have necessary dialogues with stakeholders and decision makers about identifying and measuring goals.

These five areas, we believe, represent project management's “low‐hanging fruit,” that is, the PM principles that could most easily and most effectively be incorporated into DSD to address some of the challenges that the field faces. Other project management knowledge areas, however, are also ripe for further exploration, and we hope that this article will generate further discussion about the nexus between project management and DSD.

As a caveat, we certainly do not mean to imply that project management holds the answer to all the emerging and complex issues facing DSD. Nor do we mean to suggest that project management is applicable to all systems design interventions. In many instances, for example, PM principles and practices may be too linear or rigid for disputes that require rapid, autonomous decision making (e.g., hostage or terrorism situations), or values‐based identity conflicts and sacred value conflicts such as those associated with truth and reconciliation processes, or long‐standing religious, historical, cultural, or geopolitical issues (e.g., disputes in the Middle East).

Project management, however, does offer DSD a disciplined, measurable, and repeatable process for managing change — particularly if it is large‐scale or involves multiple nonmonolithic stakeholders. We hope that this brief discussion will be viewed as an invitation to begin a cross‐fertilization of ideas between the two disciplines.

Questions to consider going forward include the following:

• What is PM's role in harmonizing DSD systems with an entity's ongoing operations and long‐term strategic plan, or program‐level “integration management” in PM terminology?

• Would designers face any ethical issues in “weighing” stakeholder interests as PM does? And should the authority to weigh those interests rest with the designer in the DSD context as it does with the project manager in the PM context?

• How can PM help DSD address the “complexity factor” introduced by multiple project teams working together on multi‐organizational or intra‐organizational designs?

• What does PM have to offer DSD in a values‐based identity conflict design or a geopolitical consensus‐building initiative?

Finally, as we noted at the beginning of this article, everything is a process that can be defined. But this is only so to the extent that the stakeholders, designers, managers, and decision makers recognize that there is an actual process (and then a project, and perhaps another project, and then a program and then another project). In the ever‐expanding world of DSD in multiple settings across the globe, designers cannot afford to bypass the opportunity to learn what they can from practitioners of project management.