What is listed below is the entire case study. I have to address each of the six

Question

What is listed below is the entire case study. I have to address each of the six project constraints (scope, schedule, budget, risk, quality, and resources) as they pertain to managing the procurement of the Lighter Amphibian Heavy-Lift (LAMP-H).

How NOT to Manage a Project: Conflict Management Lessons Learned from a DOD Case Study

Abstract

This is a case study of a failed Department of Defense (DOD) project, even though it was fully justified and badly needed. Project management within the DOD is a complicated process. Projects are beset by the agenda of various stakeholders within the DOD organizational structure. When this occurs, strong project management leadership is necessary for success. This paper analyzes the potential causes of the project failure resulting from the three domains of organizational conflict, and identifies lessons learned from the failure via a conflict management perspective. Lessons learned are presented to facilitate the management of interpersonal-based, task-based, and process-based conflicts on the part of project managers and project sponsors, thus increasing the likelihood of successful project management outcomes. This case study fills a void in the project management literature by examining the relationship between the three dimensions of organization conflict and the increase in various project costs, and then offering a Project-Conflict Management Framework.

Introduction

Project management within the United States Department of Defense (DOD) has been aptly described as the one of the world’s most complicated processes. Completion of projects may require several years, and they can be difficult to manage under the best of circumstances. If organizational conflict is superimposed upon the normal project management difficulties, successful project outcomes are rendered immensely more difficult. The complexity of DOD projects stems from the fact that various stakeholders from above and below are likely to besiege the project manager. From above, there are the senior financial executives whose jobs consist of constantly re-allocating resources. More specifically, they typically re-allocate funds that have been awarded to a project manager for his or her program. Within the DOD, the complexity also stems from the appearance or perception that there have been times when the re-allocation of funds has been done without any regard for national security or for those military missions that might be of strategic importance to the military.

From below, there are the departmental or organizational managers who are vested in protecting their own interests in the project, whether directly or indirectly. Often times, these managers consider the authority and latitude for independent action accorded by senior DOD management to the project manager to be an encroachment upon their authority. Along with this, such departmental managers are concerned with preserving their own organizations, and therefore attempt to compel the project manager to comply with each and every regulation pertaining to their separate areas. This was especially true in the late 1980s and early 1990s when the emphasis in the DOD was on streamlining acquisition strategies to reduce the funding outlay and the time required for fielding a system. At the time the Lighter Amphibian Heavy-Lift (LAMP-H) Project, which will be described below, was extant, the time to field was typically 10 – 15 years, which continues to be an issue and a matter of concern (Griffard, 2002; Office of Inspector General, 2001). Departmental managers have been and still are concerned that any attempt to shorten the acquisition process represents a threat to their various areas, and are highly resistant to any approach to acquisition streamlining.

Consequently, departmental managers do everything within their power to compel full compliance with all regulations, even though in many cases such compliance can be a direct barrier to acquisition streamlining, greatly increase project cost and extend the project schedule. All this results in systems that are unaffordable and frequently do not satisfy their operational requirements. An environment with organizational conflict from above and below is the type of environment within which most DOD project managers frequently must function.

Literature Review Organizational Conflict

Organizational conflict management is “ a phenomenon that occurs between interdependent parties as they experience negative emotional reactions to perceived disagreements and interference with the attainment of their goals” (Barki & Hartwick, 1991). It has three main domains: interpersonal-based conflict, task-based conflict, and process-based conflict (Coser, 1956, Guetkow & Gyr, 1954; Hearn & Anderson, 2002; Jehn, 1995, 1997; Pinkley, 1990). Interpersonal-based conflict deals with relationship tension between interdepartmental and intradepartmental individuals (Hearn & Anderson, 2002).

Three dimensions of interpersonal conflict have been identified: interdependence, disagreement, and interference (Barki & Hartwick, 2001; Putnam & Poole, 1987; Thomas, 1992). Interdependence, a key structural pre-condition of any conflict, occurs when the attainment of one party’s goals depends in some way on the actions of another party (Barki & Hartwick, 2001). Disagreement, a key cognitive component of interpersonal conflict, exists when one party’s values, needs, interests, opinions, goals, or objectives are divergent from those of the other party (Barki & Hartwick, 2001). Interference, the central behavioral characteristic of any conflict, refers to the opposition that one party has with another party’s attainment of its interests, objectives or goals (Barki & Hartwick, 2001).

Task-based conflict deals with tension that stems from whether or not certain tasks, or requirements in the case of project management, should be pursued (Hearn & Anderson, 2002). Process-based conflict deals with tension that stems from how tasks should be completed (Hearn & Anderson, 2002). Although there is extensive research regarding organizational conflict and its domains, there is a lack of research examining the three domains of organizational conflict in the project management literature. Therefore, this case study fills a void in the project management literature by examining organizational conflict and its three domains, and offering a Project-Conflict Management Framework. The next section will identify the potential costs associated with conflict, followed by the specific forms of conflict along with the symptoms of that conflict. The subsequent section will review the conflict process and conflict handling intention strategies, and identify a Project-Conflict Management Framework.

Costs Associated with Conflict

The major lesson learned from the problem of organizational conflict identified in this case study is that conflict stems from deviations. Those deviations can be with the people, the plan, or the process. Kerzner (2003) stated that “ good up front planning may reduce the number of changes required.” The minimization of changes or deviations can enhance the chances of effective project execution. Unfortunately, the various types of organizational conflict that arose concurrently throughout the LAMP-H project, which will be identified and analyzed below, were not resolved or managed in a way that led to effective project execution.

The problem of organizational conflict comes with a cost. The cost of the conflict is in large part determined by the extent to which the conflict can be managed or resolved. The costs associated with not effectively resolving or managing conflict in a complex project setting are always detrimental, and can be fatal, as will be demonstrated below by the eventual demise of the LAMP-H project. The cost of organizational conflict may be viewed from a mathematical perspective. Consider a symmetric hyperbola of the form

x*y = c

with only positive values for “x” and “y.” The plot of this equation is in the first quadrant. As “x” becomes small, “y” becomes very large, which causes the curve to become asymptotic to the “y” axis, whereas if “y” becomes small, “x” becomes large, causing the curve to become asymptotic to the “x” axis. Consider a similar function to describe the relationship among the risk of conflict, the cost of conflict, the scheduling deviations due to conflict, and expected performance. The function is as follows:

where

r = f(c,s,p)

r – overall risk of conflictc – cost of conflicts – scheduling deviations due to conflict p – expected performance

This four dimensional equation would yield a hyper-surface where the risk of conflict could be thought of as surfaces of constant value, analogous to the constant in the first equation. These surfaces would be comprised of points such that

f(c,s,p) = r = constant.

