Defense ARJ - Defense Acquisition University

More documents

Recommendations

Info

<strong>Defense</strong> <strong>Acquisition</strong> Review Journal tAble 10. tradoC Changes and proJeCt perforManCe One would expect that the doctrinal and operational underpinning for the systems’ requirements should have been relatively constant (during this late Cold War period), but the authors found a substantial number of changes in systems requirements for these cases. The question, therefore, lingers: Did the changes in TRADOC personnel found here somehow play a role? New personnel may not feel that their predecessors had correctly defined the threat’s implications on requirements, or having not been a party to earlier discussions, been more willing to pursue changes suggested by new knowledge and events. This suggestion raises the possibility that TRADOC personnel change could have adverse, indirect effects by somehow permitting changes in systems requirements that have, in turn, a negative impact on project performance. This study analyzed the relationship between early TRADOC staff changes and shifts in systems requirements and found some support for that view. As noted previously, the results in Table 10 suggest that the most damaging requirements changes 126 Average number of successful outcomes TRADOC change during early development? TRADOC change in early stages* of project? Did system requirements change during mid development? Staff change No change No change Signif. at 2.40 (5) 4.29 (7) .011 tAble 11. Changing systeMs reQuireMents and Key tradoC personnel In one stage In both stages No 5 3 0 Yes 0 2 2 Total 5 5 2 Tau B = 0.0685, significant at 0.001 *pre-development or early development The most damaging requirements changes are those that occur in mid-development.
lessons froM tHe DeVeloPMent of arMy systeMs tAble 12. proJeCt duration, instaBility and field perforManCe How often did systems requirements change? are those that occur in mid-development. To look for a relevant relationship, one can aggregate TRADOC changes by asking whether there were key staff changes during the technology selection/planning period or during early development (the two earliest time slices in the project). One can then compare the projects that did or did not have these early key TRADOC personnel changes. Table 11 shows that five projects avoided early TRADOC changes, and none of the five had mid-development changes in systems requirements. Of the five projects that had TRADOC changes in one of these early stages, two experienced requirements changes. The two projects that had TRADOC changes in both planning and early development saw later requirements changes in mid-development. It would appear that TRADOC turnover in the early stages of projects is in some way related to mid-development changes in systems requirements. conclusions Three years or less Four years or more Never 4 0 Once or twice 3 2 Several or many times 0 4 Tau B = .723, significant at .001. Did system have operational problems in the field? Total 7 6 Did not meet expectations 1 4 Met expectations 4 2 Exceeded expectations 2 0 Tau B = -.556, significant at .003. Total 7 6 Taken together, these several relationships strongly suggest that stability of program resources, staffing, and objectives is a very powerful influence on the relative success of projects. Certainly, as has been noted, a wealth of anecdotal evidence suggests that this should be the case. In reflecting on this array of instabilities that could impact a system development, it became clear that they had at least one thing in common. That is, the longer a system stayed in development, the greater chance it had to experience one or more of these program destabilizing events. Support for this view is found when the occurrence of cutbacks and systems requirements changes are related to the duration of the 13 development projects studied 127
Page 2 and 3: Vacant Office of Small Business Pro
Page 4 and 5: 133 151 disruption of testing regim
Page 7 and 8: Defense ARJ executiVe eDitor Defens
Page 9 and 10: July 2008 Joint attack Munition sys
Page 11 and 12: Does orGaniZational leVel influence
Page 13 and 14: creatiVe Potential anD PracticeD cr
Page 31 and 32: lessons froM tHe DeVeloPMent of arM
Page 33 and 34: tAble 1. suMMary Case inforMation S
Page 41: tAble 9. Continuity of tradoC staff
Page 49 and 50: HoW to Make incentiVe systeM of anD
Page 51 and 52: tAble 2. suMMary of Consensus views
Page 63 and 64: conclusions HoW to Make incentiVe s
Page 65 and 66: endnotes HoW to Make incentiVe syst
Page 67 and 68: PPBe: a reD or a Blue Pill? PPBe: a
Page 69 and 70: PPBe: a reD or a Blue Pill? 1995).
Page 71 and 72: PPBe: a reD or a Blue Pill? cation;
Page 73 and 74: Our policy to counter international
Page 75 and 76: PPBe: a reD or a Blue Pill? reminis
Page 77 and 78: PPBe: a reD or a Blue Pill? process
Page 79 and 80: PPBe: a reD or a Blue Pill? COE. As
Page 81 and 82: PPBe: a reD or a Blue Pill? with th
Page 83 and 84: RefeRences PPBe: a reD or a Blue Pi
Page 85 and 86: PPBe: a reD or a Blue Pill? Martin,
Page 87 and 88: PPBe: a reD or a Blue Pill? Wachows
Page 89 and 90: PPBe: a reD or a Blue Pill? 6. The
Page 91 and 92: systeM of systeMs DeVeloPMent syste
Page 93 and 94:
tHe Defense acQuisition fraMeWork:
Page 95 and 96:
systeM of systeMs DeVeloPMent tHe D
Page 97 and 98:
systeM of systeMs DeVeloPMent searc
Page 99 and 100:
systeM of systeMs DeVeloPMent “em
Page 101 and 102:
systeM of systeMs DeVeloPMent for l
Page 103 and 104:
systeM of systeMs DeVeloPMent DAPA
Page 105 and 106:
� � systeM of systeMs DeVeloPMe
Page 107 and 108:
RefeRences systeM of systeMs DeVelo
Page 109 and 110:
endnotes systeM of systeMs DeVeloPM
Page 111 and 112:
a GliMPse into DoD WeaPon systeMs P
Page 113 and 114:
� � � � � � � systeM
Page 115 and 116:
systeM DoD WeaPon of systeMs DeVelo
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123:
Page 126 and 127:
Defense Acquisition Review Journal
Page 128 and 129:
Page 130 and 131:
defense Acqu s t on un vers ty web
Page 132:
show all

Defense ARJ - Defense Acquisition University

Create successful ePaper yourself

Delete template?

Save as template?