Application 2 – Annotated Bibliography

How NOT to Manage a Project:

Conflict Management Lessons Learned from a DOD Case Study

J. Scott Sutterfield

Florida A&M University School of Business and Industry

Shawnta S. Friday-Stroud

Florida A&M University School of Business and Industry

Sheryl L. Shivers-Blackwell

Florida A&M University School of Business and Industry

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: r = f(c,s,p)

where r – overall risk of conflict c – cost of conflict s – 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:

1. Identification of conflict as the problem 2. Identification of symptoms of the problem and classification of them as

interpersonal-, task-, or process-based conflict

3. Setting strategy selection criteria 4. Identification of alternative conflict handling intention strategies for each symptom

based on domain classification a. Avoiding (Neglecting, Withdrawing) b. Competing (Asserting, Distributive, Dominating, Forcing) c. Accommodating (Appeasing, Obliging) d. Compromise (Sharing) e. Collaboration (Integration, Problem-Solving)

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

6. 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 for

approximately 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

Activity/Event Date Identification of LAMP-H Requirement Year 1 Deputy Project Manager Appointed Sept, Year 10 Requirements Analysis (RA) Undertaken Sept, Year 11

RA Results are Forthcoming Nov, Year 11 – May

87, Year 12 PEO Structure Established Mar, Year 12 New PEO Appointed Apr, Year 12 New Project Manager Appointed July, Year 12 RA results in Project Funds Restoration Aug, Year 12 RA Refinement and Project Coordination in DOD

Sep, Year 12 – Jun, Year 13

Matrix Management Team Formed Jul, Year 13 Program Management Documents Preparation

Jul, Year 13 – Dec, Year 14

IPR to Enter Development Phase Dec, Year 14 Continuing Conflict Over Requirements Jan – Jun, Year 15 New Project Manager Appointed Jul, Year 15 Deputy Project Manager Reassigned Mar, Year 16 Request for Proposal (RFP) Released Jan, Year 16 LAMP-H Project Terminated Jun, Year 16

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.

Figure 1. Army Structure before Implementing PEO

DoD

ArmyNavy Air Force

Army Materiel

Command

Test & Evaluatio

Training & Doctrine

Command

Other

Troop Support

Command

Transportation School

(T-School)

Other

Ft. Belvoir R&D Center

Watercraft PM

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.

Figure 2. Army Structure after Implementing PEO

DoD

ArmyNavy Air Force

Army Materiel

Command

Test & Evaluatio

Training & Doctrine

Command

Other

Troop Support

Command

Transportation School

(T-School)

Other Program Executive

Officer

Ft. Belvoir R&D Center

Watercraft PM

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 organiza- tional 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.

References Al-tabtabai, H., Alex, A. P., & Abou-alfotouh, A. (2001). Conflict Resolution Using Cognitive Analysis Approach. Project Management Journal, 32 (2), 4-16.

Barki, H., & Hartwick, J. (1991). Interpersonal conflict and its management in information system development. MIS Quarterly, 25(2), 195-228.

Blake, R. R., & Mouton, J. S. (1964). The managerial grid. Houston: Gulf. Callanan, G.A., & Perri, D.F. (1996). Teaching conflict management using a scenario- based approach. Journal of Education for Business, 81(3), 131-139. Coser, L. A. (1956). The functions of social conflict. New York: MacMillan. De Dreu, C. K. W., Evers, A., Beersma, B., Kluwer, E. S., & Nauta, A. (2001). A theory- based measure of conflict management strategies in the workplace. Journal of Organizational Behavior, 22 (6), 645-668. Defense Systems Management College (DSMC) (1989). Systems Engineering Guide.

Washington, DC: Department of Defense.

DOD/Defense Acquisitions University (DAU) (2002). Risk Management Guide for DOD Acquisitions. Washington, DC: Department of Defense. Dooley, L., Lupton, G., & O’Sullivan, D. (2005). Multiple project management: A modern competitive necessity. Journal of Manufacturing Technology Management, 16 (5/6), 466-482. Eisenhardt, K.M. (1989). Building Theories from Case Study Research. Academy of Management Review, 14, 532-550. Griffard, B. (2002). Shortening the Defense Acquisition Cycle: A Strategic Imperative. Issues Paper 13-02. Carlisle Barracks, PA: Department of Defense.