Any attempt to change one of the variables, say expected performance, without a corresponding change in the other variables would move the resulting point to another risk surface. For example, if one attempted to increase the expected performance without corresponding increases in cost and scheduling, one would move to a new surface with an increased level of risk. As will be described below, this is precisely what occurred as a result of the interpersonal-, task-, and process-based conflict that occurred throughout the LAMP-H project.

The Conflict Process

The conflict process can be viewed as having five stages: (1) potential opposition or incompatibility, (2) cognition and personalization, (3) intentions, (4) behavior and (5) outcomes (Robbins & Judge, 2005). Stage 1 is characterized by the presence of conditions that create opportunities for conflict to arise, for example, communication, structure, and personal variables. Stage 2 occurs when the potential for opposition or incompatibility negatively affects another party or becomes actualized. Stage 3 occurs when a decision is made to act in a certain way. This stage is characterized by two- dimensional cooperativeness (the degree to which one party attempts to satisfy the other party’s concerns) and assertiveness (the degree to which one party attempts to satisfy his own concerns). From these two dimensions five conflict handling intentions are identified: avoiding (unassertive and uncooperative), competing (assertive and uncooperative), accommodating (unassertive and cooperative), compromising (midrange on both assertiveness and cooperativeness), and collaborating (assertive and cooperative) (Robbins & Judge, 2005; Thomas, 1992).

Hocker and Wilmot (1998) note that avoiding occurs when people physically or psychologically remove themselves from the conflict scene or episode often by denying the conflict, being indirect and evasive, changing and/or avoiding topics, employing noncommittal remarks, and making irrelevant remarks or joking as a way to avoid dealing with the conflict (Gross & Guerro, 2000, p. 207). The competing style relies on the use of position power, aggression, verbal dominance, and perseverance. Hocker and Wilmot (1998) state that behaviors associated with this style include confrontational remarks, accusations, personal criticism, rejection, hostile imperatives or threats, antagonistic jokes or teasing, aggressive questions, presumptive remarks, and denial of responsibility at the expense of others (Gross & Guerro, 2000, p. 206). Papa and Canary (1995) suggest that the competing style may be effective however inappropriate in organizational contexts where there are production-related goals (Gross & Guerro, 2000).

Hocker and Wilmot (1998) note that the accommodating style is associated with putting aside one’s own needs to please others, passively accepting the decisions of others, making yielding or conceding statements, and explicitly expressing harmony and cooperation during a conflict episode (Gross & Guerro, 2000). The compromising style is characterized as being focused on individual goals as well as the needs of others (Blake & Mouton, 1964; Gross & Guerro, 2000). Hocker and Wilmot (1998) state that this style requires searching for an intermediate position, through strategies such as splitting the difference, meeting the partner halfway, suggesting a trade-off, maximizing wins while minimizing losses, and offering a quick, short-term resolution to the conflict (Gross & Guerro, 2000, p. 208). Lastly, the collaboration style is viewed as both effective and appropriate in managing conflict because it provides disputants with access to other’s perceptions of incompatible goals, thereby enabling them to find a solution that integrates the goals and needs of both parties (Tutzauer & Roloff, 1988; Gross & Guerro, 2000).

Stage 4 is considered the behavior stage and includes statements, actions, and reactions made by the conflicting parties. Lastly, Stage 5 occurs when the action- reaction interplay results in functional or dysfunctional conflict (Robbins & Judge, 2005). The next section will identify conflict handling intention strategies for each symptom based on the domain classification in the context of a Project-Conflict Management Framework.

Project-Conflict Management Framework

Given the need for project managers to make decisions in the midst of organizational conflict, the conflict management process and decision-making process have been merged and modified to fit the field of project management, and its step-by-step approach (Kimmons, 1992). The resulting Project-Conflict Management Framework suggests the following:

Identification of conflict as the problem

Identification of symptoms of the problem and classification of them as interpersonal-, task-, or process-based conflict

Setting strategy selection criteria

Identification of alternative conflict handling intention strategies for each symptom based on domain classificationa. Avoiding (Neglecting, Withdrawing)b. Competing (Asserting, Distributive, Dominating, Forcing) c. Accommodating (Appeasing, Obliging)d. Compromise (Sharing)e. Collaboration (Integration, Problem-Solving)

Selection of conflict handling intention strategies for each symptom identified, many of which may need to be employed concurrently

Implementation of selected conflict handling intention strategies, concurrently if necessary.

Following the introduction and overview of the DOD LAMP-H case study below, the Project-Conflict Management Framework will be used to articulate conflict management lessons learned from the LAMP project. The practical applications will be delineated from the case analysis using the Project-Conflict Management Framework to provide project managers with a guide for how to identify and resolve interpersonal-, task-, and process-based conflict.

LAMP-H Case Study

This paper articulates the LAMP-H project’s history based on the use of archival data and observations (Eisenhardt, 1989). Next, various project phases are analyzed, along with departmental concerns at each phase. Then, specific project conflicts and their symptoms are identified and analyzed based using the Project-Conflict Management Framework. Lastly, practical lessons learned are shared in an effort to enhance future decision-making and improve the management and resolution of conflicts for successful project outcomes.

The Lighter Amphibian Heavy-Lift (LAMP-H) Project was initiated by the U. S. Army to acquire amphibious heavy-lift capability. The term “lighter” refers to the function performed by a craft in moving supplies from large carrier ships to the shore. The term “amphibian” refers to the motion of the craft, that is, its capability of moving over the surface of water and then transitioning to movement over land. Because of the requirement to move over both water and land, amphibians are usually, though not always, air-cushioned vehicles. This means that such a vehicle glides on a cushion of air, an inch or two above the surface over which it moves. The requirement for this capability had been identified as essential for the Army’s logistic re-supply mission for numerous areas of strategic interest in the world. The purpose of the LAMP-H was to support the ground troops during amphibious assault missions. The operational concept of the LAMP-H was that it would follow the troops on to the beach and provide them with the supplies necessary to sustain their ground assault.

Although the need for the LAMP-H had been identified, the project had languished forapproximately 10 years due to internal disputes about what the capabilities of such a vehicle should be. In particular, two points of contention were the payload and the speed. Some thought that it should be capable of carrying two M-70 tanks, a payload of approximately 140 tons, at a relatively low airspeed. Others argued that it should have a lower payload and be able to fly at a greater airspeed. Some believed that it should be powered by paddlewheels that would propel it through the water until it reached the beach, and thereafter by large deeply treaded tires over the sand. Others believed that two large Archimedean screws should power it. It was argued that this would suffice for propulsion over sea or sand. Still others argued that the LAMP-H should be driven with ducted propellers. Along with this diversity of opinion, there was also wide disagreement as

to just how many LAMP-H units should be purchased and at what unit price. Finally, the user of the system, the Transportation School (T-School), was no longer certain that it wanted or needed the LAMP-H system. Although the program had floundered along for about 10 years, it is likely to have survived as a result of the “seductive appeal of collective belief” (Royer, 2003) by those involved with the project because of their perceptions regarding the importance and significance of having LAMP-Hs in the Army’s arsenal. While a description of highlighted project events is delineated below, Table 1 is a timeline that delineates the chronology of the events to be described.

Table 1. Chronology of LAMP-H Activities and Events

Program Development Infancy

The project manager of the LAMP-H Project was surprised at the great diversity of opinion surrounding the LAMP-H project, and wondered how this project became so controversial given its potential usefulness to the Army’s arsenal. Not only was there great diversity as to the technical requirements for the LAMP-Hs, but there was also an equally great divergence as to the Acquisition Strategy for the system. Management at the Army Watercraft R&D Center at Fort Belvoir, VA, believed that no R&D was necessary for the LAMP-H. They believed that it could be purchased “off-the-shelf” from a commercial firm, and that the propulsion system could then be integrated. This would have necessitated only a single In-Process Review (IPR), thus greatly simplifying production approval for the project. It was evident, however, that there were some significant problems with this approach. First, not all of the technology required was state-of-the-art. Second, the subsystems to be used for the LAMP-H had never been integrated before. It seemed, therefore, that the LAMP-H Project could best be executed as an Army Streamlined Acquisition Program (ASAP) that would involve two IPRs: the first to obtain approval for proceeding with the R&D phase, and the second upon completion of the R&D phase, to approve the LAMP-H as having satisfied all R&D re- quirements, and as being ready for transition into the production phase.

A third issue that had plagued the LAMP-H Project since its inception was that of funding cuts. It was discovered that this was due to the fact that performance characteristics for the LAMP-H had never been defined. Hence, it became evident that a requirements analysis would be needed in order to provide documented rationale for funding the LAMP-H in order to put an end to all speculation as to the LAMP-H configuration specifications. The requirements analysis would also determine the number of craft to be acquired in order to best satisfy the LAMP-H mission. Since the Department of Army was threatening to withdraw funds, a requirements analysis was immediately initiated with an independent systems analysis organization. Soon positive results were forthcoming, and they immediately began to breathe new life into the LAMP-H project. To understand the vital importance of the requirements analysis in defending the LAMP-H project budget, it is necessary to understand the organizational structure within the DOD’s Department of Army, which is described pictorially by the organization chart in Figure 1.

Within the Department of Army’s organizational structure, the line of authority for the Watercraft project manager reached through the Troop Support Command, through the Army Materiel Command to the Department of Army staff. In practical terms, this meant that the Army Materiel Command controlled the funds for all Watercraft Product Managers' programs and projects. Although the Department of Army staff had been generally favorable toward the LAMP-H project, in the absence of a requirements analysis, they had no basis for defending against the Army Materiel Command management for LAMP-H funds. However, as results from the requirements analysis were forthcoming, they were used in a major consensus building effort to demonstrate the need for the LAMP-H project. The consensus building was done by briefing high levels of Department of Army management and the DOD staff on the requirements analysis results. Once the Department of Army staff had a sound rationale for supporting the LAMP-H project, the Army Materiel Command was no longer able to arbitrarily cut funds, which enabled progress to be made on the project. An Acquisition Strategy was developed based on the results of the requirements analysis, consistent with the technical requirements shown to be necessary for the LAMP-H craft, which further solidified the program.

As requirements analysis results became available, it became obvious that the LAMP-H should not carry two Abrams tanks at a relatively low speed. Instead, it needed to have a payload of about 90 tons, 50 tons less than that for two Abrams tanks, and to be capable of traveling about 15 to 20 knots in a fully loaded condition. These characteristics maximized the off-load capability of the craft, and minimized the number of LAMP-H craft required to execute the off-load mission, which as the analysis indicated, was about 30 craft. Another very significant result from the requirements analysis was that the craft would have to be propelled by ducted airscrews in order to satisfactorily complete the mission. Lastly, the results indicated that each LAMP-H craft could be acquired for approximately 15 million dollars.

An Army Streamlined Acquisition Program (ASAP) approach would be required because of the need to further develop some of the technology and to perform a systems integration effort. The results from the requirements analysis made it possible to move quickly to ensure that adequate funds were programmed for the acquisition, and to refine the Acquisition Strategy. Once the results from the requirements analysis became available, the Transportation School (T-School) became an enthusiastic supporter of the program. The management at Watercraft R&D Center, however, was very much annoyed at having been shown to be technically incorrect; thus, they only half-heartedly supported the program. Even so, the LAMP-H project appeared at last to have been established as a viable project. However, as it turned out, it was only the beginning of the problems with the LAMP-H project.

Program Development Maturation

Two very significant senior leadership changes occurred shortly after the LAMP-H project was solidified as a viable project. First, a senior position called the Program Executive Officer (PEO) was established throughout the Department of Army to provide an executive sponsor for each program. A visual of how the new PEO structure affected the lines of authority in the Department of Army organizational structure is shown in Figure 2.

The implementation of the PEO structure led to the Project/Program Managers being taken from under the Troop Support Command, and being placed under the authority of the new PEO. This same organizational change was made with all Product/Project/Program Managers under the Army Materiel Command. As a result, the PEOs reported directly to the Assistant Secretary of the Army for Research, Development and Acquisition (ASARDA), which meant that the PEOs were placed in charge of all programs/projects, and that the Army Materiel Command no longer had any management control of the programs. Hence, the Army Command could no longer take funds from programs, which was an early try at achieving what Matta and Ashkenas (2003) call “Balancing Vertical and Horizontal Activities.” Combined with a matrix management approach, this theoretically provided the capability to achieve rapid results both vertically and horizontally, which was precisely what the Department of Army had envisioned when it reorganized into the PEO structure (Kerzner, 2003).

The Program Executive Officer (PEO) position over the Watercraft project manager was filled by a man who came from a senior position on the Department of Army staff. Although he was supposed to have been the LAMP-H program sponsor and to have supported the program at the senior levels in the Department of Army and the DOD, he came to his new position with no acquisition experience. As the project drew on, it became apparent that he neither understood the significance of the program nor it’s Acquisition Strategy.

The second leadership change that occurred in the Watercraft Product Manager organization (the LAMP-H’s home) was the appointment of a new Product Manager (PM). This new PM had also come directly from the DOD. But unlike the PEO, this new project manager had come with an excellent acquisition background. He had completed the DOD Program Management School where he had learned many new ideas as to how systems should be acquired. As a result of his training, he believed that he should be firmly in control of his programs. He was a staunch advocate of the Army Streamlined Acquisition Program (ASAP) approach to systems acquisition, which led him to be an enthusiastic supporter of the LAMP-H Acquisition Strategy. The new PM, as it turned out, proved to be a very effective manager. He had come to accept new approaches regarding concurrent engineering and the need to build prototypes on production tooling in order to minimize the number of system configuration changes.