Gross & Guerro, (2000). Managing conflict appropriately and effectively: An application of the competence model to Rahim’s organizational conflict styles. The International Journal of Conflict Management, 11 (3), 200-226. Guetkow, H., & Gyr, J. (1954). An analysis of conflict in decision-making groups. Human Relations, 7, 367-381. Hearn, J.C., & Anderson, M.S. (2002). Conflict in academic departments: An analysis of disputes over faculty promotion and tenure. Research in Higher Education, 43 (5), 503- 529. Hocker, J. L., & Wilmot, W. W. (1998). Interpersonal conflict 5th ed. Madison, WI: Brown & Benchmark. Hosking, James E. (2005). Lessons learned: Seven keys to a successful replacement hospital project. Journal of Healthcare Management, 50 (1), 8-11.

Jehn, K.A. (1995). A multi-method examination of the benefits and detriments of intra- group conflict. Administrative Science Quarterly, 40, 256-282. Jehn, K.A. (1997). A qualitative analysis of conflict types and dimensions in organizational groups. Administrative Science Quarterly, 42, 530-557. Kerzner, H. (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, NJ: John Wiley & Sons, Inc.

Kerzner, H. (2004). Advanced Project Management: Best Practices on Implementation. Hoboken, NJ: John Wiley & Sons, Inc.

Killian, W. P. (1971). Project Management – Future Organizational Concepts. Marquette Business Review, 2, 90-117.

Kimmons, R. L. (1990). Project Management Basics: A Step by Step Approach. New York and Basel: Marcel Dekker, Inc.

Matta, N. F., & Ashkenas, R.N. (2003). Why Good Projects Fail Anyway. Harvard Business Review, 81(9), 109-114.

Metzger, J. (2003). JWAES: A Case Study. Project Management Journal, 34 (4), 40-46. (Note: The Required Operational Capability (ROC) document is now known as an Operational Requirements Document (ORD)).

Office of Inspector General (2001). Audit of Major Defense Acquisition Programs Cycle- time, Report No. D-2002-032, Project No. D2002AB-0066.000. Washington, DC: Department of Defense.

Papa, M. J., & Canary, D. J. (1995). Conflict in organizations: A competence-based approach. In A. M. Nicotera (ed.). Conflict and organizations: Communicative processes. State University of New York Press: Albany, NY; 153-179. Pinkley, R. L. (1990). Dimensions of conflict frame: Disputant interpretations of conflict. Journal of Applied Psychology, 74 (2), 117-126. Robbins, S.P., Judge, T.A. (2005). Organizational behavior, 12th ed. Upper Saddle River, NJ: Prentice Hall. Royer, I. (2003). Why bad projects are so hard to kill. Harvard Business Review, 81 (2), 48-56.

Shimizu, K., & Hitt, M. A. (2004). Strategic flexibility: Organizational preparedness to reverse ineffective strategic decisions. Academy of Management Journal, 18 (4), 44-59.

Thomas, K. W. (1992). Conflict and negotiation processes in organizations. In Dunnette MD, Hough LM (eds). Handbook of Industrial and Organizational Psychology, 2nd ed, Vol. 3, Consulting Psychologist’s Press: PaIo Alto, CA; 651-717. Tjosvold, D. (1998). Cooperative and competitive goal approach to conflict: accomplishments and challenges. Applied Psychology: An International Review, 47, 285-342. Tutzauer, F., & Roloff, M. E. (1988). Communication processes leading to integrative agreements: Three paths to joint benefits. Communication Research 15, 360-380. Willoughby, W. J. (1986). Best practices. Department of the Navy, NAVSCO P-6061. Washington, DC: Department of the Navy.

Best Quality Custom Writing Services

Application 2 – Annotated Bibliography

Application 2 – Annotated Bibliography

Engage Quality Experts

Excellent Client Support

Get it before Your Deadline

You Need a Professional Writer To Work On Your Paper?

Privacy Policy

Do you have an Urgent Assignment?