Shortly thereafter, the LAMP-H project manager was promoted to Deputy Product Manager (DPM) and began to enthusiastically promote these new approaches. This resulted in the new PM and his Deputy being in direct conflict with their new boss, the PEO, and departmental managers and workers on whom the project/product managers relied for matrix support (Kerzner, 2004; Killian, 1971). Although the PEO ostensibly supported the LAMP-H program, he obscurely entertained great reservations about it. The PEO’s lack of knowledge about the basic acquisition process prevented him from understanding any new innovations to the acquisition process. Additionally, the PEO preferred to abstain from conflict with departmental managers and workers, and thus, became very nervous with disagreements that the departmental managers and workers had with the new PM and the DPM regarding the new approaches taken with respect the project. The PEO, as it turned out, valued political favor above his mission.

The PEO's true intentions about the LAMP-H project were revealed when the R&D funds for the LAMP-H project were cut. It was essential that the R&D funds be restored, so as to not cause the program to suffer a break in activity. Although the PEO had the power to restore the funds, he continually delayed the restoration, which caused slippage and the need for the entire Acquisition Strategy to be revised and re-justified. It later became clear, that he was hoping his benign neglect of the LAMP-H project would cause program termination because the complexity of an R&D program with two IPRs made him very nervous.

Another factor that delayed the program was the T-School’s untimely completion of the Required Operational Capability (ROC) Document (Metzger, 2003), which is indispensable in DOD acquisitions. The ROC legitimizes a project by specifying the exact capabilities to be acquired. ROC approval was required before R&D funds could be spent on further project development. To this point, the ROC had only been circulated in draft form, and had existed in this unapproved form for seven years with almost no attention. Revision and staffing of this document were handled in a very nonchalant way even though the T-School had been told on several occasions that the ROC had to be approved before funds could be spent on the LAMP-H program.

IPR Approval Process

The in-process review (IPR) period proved to be an interesting time for the project manager and his deputy. The IPR authorized the release of the Request for Proposal (RFP) to invite submissions detailing how a contractor would, if selected, construct a vehicle to satisfy the LAMP-H requirements. The preparations required for the IPR and the release of the RFP included four principal program management documents: the ROC; the Test and Evaluation Master Plan (TEMP); the Integrated Logistics Support Plan (ILSP); and the Acquisition Strategy. The TEMP and the ILSP could be taken to the IPR in draft format; however, it was necessary that the ROC and the Acquisition Strategy be approved prior to the IPR. A matrix team was formed and a small contract executed for preparation of the Acquisition Strategy, the ILSP, and some of the program management documents, so that the outputs needed would be completed in time for the IPR. The Watercraft R&D Center in coordination with the Test and Evaluation Command (TECOM) was tasked with preparing the TEMP.

Program Destruction

In order to proceed with the development for the LAMP-H system was to have been released just after the in-process review (IPR). After all of the effort exerted on the LAMP-H by various stakeholders, unfortunately, this deadline was not met. The PM and the DPM moved on to other positions shortly after the missed deadline. The RFP still had not been released at the time of their departure. Subsequently, a new inexperienced project management team was formed, and unfortunately willing to accommodate whatever might be requested by various stakeholders, regardless of whether the requests were supported by the requirements analysis. Finally, the RFP, which was expanded to include all of the special interests and additional requirements, was released twelve months late. When the bids arrived from the contractors, it was evident that something was terribly wrong. It seemed that the inflated requirements had led the contractors to bid from 175 million to 225 million dollars for the R&D portion of the project while only 50 million dollars had been budgeted and approved. Also, the unit cost of the LAMP-H as bid by the contractors ranged from 30 million to 43 million dollars wherein only 15 million dollars per unit had been budgeted. An attempt was made by the new PM to obtain more R&D funds and to extend the program by another year. This resulted in withdrawal of the production funds and cancellation of the LAMP-H project within a short time after the request. And so, after the expenditure of many thousands of man-hours and dollars over a 15 year time period, a fully justified system that was badly needed by the military was terminated at a cost of 5 million dollars to U.S. taxpayers.

LAMP-H Case Analysis & Conflict Identification

The major problem identified and the focus of this case study is organizational conflict management, which has three main domains as previously discussed: interpersonal- based conflict, task-based conflict, and process-based conflict (Coser, 1956, Guetkow & Gyr, 1954; Hearn & Anderson, 2002; Jehn, 1995, 1997; Pinkley, 1990). As articulated above, the inability to manage or resolve the various types of organizational conflicts that occurred throughout the LAMP-H project led to costly people, plan, and process deviations. More specifically, the attempts by the various stakeholders to increase the expected performance of the LAMP-H without corresponding increases to the budget and timelines to account for the increased costs and scheduling, led to an increased level of risk, and ultimately, the demise of the LAMP-H project. The next section will describe the interpersonal-, task-, and process-based conflicts that took place throughout the LAMP-H project, which will be followed by practical conflict management lessons that managers can learn from the DOD LAMP-H project.

Interpersonal-Based Conflict

Symptom #1: Interpersonal/Interdepartmental Conflict between Project Manager and TECOM & Project Sponsor

The Acquisition Strategy required that the R&D phase of the LAMP-H program be executed within 36 months. This was done in order to conform to the three years of R&D appropriation that had been programmed, and the guidelines of the Army Streamlined Acquisition Program (ASAP). This meant that the TECOM community had to tailor its test program so that it could be completed within the ASAP structure, which is a process-based conflict that led to an interpersonal/interdepartmental conflict. This led to a sharp reaction from Test and Evaluation Command (TECOM) personnel who insisted upon having a “business-as-usual” test program. Though it was demonstrated that a perfectly satisfactory test program could be achieved by tailoring the standard test program to the demands of the ASAP and that acquisition regulations provided for such a program, the testers were completely inflexible on the matter. Even after it was pointed out that lengthening the test program would cause the program to slip and result in the loss of the LAMP-H project, the testers were still not willing to tailor the test program. All of this led to a sharp conflict between the PM and TECOM. Although the PEO was the program sponsor and should have mediated this problem, he exhibited an aloof indifference and avoided lending any help to the PM in terms of problem resolution. This conflict continued between TECOM and the PM, thru the In-Process Review (IPR) period, until the LAMP-H program was eventually terminated.

Symptom #2: Interpersonal/Interdepartmental Conflict between Watercraft R&D Center and Contractor R&D Center

Another area of serious conflict was in the preparation of the Request for Proposal (RFP), which is a task-based conflict that led to an interpersonal/interdepartmental conflict. In order to expedite preparation of the RFP, the aid of a support contractor had been enlisted. About the time that the RFP was complete, the Watercraft R&D Center protested that it must prepare the RFP. Although the Program Executive Officer (PEO) could have prevailed against this protest, he failed to do so, supporting the R&D Center’s position, and permitted them to prepare the RFP. Instead of taking the then complete RFP and making any refinements that might have been required, the Watercraft R&D Center started over, entirely from the beginning, completely redoing the RFP. This ultimately resulted in a program delay of about twelve months.

Symptom #3: Interpersonal/Interdepartmental Conflict between Transportation School and Legal Advisory Department

The Source Selection Plan was an area of conflict between the Transportation School and the Legal Advisory Department because of the Legal Advisory Department’s objection to the Source Selection Plan having been based upon a “best value” selection criterion. Although the acquisition regulations provided for a “best value” approach to source selection, it seems that legal advisory personnel had never been involved in any such approach to source selection and were afraid to attempt it because, “We’ve never done it that way before.” Therefore, this process-based conflict led to another interpersonal/interdepartmental conflict. The legal advisor, subsequently, insisted upon a complete revision of the Source Selection Plan. So it was with great dissention, a sharply divided state of affairs, and great reservations upon the part of the PM that the LAMP-H project was taken to the Milestone II In-Process Review to obtain approval for entry into the development phase.

Task-Based Conflict

Symptom #1: Task Conflict as to the Logistical Support System

This area of conflict had to do with the logistical support system for LAMP-H. Since the LAMP-H was to have been a low-density system, the requirements analysis disclosed that 30 LAMP-H systems should have been purchased. With no repurchase contemplated, a tailored logistical support concept had been developed in which testing of the logistical support package was to have been done during developmental testing of LAMP-H. This also provoked a reaction from the logistical community. As had been the case with the testers, the logisticians were also unwilling to tailor their desires to meet the demands of the ASAP program for the LAMP-H project. This problem area was never entirely resolved before the first IPR.

Symptom #2: Task Conflict about Data Requirements

Another area of conflict that arose as the program management documents were being prepared had to do with the amount of data that would be requested by the government in the RFP. The testers, the logisticians, and the engineers all wanted large quantities of data, far more than was reasonably required. The project manager was emphatic that such large quantities of data were far too costly and were not required for a project such as the LAMP-H. This dispute continued until well after the first IPR, and eventually delayed the release of the RFP.

Symptom #3: Task Conflict about Product Requirements

When the T-School finally produced its approved ROC, it was evident that it had become an enthusiastic supporter of the LAMP-H program. The T-School had become so enthusiastic that it had inflated requirements in the ROC far beyond what could be operationally justified. It insisted upon having a payload of two Abrams tanks, even though this was not supported by the requirements analysis. It also insisted that the LAMP-H be decontamination survivable, an immensely expensive requirement. A third requirement that had never been contemplated during the program planning was a computerized maintenance diagnostic system. When it was pointed out to the T-school that previous planning had never included these requirements and that there was not sufficient funding programmed to pay for them, the reaction was one of indifference. Even admonitions that the program might be canceled failed to elicit any change of attitude.

Process-Based Conflict

Symptom #1: Conflict pertaining to Timing of the Requirements Analysis in the Process

The requirements analysis is typically done early in the project management process so that all product and project specifications and funding requirements are defined. In this case, a requirements analysis was not completed at the inception of the project. Unfortunately, the requirements analysis was not initiated until the Department of Army threatened to withdraw funds for the projects. The requirements analysis was eventually conducted and the results were used to support the continuation of the project.

Symptom #2: Conflict regarding the Process of Awarding Scoring Weights

The Source Selection Plan also proved to be another area of sharp contention. In order to emphasize logistical supportability and low operation and maintenance costs, the DPM had written the plan so as to reward the greatest scoring weight in the area of supportability, with performance having a lesser weight. The Transportation School insisted, however, that performance have the greatest scoring weight. Even though it was pointed out that this was in conflict with the requirement to minimize operation and maintenance costs, Transportation School personnel refused to retract their position.

Symptom #3: Process Conflict within the Matrix Support Structure

Theoretically, the matrix management approach should have provided the capability to achieve rapid results both vertically and horizontally, which was precisely what the Department of Army had envisioned when it reorganized to the PEO structure. However, the PEO’s lack of knowledge about the basic acquisition process and his preference to avoid conflict with departmental managers and workers led to a lack of consensus in decision-making at the necessary authority levels. As previously stated, this resulted in the new PM and his DPM being in direct conflict with their new boss, the PEO, departmental managers and workers upon whom PMs relied for matrix support (Kerzner, 2004; Killian, 1971).

Practical Implications of the DOD LAMP-H Project

Interpersonal-Based Conflict Management Lesson – Use Compromise or Collaboration Strategy

It is vitally important to the success of a project that the project manager effectively manages his or her relationships with the project sponsor, other relevant organizational managers, and contractors. Oftentimes, the management of these relationships must take place concurrently throughout the life of the project. As evidenced by this case analysis of the LAMP-H project, the project manager, for various reasons, was unable to successfully manage the multiple relationships with the various entities that were involved in the project.

In the case of managing his or her relationship with the project sponsor, it is suggested that the project manager execute a collaboration strategy. While this strategy may take the longest of all of the conflict management strategies to implement, it is very important that the project manager and the project sponsor are in full agreement about all details regarding the project if a successful outcome is desired. With respect to the management of his or her relationships with other relevant organizational managers and contractors, the project manager may want to employ a compromise strategy or a collaboration strategy when necessary. Without the cooperation of the other managers and the contractors, it is unlikely that the project will be a success.

Task-Based Conflict Management Lesson – Use Competing, Compromise, or Collaboration Strategy

Another critical conflict area for a project manager to manage is project requirements or tasks. Typically, project requirements are stipulated at the onset of a project. When the requirements, whether they are product requirements or data requirements, as in this case, are changed significantly late in the project process or much beyond the original scope of the project, it puts the completion of the project at risk. The project manager needs to determine the power, position, or influence of the stakeholder to determine which conflict management strategy to employ. If the project stakeholder has very little power or influence and is not in a position to detrimentally impact the project, then the project manager may want to use the competing strategy. If the project stakeholder holds a fair amount of power and influence and is in a position to detrimentally impact the project, the project manager would want to use the collaboration strategy if time permits or the compromise strategy if time is of the essence.

Process-Based Conflict Management Lesson – Use Competing or Compromise Strategy

A third potential area for conflict is with the project process. In project management, there are sequences of events that must take place in order for the project to progress successfully. In many cases, the steps in the process are not controlled by the project manager because they are mandated or required from above. When steps in the process are mandated, the project manager should use a competing strategy to get all project stakeholders to comply with the required steps. It would be helpful if the project manager educates the project stakeholders as to why the steps are required and as to why he or she is forcing everyone to comply with the steps. In some cases, the steps may consist of general guidelines and not mandates. When the steps allow for flexibility in the guidelines, then the project manager has some leeway, and therefore, may want to use a compromising strategy so that all project stakeholders have some input in the process where possible.

Another area of process-based conflict was the organizational structure. The goal of the matrix support structure is to help balance the necessary authority levels between functional and project management so that a consistent message is communicated from one organizational level to another. Thus, each authority level must adopt a group or consensus-based approach to decision making to ensure that a workable compromising strategy is achieved, thus avoiding authority conflicts and reducing the risk of projects becoming politicized. Dooley, Lupton, and O’Sullivan (2005) note that management can address potential conflicts between authority levels by making the reporting lines in the matrix structure transparent; otherwise workers will find themselves answering to multiple bosses and attempting to reconcile varying directions. Thus, the matrix structure could not achieve its intended purpose which was to balance operational issues (functionality driven) with developmental issues (project driven) due to the lack of a compromising strategy.

Inter-Domain Conflict Management Lesson

Conflict as articulated mathematically above, if not managed properly, can be detrimental to a project. Most projects cannot withstand significant overruns due to change in time and costs as a result of interpersonal-based conflict, task-based conflict, process-based conflict, or inter-domain conflict, which is some combination of three. Although change, risk, and conflict are inevitable in any project, “unmanaged change” (Kerzner, 2003), unmanaged risk, and unmanaged conflict are likely to contribute to a project’s demise. Kerzner (2003:695) states that

Another critical interdependency is the relationship between change management and risk management. Risks and Changes go hand in hand, which is one of the reasons companies usually integrate risk management and change management into a singular methodology. If changes are unmanaged, then more time and money are needed to perform risk management, which often takes on the appearance of and behavior of crisis management.

Al-tabtabai, Alex, and Abou-alfotouh (2001) discuss some of the causes of organizational conflict. One such cause, according to these authors, is that of managerial conflict. Managerial conflict is said to arise from “ differing practices advocated by respective organizations under different managerial units” (Al-tabtabai et al., 2001), which is an example of the interpersonal-based conflicts that took place within the LAMP-H project. Concurrently, task-based conflicts with conflicting product and data requirements and various process-based conflicts discussed above were also occurring. Thus, by the very nature of complex projects, whether large-, medium-, or small-scale, project managers of today must learn to develop effective conflict management skills and employ appropriate conflict handling intention strategies concurrently if they are to be successful in accomplishing their desired outcomes. Additionally, they must exercise individual strategic flexibility, which is defined as the “ capability to identify major changes in the external environment to quickly commit resources to new courses of action in response to change ” (Shimizu & Hitt, 2004). Project managers must also be able to identify and effectively manage major and subtle internal environmental changes, which are likely to include inter-domain conflict.

Conclusion

The effectiveness of individual employees, teas and entire organizations depends on how they manage conflict at work (Tjosvold, 1998). Managers spend an average of 20 per cent of their time managing conflict (Thomas, 1992), and evidence suggests conflict and conflict management substantially influence individual, group and organizational effectiveness. Managers must recognize that the deployment of situationally appropri- ate responses to conflict should produce more positive individual, group, and organizational outcomes (Callanan & Perri, 2006). Given the practical importance of conflict management in organizations, it is vital to use and develop theory in this area to offer project managers practical frameworks that can enable them to make better decisions (Dreu, Evers, Beersma, Kluwer, Nauta, 2001).

It has been stated previously that project management within the DOD is likely one of the most complex processes in the world. The LAMP-H project is an excellent example of how not to manage conflict within a project. Almost every conceivable obstacle relating to the three domains of conflict and inter-domain conflict that might be found in project management was encountered on the LAMP-H project. In fact, the organizational conflicts continued throughout the life of the project. The organizational conflict pitfalls illustrated in this case study can lead to the failure of a project. The conflicts identified in this case stemmed from conflicting relationships between and among various project stakeholders around interpersonal/interdepartmental, task and process requirements.

Nevertheless, practical conflict management lessons can be learned from this case study to enhance the likelihood of successfully managing and/or resolving conflicts that are likely to emerge while working on a project. Some factors that could contribute to the successful management of conflict on a project that can be learned from this case study are the need for a project manager to be able to identify the types or domains of conflict that are likely to take place concurrently and implement the appropriate conflict handling intention strategies concurrently to resolve or manage the conflicts. The pitfalls identified, the Project-Conflict Management Framework offered, and the lessons learned from this case study should facilitate project managers in making better decisions when dealing with conflict that can significantly increase the likelihood of a successful project management outcome.

Explanation / Answer

The Six Constraints

Time and Cost

These are considered the standard constraints. They are reflected in our estimates and presented as ranges (plus-or-minus). In PRINCE2™ terms, as long as we are operating (delivering our projects) inside that agreed range limit, we are considered on-target. Good project management practice requires us to provide ranges for these constraints – ranges representing the estimating uncertainties associated with a project's particular circumstances. (PRINCE2™ separates these estimating uncertainties from funds set aside for specific purposes: a Change Budget – a fund to implement requests for change to scope or quality characteristics, or a Contingency Budget – funds to respond to previously defined risk contingencies.)

Classically time and cost are the first place the sponsors look (and for some sponsors, the only place) to see if a project is “in trouble” – ie, not meeting stakeholder expectations. This is probably because they are the most tangible measurements: we have a due date and a budget – what could be simpler? For many on the sponsor level the “scope” and “quality” of the project are harder to grasp – and measure. The assumption very often is: “Of course it will do what it's supposed to. Isn't that what we're paying for? Make sure it works and get it done on time. I don't care what it takes, as long as it comes in within budget and on time!” It becomes easier to disguise some missing features, or gloss over quality checking. Since the sponsors usually aren't quite sure what the detail scope characteristics are, or what goes into “quality checking,” everyone is just as happy to see them ignored or minimized, in favor of time and cost.

In the classic model, Risk and Benefits constraints don't even exist, so they are certainly not under consideration. We will soon see the importance of the four other factors that make up the six constraints.

Scope

Scope doesn't have the same ease of definition – ie, as normally being defined through “ranges”. Scope refers to the particular deliverables (“products” in PRINCE2™ terminology), which have been agreed to by the project's owners. In most cases there are no “ranges of acceptability” for scope: we asked for particular items, and we expect to get them – neither more nor less. We can, however, represent scope as a range, and it might look like the following. I typically would ask the project manager to produce Item A. With “scope tolerance” I might say “I want Item A – that's a must. if you have enough time or money left (ie, you can afford it) I'd also like you to build me Item B. But if you can't, I can live with only getting A.” With this kind of scope tolerance, the project manager has flexibility on what is to be delivered, but within strict and agreed limits. Scope tolerance could also show up as a “negative” range as well: “I would like you to develop items C and D, but if you are running short on time or money, it's acceptable if you don't produce D”. Either of these situations might occur when there are essentials that the project must deliver, but there are other items which are discretionary, or can be delivered at a later date without compromising the project's key objectives.

Quality

The quality constraint (or “quality tolerance”) is actually quite similar to that of scope – except that quality focuses on characteristics of a deliverable. When we address quality we are not looking to add (or delete) a new item. We are only looking to alter or provide flexibility (or “breathing space”) for some feature of an already-defined item – or to assure that a particular characteristic is present and working properly (quality checking). Here's an example. If I am building you a custom-made table, and you say “I want the table only to be made from cherry wood,” then you have given me NO quality tolerance on that particular characteristic of the table. If, for some reason, I can't find cherry wood, then I do nothave the flexibility to substitute anything else, unless I ask your permission. With “quality tolerance” you might say “I want the table made out of cherry, but if you can't find cherry, or it is very expensive (above a certain cost), then I give you permission, in advance, to substitute walnut or oak.” You have just provided me with quality tolerance. You are not adding a new item, just giving me flexibility on one of the item's characteristics. If I can't find good cherry wood, I can use oak without getting your permission.

Quality tolerance also operates in the realm of exactitude, which is a traditional measure for quality criteria. It represents the degree to which a developed item matches its defined characteristics. For example, if I ask for a table to be exactly 1 meter long, then if it is delivered at 99 cm or 101 cm it would be rejected. As an alternative I might have quality tolerance of +/- 1 cm. That means I could deliver a product measuring 99.5 cm or 100.8 cm, and it would still be acceptable, passing its quality criteria.

Quality works in the same mode as the other constraints. For example, if a project is running late or over budget, the project manager may still be able to deliver the expected items – but they might not be tested as thoroughly (ie, we do not assure that the characteristics are present and working properly – very common!), or some characteristics of that item may be reduced or eliminated. This is how quality operates as a constraint. Some models of the triple constraint triangle use quality instead of scope as the 3rd leg of the triangle. In many classic situations, when time or cost was strained, it was quality – usually through less testing or verification, but sometimes through dropped characteristics – that was compromised.

Benefits and Risk

The last two elements of the six-constraint model are the newest and least-familiar ones, and could be considered controversial – except that they are both already present in projects. We are not creating them – we are just bringing them to the forefront and demonstrating how they interact with the “classic” constraints (time, cost, scope, and quality). When these two new constraints – benefits and risk – are not considered, they are likely to be neglected and produce a negative impact on the project and the organization. We will examine those potential consequences as we discuss each of them.

Benefits

First let us look at benefits. Benefits represent the value the project is expected to deliver to the organization. In PRINCE2™ terms, we don't do a project just because someone “feels” like it, or (in vague terms) “thinks it's a good idea.” PRINCE2™ requires the project to have a Business Case – a clearjustification, with measurable, agreed benefits that are expected to result from the project's outputs. If there is no clear justification, then the project should not be started, and if the justification disappears – or is reduced below an agreed-upon limit – the project should be stopped. (That “limit” will become our constraint.) As the project has deliverables that it produces, the benefits represent the value that those items are expected to have for the organization (in financial or other terms).

While a project's objectives may be to deliver a new sales system, its value would be in its ability to increase sales, or improve customer service. Either one of these we would want to measure, to determine whether the new sales system was worth the time and cost to create it. Even governmental or nonprofit (charitable) projects need to have a Business Case – some measurable means to focus the project, and to use to assess the effectiveness of the project. (It is rarely possible to assess all benefits during a project. In a PRINCE2™ environment we would regularly anticipate and assess expectedBenefits, and have a clear plan for an assessment of achieved benefits sometime after the delivery of the project's outputs.)

The benefits are affected by factors both internal and external to the project. PRINCE2™ recognizes that even if we are on time, on budget (cost), and meeting scope and quality expectations, a change in circumstances may indicate that it is no longer worthwhile to continue the project (ie, the benefits have diminished or disappeared). Considering benefits means we focus on the key question: “Do we want to continue expending limited organizational resources on work that has no discernible value to the organization?”

Here are a few examples.

I am a company developing a new product for our market. We will need to grab 25% of the market for that particular product for our investment to pay off. At the beginning of the project it looks like we'll get even more. Halfway through our one-year effort we hear the news: our major competitor has announced (and will start selling within 2 months) a product that is clearly superior to ours. We can still produce our item (and bring it to market), but it's quite clear we won't come close to breaking even. According to PRINCE2™'s approach, we have fallen below our “benefits tolerance” – and this constraint is under threat. With the triple constraint model we might have looked for the time or cost going outside acceptable limits – but here it's only the benefits that are in danger. We can still deliver to the expected time, cost, scope and quality – but we need the awareness (and measurement) of benefits to assess the viability of the project. The standard triple constraints are clearly inadequate to help us diagnose this problem, or its magnitude.

In this particular situation, we could pour in more funds (cost) to enable the project to come in earlier (reduce time), and therefore have a better chance of being competitive and achieving some (or all) of our benefits. It is the consciousness of this benefits threat – as one of our constraints – that has us looking to the other constraints to adapt to a change in circumstances.

In this same situation, we might also choose to cancel the project: we would rather cut our losses now, since we won't be able to get the return on our investment that initially justified the project. A benefits threat could also have been triggered by internal issues, such as senior management of the organization choosing to get out of the business that the project's deliverables would represent. (The degree to which a project supports organizational strategy is another way to define a Business Case or benefits measurement.)

The Sixth Constraint: Risk

Everyone recognizes the Risk on a project needs to be addressed and managed. We can see that in any project there may be a level of risk that we are simply not willing to live with, or “tolerate.” That is our risk tolerance. Its simplest and most common expression is in examining the probability of significant risks occurring, their potential impact on the project if they do occur, and our degree of willingness to live with those potential consequences. Risk refers to “opportunities” as well as “threats,” and can be applied in a similar manner.

“Risk Tolerance” of stakeholders is presented as an important consideration in the PMBOK® Guide's Management of Risk knowledge area, but how one establishes “risk tolerance” is not defined. Here you will see a clear, functional definition. These concepts can be brought back to the PMBOK® Guide and applied there as well.

The basic Risk model looks like this: (See Exhibit 1.)

Exhibit 1

Each of the numbers represents an identified (and documented) significant project risk. We would be particularly concerned about threats that fall in the upper right-hand corner: medium-to-high likelihood of occurrence and medium-to-high (negative) impact of the project if they do. The more serious the threat the greater effort we make to mitigate that risk. The “risk tolerance line” – here indicated as the thick line – represents the limit as to the level of risk the project owners are willing to “live with” (or “tolerate”) for that project.

Here is an example. Our project is developing a new product for our domestic market. We have identified several significant risks, which have been mapped into our model (Exhibit 1). Risks #1 and 2 represent risks that are under control, and are not significant enough to stop the project. We will look at risks 3 and 4.

First Scenario

Risk #4 is a Supplier risk. We have a great supplier, but they are having financial problems. The probability that they will have trouble delivering looks high right now; the impact would be that we couldn't deliver our product. As of now we haven't come up with any satisfactory mitigating responses that would protect us. The risk tolerance of the project owners could be: “We can't live with Risk #4 as it stands. If there are no options to deal with it, it's better to stop the project right now before we commit too many resources.” This particular risk is on the wrong side of their “risk tolerance” limit (which they had established). They could also say: “Let us look for additional ways to mitigate it – like an alternative supplier. If we can have a reliable contingency plan, the probability would still be high, but we would reduce the impact (to the “probability high, impact low” box), so the overall rating would fall below our risk tolerance line.” (See the new location of risk #4 in Exhibit 2.) The project risks are now within their constraint/ tolerance limit.

Exhibit 2

Second Scenario

Risk #3 is the risk that our market-dominant competitor might come out with a similar item. At this point that looks very unlikely (from what we know), but the impact on our project would be high if it did occur. (See risk #3 in Exhibit 1.)

Risk #3 is acceptable right now, since the probability is low, and it falls below the project owners’ risk tolerance line. If, during the project, we hear more reliable rumors that it is becoming increasingprobable that our competitor will come out with their product, then risk #3 would move to “probability high” with the same level of impact. (See the movement of risk #3 in Exhibit 2.) That would put the risk above the risk tolerance limit – ie, “we cannot live with that level of risk – we have to re-consider our situation.”

There could be three choices for the project owners at this point, with risk #3:

a) find a mitigating response that will reduce probability and/or impact to an acceptable level;

b) close the project down, since the project owners are unwilling to live with projects that have any risks above their agreed-upon risk tolerance line;

c) move the risk tolerance line to some point above the new risk level. (See the new solid line representing the revised risk tolerance in figure 3.) They can move risk tolerance just as cost or time limits might be re-set or adjusted. “We decided reluctantly that we have to go ahead and live with a higher level of risk, because this project is critical to our survival.”

Exhibit 3

How to Use the Six Constraints Model

We use the constraints model to help us control the project. Building on the examples we have provided above, the project manager with the sponsor/ stakeholders/ Project Board (Project Boards are how PRINCE2™ clarifies the sponsor role and responsibilities) establish what the project's (and phase/ stage) limits are in these six key areas. (Benefits and risk are usually defined down to the project and phase (stage) levels only; the other four are also scaled to the work package level, if required.) Together the six provide a complete set of guidelines for the project manager to know (a) what the sponsor/ stakeholders/ Project Board see to be important (since they have a vested interest in the project's success, and are providing the funding), and (b) what are their limits of acceptability in performance.

Constraints/ tolerances are set by the sponsor/ key stakeholders/ Project Board, so there are common, agreed expectations for a project. These constraints/ tolerances indicate for a project, as follows.

Scope: This is what the project is expected to deliver (if the scope tolerance is zero, the project must deliver no more and no less than what is specified).

Quality: The scope items are to be delivered with the defined characteristics (no deviation allowed if quality tolerance is zero), and all deliverables must be reliable – ie, the characteristics have been quality tested/ checked to the extent specified, so that they function as agreed..

Time/ Cost: The project manager is expected to deliver the final products/ deliverables within the agreed ranges. If the project is running late and/or costing more than the specified range, the sponsor/ stakeholders/ Project Board need to be informed, so they can decide how to proceed. If the project will end below the time or cost range, they also want to know, as other projects may be able to start earlier, or be able to use the unneeded funds.

Benefits: The sponsor/ stakeholders/ Project Board expect a minimal level of benefits to accrue from this project, or it may not be worthwhile to continue investing the agreed time and cost. (Even though we could deliver the agreed scope on time and within budget, to the expected level of quality, that does not mean the project is worth continuing. Delivered scope is not the same as benefits.) Similarly, if we see potential benefits running higher than our planned upper benefits tolerance range, the sponsor/ stakeholders/ Project Board may be willing to invest more time and money, or expand the scope, in order to assure (or take advantage of) those higher benefits.

Risk: We have agreement on the level of risk the sponsor/ stakeholders/ Project Board are willing to live with in the course of the project (their risk tolerance). If the project manager cannot control (mitigate/ transfer, etc.) major risks, then the sponsor/ stakeholders/ Project Board need to decide if they are willing to live with the greater risk exposure, or want the project to close down (“It's just too risky for us to move forward if we cannot mitigate, or don't have a contingency plan for risk ABC.”).

Balancing Constraints

Exceeding one or more of the constraint/tolerance limits is not a question of having done something “right” or “wrong”. It is an indicator that draws the attention of the project manager, to determine what has caused (or will cause) the deviation, and after analyzing possible consequences, devise a resolution coordinated with the sponsor/ stakeholders/ Project Board.

Well-thought-out constraints allow the sponsor/ stakeholders/ Project Board to “manage by exception” – ie, they allow the project manager to continue running the project, as long as none of those constraints is anticipated to be exceeded. If any of the six constraints has the potential to be exceeded, the project manager should approach the sponsor/ stakeholders/ Project Board to establish the cause and a course of corrective action (including possible cancellation of the project).

We have provided several examples of how an exceeding of one of the constraints can be balanced through examination/ extension of another constraint. In one case, a benefits threat (from a competitor's product coming out before ours) could be addressed by spending more money (cost) to get our product out earlier (time), or by taking greater risks, or by reducing or increasing the project's scope.

Here are a few other situations that the six constraint model would help to analyze and address.

a) Quality testing is on a tight schedule, generating greater risk that errors will not be detected and corrected. (This is a common situation – and presenting it in terms of “risk to the project” is more likely to get the attention of the sponsor/ stakeholders/ Project Board than just complaining.) There are additional implications, in that defective deliverables may threaten benefits as well. This could be addressed through additional time and/or funds to test properly.

b) Asking for additional scope or modification of characteristics (change requests) is addressed through additional funding and/or adding time to the project schedule. One would, or course, expect benefits to increase as well, and be worth the additional time/ cost.

c) A project is depending on the availability and functionality of an untested technology – a high risk situation. Allocating additional funds (cost) or time to confirm the reliability of the final deliverables may be a way of mitigating that risk. Alternatively, the company could reduce the risk by using a known technology, but that may cause the scope of the project to be reduced, or may reduce the expected benefits.

Notice the complex interactions between the constraints. Making changes – adding scope or quality – will (hopefully) increase benefits, but may also increase risk (that the changes may impact negatively on existing scope/ characteristics). Taking greater risks may increase benefits, but also have the potential to damage benefits if the risks don't work out. Taking more time may reduce risks (through better quality testing), or increase risk (if our product gets to market too late to compete effectively against other companies’ products, which would also reduce benefits). The six constraints constantly influence and affect each other throughout the project.

Where the Six Constraint model fits into the PMBOK® Guide

Even though it defines the Triple Constraint as “a framework for “evaluating competing demands,” the PMBOK® Guide makes no specific reference as to how or when to apply the Triple Constraint to do just that.

It is clear, though, that application of the constraints/ tolerances occurs in 2 key points in the PMBOK®Guide's process flow. The first is in planning, where we have to assess:

The second area is in monitoring/ control, where consideration needs to be given to:

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.