Cycle time reduction in defense acquisition: the department of defense must be able to evaluate, acquire, and deploy new technology rapidly in order to accomplish its mission. a more flexible approach can bring dOd development processes more in line with commercial practices and substantially reduce cycle time.
One area where performance has been a perennial issue has been in the area of cycle time, the time required to develop and field a new system (US GAO 2003). The DoD system development process, which dates to the 1960s, was intended to manage the achievement of technical performance requirements, control costs, and meet schedule objectives. However, the process has often generated inadvertent consequences for cycle time. Substantive reforms in the process have created greater congruity with best practices in commercial product development, but cycle time reduction continues to be a critical challenge.
In recent years, the DoD community has begun to recognize that a more flexible acquisition process, like that used in commercial product development efforts, offers increased potential for reducing cycle time. This more flexible approach, advocated under the DoD 5000 series of acquisition directives, is in direct contrast to the traditional, more rigidly standardized approach to defense systems acquisition. The issues confronted by DoD in its acquisition processes suggest how schedule performance can be improved not only in defense projects but in product development in general. In this review, we examined the commercial literature and compared it with our experience and observations in over 20 DoD programs, all of which had a focus on cycle time reduction.
The DoD Acquisition Process
Defense acquisition differs from commercial product development in three important respects. First, in contrast to the direct relationship between customer and corporation that characterizes commercial product development, in defense systems development the customer (a military command representing the warfighters who will use the system) is separate from the government program office that manages the contractor developing the system. Second, although defense contractors, like commercial firms, attempt to maximize financial performance, the tolerance for cost overruns means that contractors often have insufficient incentive to control costs. Third, defense acquisition is subject to the Federal Acquisition Regulations (FAR), a regulatory framework designed to control waste, fraud, and abuse. The need to adhere to FAR requirements has implications for cycle time at all stages of the acquisition process.
The DoD acquisition process developed during the 1960s was relatively rigid and inflexible. In particular, the acquisition process tended to be applied to all systems regardless of the size of the program or production quantities. By contrast, in commercial product development, the processes that guide concept definition, prototype development, testing, and the sequence of corporate approval decisions tend to be varied, flexible, and customized to fit the particular requirements of each project (Cooper, Edgett, and Kleinschmidt 2004). Beginning in 2003, the DoD began to move toward a more flexible model more closely resembling commercial product development; this shift has been documented in the 5000 series of DoD acquisition directives (DoD 2003; Defense Acquisition University 2009).
The DoD acquisition process currently in use (Figure 1) includes phases for materiel solution analysis, technology development, engineering and manufacturing development, production and deployment, and operations and support. The preferred approach to systems development under this process is evolutionary; new systems are developed and deployed in increments to allow for shorter acquisition cycle times. Fielding a graduated sequence of systems means that, in contrast to prior practice, military personnel do not wait prolonged periods for deployment of a fully capable system, but are given access to systems capabilities as they are developed. Evolutionary acquisition also limits the design challenge for a new system by reducing the number of system components and subsystems that must be demonstrated to be reliable and producible using proven manufacturing processes before entering production. This, in turn, limits technological uncertainty and risk.
There are two basic processes of evolutionary acquisition. These differ based on the ability to specify end-state requirements. The first is incremental development; in this process the desired capability is identified, end-state requirements are established, and development occurs in incremental phases or blocks of preplanned product improvements with technology updated as it matures (US GAO 2003; Defense Acquisition University 2009). The second basic process of evolutionary acquisition is generally referred to as spiral development. In spiral development, the end-state requirement is not known, and each incremental upgrade is based on direct feedback from end users--military personnel in the field (US GAO 2003). Both processes aim to reduce technological risk and allow greater control of both cost and schedule (US GAO 2002). However, some evidence from computational modeling indicates that although schedule and cost may be reduced initially, subsequent incremental upgrades may result in greater total life cycle cost (Ford and Dillard 2009).
Figure 1.--The Department of Defense's acquisition system is a phased process The DoD Acquisition Process Materiel solution analysis. At the beginning of the acquisition process, representatives from multiple DoD agencies and commands assist in formulating broad, time-phased, operational goals and requisite capabilities. During this phase, multiple concepts and materiel approaches are subjected to detailed analysis, with the goal to optimize the way DoD provides the specified capabilities. The examination includes robust analyses that evaluate the affordability, maturity, and suitability for use by military personnel of the proposed technologies. The conclusion of this initial stage, generally referred to as Milestone A, is the materiel development decision. This is a stage-gate decision to proceed or not proceed. Technology development. The next stage is the funding and development of science and technology (S&T) research programs to further develop the required technologies and system-level solutions. It is the role of S&T research programs to address user needs; maintain a broad-based program spanning all defense-relevant sciences and technologies to anticipate future needs and those not being pursued by civil or commercial communities; preserve long-term research; and enable rapid, successful transition from the S&T base of basic and applied research knowledge to useful military applications (US GAO 2001a). Once there is confirmation that the technologies are sufficiently mature to begin system level development, funds are appropriated for the next stage. This approval of sufficiency of technology maturity and the appropriation of funds is generally referred to as Milestone B and initiates engineering and manufacturing development. Engineering and manufacturing development. In this phase, program objectives for cost, schedule, and technical performance are identified and design specifications are created. Engineering and manufacturing development is guided by the test and evaluation plan, which is developed concurrently. For defense programs, independent test and evaluation is required by law and is the responsibility of the appropriate DoD operational test agency. At the end of engineering and manufacturing development, a key design review takes place for an assessment of design maturity. In order to exit this phase, the system must demonstrate that it meets the approved requirements in its intended environment; this is Milestone C. Production and deployment. Attainment of Milestone C authorizes a project's entry into Low Rate Initial Production (LRIP). In this phase, operational testing and evaluation determine the effectiveness and suitability of the system. A review and decision following testing then authorizes full-rate production and subsequent deployment of the weapon system. Operations and support. Once the system has moved into full production and deployment, it must be sustained and supported over the life of the deployment. This requires a logistical support program that meets operational support performance requirements and sustains the system in the most cost-effective manner over its life cycle. Effective sustainment of weapons systems begins with the design and development of reliable and maintainable systems. Operational readiness is achieved through affordable, integrated, embedded diagnostics and prognostics, embedded training and testing, serialized item management coding of spare parts, and automated logistical identification technology. [ILLUSTRATION OMITTED]
In general, the DoD acquisition process and the acquisition changes enacted in the DoD 5000 series have been important improvements. However, problems do emerge in the implementation or execution of the process. In execution, inadequate systems engineering input before requirements are finalized, failure to implement concurrent engineering, poor composition of integrated product teams OPTs), and failure to implement design for manufacturability and maintainability may lead to delays and other challenges. Other factors that may create problems in the development process include insufficient contractor, supplier, and user integration; inadequate design flexibility for technology insertion; lack of continuity in system-specific expertise; insufficient incentives for timely completion of the project; and the lack of a product champion.
Cycle time reduction is important in defense projects in general. However, external conditions such as a rapidly evolving threat or rapidly evolving technologies can make time parameters for development, testing, production, and fielding of a system even more critical. Achieving cycle time reduction under such conditions requires the observation of several preconditions and a number of important project characteristics (Figure 2).
[FIGURE 2 OMITTED]
Preconditions for Cycle Time Reduction
Preconditions for cycle time reduction include a high level of maturity in the core technologies, the potential for use of standard or commercial off-the-shelf components, high-level and widespread support for the program at all levels, and a flexible and customizable acquisition process. Significantly, three of these four preconditions focus on reducing technological risk.
Maturity of core technologies. While the core technologies for a defense system may approach the state of the art, they must be sufficiently mature to ensure the optimization of engineering development on the critical path in the schedule. When the core technology is not sufficiently mature, technological uncertainty and risk increase, resulting in higher probabilities of schedule delay during development.
Numerous defense systems have encountered serious schedule delays because the system entered engineering development before critical technologies were sufficiently mature (e.g., the Comanche helicopter, the NonLine of Sight Launch System). This problem frequently stems from an underestimation of technological risk (US GAO 2001a), often compounded by the fact that the operational requirements stated by military commands influence program managers to define overly ambitious design objectives. Similarly, program managers may attempt to push the technological envelope too far too soon in the interest of securing necessary funding. Significant cycle time reduction can be achieved by enforcing a disciplined Stage-Gate [TM] screening process like that employed by many commercial product developers (Cooper, Edgett, and Kleinschmidt 2004).
Potential for use of commercial components. The use of non-developmental components or commercial "off the shelf" (COTS) components will generally reduce development time, but requirements specifications that articulate predetermined performance levels reduce the potential for using nondevelopmental components. Design decision criteria generally assign greater weight to technical performance with schedule receiving minimal weight as a decision criterion. When the schedule is critical, design decisions cannot simply maximize on variables such as survivability without regard for schedule implications. Rather, design decisions should be based on decision science optimization, whereby schedule criticality determines the weight that schedule receives in decisions that require trade-offs with other important technical performance criteria. By definition, this can result in the fielding of a core capability with lower technical performance levels. These tradeoffs must be balanced against the value of placing a capability in the hands of military personnel more quickly.
It should be noted that innovative engineering solutions can often be implemented to improve reliability and survivability while using off-the-shelf components. Then, once the baseline system is fielded, work can proceed on evolutionary developments that integrate successive generations of technology or offer other design improvements. However, when the need to field a baseline system rapidly is less critical, higher priority can be assigned to achieving technical performance levels; then, the assumption of greater technological risk may be justified, but the program office must be empowered with the necessary budgetary resources.
High-level, widespread support for the program. Programs requiring reduced cycle time need high-level support to ensure adequate funding and the budgetary stability necessary to optimize schedule. The absence of such support tends to threaten funding adequacy and prolong approval processes. The pattern is similar in commercial product development. Schon (1963) found that product development invariably suffered if the product champion was not able to obtain high-level executive sponsorship. In other research on cycle time in commercial product development, high-level support has been shown to result in budgetary allocations that allow for an accelerated schedule (Rubenstein et al. 1976). Further, high-level support facilitates the assignment of personnel with the highest levels of relevant technical talent and experience (McDonough and Spital 1984). In addition, internal sources of resistance are easier to overcome (Brown and Eisenhardt 1995).
There are numerous examples of success, and failure, in which sufficient high-level support made the difference. The remarkable schedule for Patriot PAC-2 prior to the Gulf War was made possible by the successful efforts of Brigadier General Lawrence Capps (Patriot program manager) to obtain Pentagon support and Office of the Secretary of Defense-directed funds for the anti-ballistic missile system (Sherman 2003b). The Tactical Unmanned Aerial Vehicle program and the Global Hawk program also benefited from similar support. In contrast, the technically elegant Fiber Optic Guided Missile (FOG-M) never achieved such support, and as a consequence of requirements instability, the program encountered endemic schedule delays, eventually resulting in its cancellation (Sherman 2006a).
Flexible, customizable acquisition process. There is increased potential for reduction in cycle time when the acquisition process itself is flexible, so that it can be customized to meet the specific development, manufacturing, and logistical requirements of the system. This approach, which is advocated at least in part in the DoD 5000 series of acquisition directives (US GAO 2001a; DoD 2003; DoD 2008), is in direct contrast to the traditional approach to defense systems acquisition, where the process followed a regulatory model with a higher degree of formalization and standardization.
The movement in DoD toward greater flexibility and customization of the process is consistent with the empirical management literature on contingency theory (Thompson 1967) and with best practices in commercial product development (Cooper and Kleinschmidt 2007). The development process should be characterized, as it is in most commercial product development processes, by a focus on product development goals, as opposed to the process itself. Excessive formalization of procedures, standardization of processes, and centralization of decision making tend to drive a psychological process of goal displacement whereby the focus shifts from product goals to bureaucratic process goals. Such displacement is psychologically subtle and may not be apparent to those who are subject to it.
Levers for Reducing Cycle Time
A number of project characteristics can influence cycle time reduction in defense acquisition. These project characteristics generally relate to flexibility and customization within the development process. Of course, the range of best practices for any new product development project should, if properly deployed throughout the process, work to reduce cycle time (see text box); other practices must be adjusted to facilitate minimization of cycle time.
Dialogue among the military command, DoD laboratories, and industry experts prior to finalizing system requirements. Flexibility and customization in the acquisition process allows for critical dialogue with the relevant military commands (including inputs from military personnel using focus groups and quality function deployment methods), pertinent DoD laboratories, and in some cases, experts from competing contractors.
Historically, requirements have typically been established before a program is approved. Program approval precedes funding for the contract that includes the conduct of systems engineering. Herein lies one of the systemic problems. The knowledge obtained through systems engineering occurs subsequent to the setting of requirements. Often, the sources with the greatest concentrations of system-relevant technical knowledge at the contractor or DoD laboratories have had little or no involvement in the shaping of requirements. This results in system development beginning with cost and schedule estimates that have not been tempered by systems engineering knowledge (US GAO 2001 a). In fact, requirements should be determined in dialogue between those who have the necessary level of systems engineering knowledge and the various sources influencing the definition of requirements. In this way, trade-offs can be negotiated before requirements are finalized, and cost estimating and scheduling can be improved.
The development of the Guardrail Common Sensor (GR/ CS) illustrates how setting requirements through dialogue can result in radical cycle time reduction (Sherman 2003a). In the case of the succession of Guardrail systems, the ESL division of TRW was the leading defense contractor for system-specific technical expertise. For the initial contract for the baseline system, requirements were set and the award of the contract was competitive. Thereafter, the contracts were sole-sourced to ESL as prime contractor. This facilitated the setting of subsequent requirements through dialogue. ESL engineers and government engineers (many of whom had moved with the program from the US Army Communications and Electronics Command (CECOM) labs to the program office) worked closely to develop requirements for each successive system. In light of the critical schedule and the rate at which core technologies were advancing, the military commands specified only general performance capability parameters and deferred to the judgment of the program office in the specifics. The practice of identifying a limited number of general performance parameters ("must-have" parameters) allows for greater flexibility in negotiating trade-offs in the finalization of requirements. This has implications not only for schedule but for cost control as well. In this case, ESL engineers identified requirements that might not be cost-effective or that could adversely affect schedule. The military commands further contributed to the requirements and funding stability by allowing for a spiral development process in which technology upgrades occurred as the system evolved through successive generations.
It is critical that the dialogue process not be dyadic and sequentially iterative among the various organizations influencing requirements. Too often, disjointed dyadic iterative meetings result in a process in which requirements become additive in order to achieve support commitments from all relevant organizations. The net result is limited trade-offs with an elaboration or increasing of requirements to satisfy all constituencies. Rather, all organizational representatives should meet together at each phase of spiral or incremental development to negotiate the design trade-offs to optimize schedule (Sherman 2003a).
Use of concurrent development processes to minimize the critical path. An important contributor to the reduction in cycle time in projects that involve multiple organizations is the optimal use of cross-functional, cross-organizational integration with concurrent development processes (US GAO 2001b). Effective cross-functional integration facilitates iterative learning and concurrent problem solving during engineering development and can significantly reduce schedule time in managing design changes (Meyer 1993). Furthermore, if properly implemented, it reduces the need for design changes, as design problems are identified and addressed earlier rather than later, when cost and redesign implications may be multiplicative (Brown and Eisenhardt 1995). A failure to maximize simultaneity in development lengthens the critical paths of projects by forcing groups responsible for downstream tasks to wait for previous stages to be completed (Kessler and Chakrabarti 1996).
Prime contractor, supplier, and user integration. Direct input from the user, defined here as the designated military command, during materiel solution analysis, technology development, and engineering development can provide valuable feedback regarding optimal design characteristics. While the command would be the primary source of input for the general performance parameters (or requirements), some flexibility in the determination of design characteristics would allow for direct input from the user in the field. This input may take several forms. Feedback from teams in the field, such as forward assistance support and technical teams, is relayed to the project office, which then coordinates with the contractors. Testing may assume the form of experimentation with sampled users. The experimentation may include different prototype versions with various characteristics. This information can then be utilized in design decisions.
Design flexibility for incremental or spiral development. One of the problems that defense systems projects encounter in areas where core technologies are advancing rapidly is the potential for components of the system to be obsolete a short time after the system is fielded (Sherman 2003a). An approach to engineering development that utilizes design flexibility to support planned system upgrades should reduce the cycle time associated with each successive generation of the system. Nowhere is this more evident than in the area of computer microprocessor technology. Design decisions that produce a unified open architecture with software standards, rather than hardware, becoming the basis for the system permit rapid upgrading as technology advances. Design decisions that favor an open architecture reduce cycle time in subsequent generations as the system proceeds along a path of evolutionary development.
To illustrate, during its early years, the Joint STARS program utilized custom-designed militarized versions of commercial components. This decision had significant cost and schedule implications for each generation of upgrades. In the 1990s, following the Gulf War, significant changes in the form of an open architecture and increased use of COTS components, particularly programmable sensors, resulted in reductions in cost and schedule for upgrading hardware and software for the system (Sherman 2006b).
Appropriate incentives to improve cycle time performance. Incentives and sanctions play an important role in influencing the behavior of both individual managers and defense contractors. For example, cost-plus-incentive-fee contracts can work well in a number of contexts, particularly during engineering development, when competition exists for subsequent production contracts. However, in some cases, engineering development contracts can be inadvertently structured to create incentives that are at cross-purposes with cycle time reduction. In the case of the FOG-M missile, for example, engineers in the US Army Missile Research, Development and Engineering Center had developed a prototype system, but Boeing did not make full use of the design and development work that had been completed, instead essentially reinventing FOG-M, because incentives were structured to maximize hours of design work (Sherman 2006a).
Another problematic dimension of incentives is in the setting of requirements. The intense competition to get programs approved and funded produces an unintended incentive to set requirements exceptionally high so that the system can compete effectively for resources. Similarly, there is an implicit incentive to attempt to achieve the most performance capability possible, given that it may be a long time before another weapon system in that domain is approved. If minimal capabilities are accepted for an initial version of the system, confidence may be low regarding future funding for more advanced versions. These are barriers to evolutionary incremental or spiral development that can only be addressed through effective management.
Individual managers also require proper incentives (and sanctions) to motivate behavior resulting in cycle time reduction. For commercial firms competing in markets characterized by high rates of technological change and market change, product development cycle time has increasingly been recognized as a source of competitive advantage (Brown and Eisenhardt 1995). The degree to which higher-level executives emphasize competing on the basis of speed represents one important antecedent to reduced cycle time. In the commercial setting, this is generally coupled with financial incentives and promotional decisions in which weight is assigned to managerial performance in meeting project schedule milestones (Tabrizi and Eisenhardt 1993). Too often, in the defense sector, schedule is given little weight as a performance factor in promotional or other personnel decisions. The area where the greatest potential for improvement exists is in the contract administration area, where processing and approvals are often delayed.
Cycle time reduction in defense acquisition continues to be a priority in the Department of Defense, as it must be in commercial contexts, as well. The wider relevance of these recommendations indicates how schedule performance can be improved not only in defense projects but in product development in general. Transfer of knowledge in the form of technology transfer occurs commonly between commercial industry and the defense sector. However, the potential for the transfer of management knowledge from one sector to another is often underestimated. The management of cycle time performance represents a potentially important area for the sharing of knowledge.
Best Practices in Systems Development
Reducing cycle time requires thorough implementation of the full set of best practices in new product development. General best practices that can help to reduce cycle time include:
* Integrated product teams. Integrated product teams should be created with representation from all involved organizations to facilitate systems development and facilitate rapid communication across organizational boundaries; these teams must be built and administered according to accepted management practices and should be focused around components or subsystems rather than particular functions (US GAO 2001b). Team members should have specific technical knowledge (Sherman 2003b) and the authority to move the process forward without lengthy consultations and approvals.
* Design for manufacturability. Design for manufacturability is a key component of reduced cycle time. This involves design decisions that incorporate optimization of manufacturing processes, resulting in simplified designs, standard assemblies, and components that are more cost effective to produce (Carmel 1995). To achieve this ideal, the prime contractor (and relevant subcontractor) manufacturing engineers must be included on the various IPTs from the early stages of system integration. This should result in a reduction in total manufacturing hours. Furthermore, the early inclusion of the manufacturing engineers on the IPTs should allow tooling to proceed as design decisions are finalized, further compressing the schedule (Clark and Fujimoto 1991; Deschamps and Nayak 1992: Wheelwright and Clark 1992).
* Design for maintainability. Design for maintainability is another consideration. Generally, the central focus in development is on achieving technical performance requirements, and maintenance considerations are given only limited attention (US GAO 2003). But key decisions on requirements and design early in the development process influence the cost of supporting and maintaining the system once it is deployed. Logistics maintenance experts should be included from the earliest stages of the process to provide input on design decisions that will facilitate maintenance, maximize the use of common parts to related systems, ensure that systems are available a high percentage of time, be more cost-effective to operate, and thereby reduce total deployment costs.
* Deep, continuous, system-specific expertise. An important factor in cycle time is the depth of system-specific technical expertise at the prime contractor and the degree to which continuity in the base of expertise is maintained over time. Cycle time performance should improve as the depth and continuity of system-specific or domain-specific technical expertise increases (Kessler and Chakrabari 1996; Smith and Reinertsen 1991). Furthermore, these should be enhanced to the degree to which the prime contractor is engaged in related development programs that create synergies between interrelated core technologies.
* Consistent leadership by a product champion. Finally, leadership by a product champion is critical not only to reducing cycle time, but to the very survival of the project. In his classic study of product champions, Schon (1963) cites numerous examples where the product champion encountered continuous organizational barriers, resistance from internal organizational rivals, and apathy from subordinates, not to mention relentless successions of technical challenges. Effective product champions typically have the organizational political skills to obtain timely cooperation from supporting organizations (Roberts and Fusfeld 1988).
Brown, S. L., and Eisenhardt, K. M. 1995. Product development: Past research, present findings, and future direction. Academy of Management Review 20(3): 343-378.
Carmel, E. 1995. Cycle time in packaged software firms. Journal of Product Innovation Management 12:110-123.
Clark, K., and Fujimoto, T. 1991. Product Development Performance. Boston: Harvard Business School Press.
Cooper, R., Edgett, S., and Kleinschmidt, E. 2004. Benchmarking best NPD practices. Research-Technology Management 47(1): 31-43.
Cooper, R., and Kleinschmidt, E. J. 2007. Winning businesses in product development: The critical success factors. ResearchTechnology Management 50(3): 52-66.
Defense Acquisition University. 2009. Interim Defense Acquisition Guidebook. Fort Belvoir, VA. https://acc.dau.mil/dag (accessed June 2, 2010).
Deschamps, J. P., and Nayak, P. R. 1992. Competing through products: Lessons from the winners. Columbia Journal of World Business 27(2): 38-54.
Ford, D. N., and Dillard, J. 2009. Modeling the performance and risks of evolutionary acquisition. Defense Acquisition Review Journal 16(2): 143-158.
Kessler, E. H., and Chakrabarti, A. K. 1996. Innovation speed: A conceptual model of context, antecedents, and outcomes. Academy of Management Review 21(4): 1143-1191.
McDonough, E. F., and Spital, F. C. 1984. Quick response new product development. Harvard Business Review 62(5): 52-57.
Meyer, C. 1993. Fast Cycle Time: How to Align Purpose, Strategy, and Structure for Speed. New York: Free Press.
Roberts, E. B., and Fusfield, A. R. 1988. Critical functions: Needed roles in the innovation process. In Managing Professionals in Innovative Organizations, ed. R. Katz, 101-120. New York: Harper Collins.
Rubenstein, A. H., Chakrabarti, A. K., O'Keefe, R. D., Souder, W. E., and Young, H. C. 1976. Factors influencing innovation success at the project level. Research Management 19(3): 15-20.
Schon, D. D. 1963. Champions for radical new innovations. Harvard Business Review 41:76-84.
Sherman, J. D. 2003a. Lessons learned from the early stages of development of the Guardrail common sensor for the radical reduction of cycle time. Acquisition Review Quarterly 10(3): 3003-14.
Sherman, J. D. 2003b. Patriot PAC-2 development and deployment in the Gulf War. Acquisition Review Quarterly 10(1): 28-45.
Sherman, J. D. 2006a. Lessons learned from the development of the Fiber Optic Guided Missile. Defense Acquisition Review Journal 12(4): 437-451.
Sherman, J. D. 2006b. Lessons learned from the development of the Joint Stand-Off Target Attack Radar System Common Ground Station. Defense Acquisition Review Journal 13(1): 81-94.
Smith, P. G., and Reinertsen, D. G. 1991. Developing Products in Half the Time. New York: Van Nostrand Reinhold.
Tabrizi, B., and Eisenhardt, K. M. 1993. Accelerating product development cycle time. Paper presented at the annual meeting of the Academy of Management, Atlanta, GA.
Thompson, J. D. 1967. Organizations in Action. New York: McGraw-Hill.
US Department of Defense (DoD). 2003. The Defense Acquisition System. Directive Number 5000.01. Washington, DC.
US Department of Defense (DoD). 2008. Instruction: Operation of the Defense Acquisition System. Directive Number 5000.02. Washington, DC.
US Government Accountability Office (US GAO). 2001a. Best Practices: Better Matching of Needs and Resources Will Lead to Better Weapon System Outcomes. GAO-01-288. Washington, DC.
US Government Accountability Office (US GAO). 200lb. Best Practices: DOD Teaming Practices Not Achieving Potential Results. GAO-01-510. Washington, DC.
US Government Accountability Office (US GAO). 2002. Best Practices: Capturing Design and Manufacturing Knowledge Early Improves Acquisition Outcomes. GAO-02-701. Washington, DC.
US Government Accountability Office (US GAO). 2003. Best Practices: Setting Requirements Differently could Reduce Weapon Systems' Total Ownership Costs. GAO-03-57. Washington, DC.
Wheelwright, S. C., and Clark, K. B. 1992. Revolutionizing Product Development. New York: Free Press.
J. Daniel Sherman, associate dean of the College of Business Administration at the University of Alabama in Huntsville, has been PI or co-PI on a number of contracts with the US Army. He is the author of over 50 research publications and his research has appeared in a number of leading journals including Academy Management Journal, Journal of Management, Psychological Bulletin, Personnel Psychology, IEEE Transactions on Engineering Management, Journal of Product Innovation Management, and Organization Science; in 2004, he received the 2004 IEEE-Engineering Management Society Publication Award. In 1989-90, he was a visiting scholar at the Stanford Center for Organization Research at Stanford University. In 2006, he received a division research award from the Academy of Management. He received a BS in sociology from the University of Iowa, an MA in sociology from Yale University, and a PhD in organizational theory/organizational behavior from the University of Alabama. email@example.com
Richard G. Rhoades is director of the Research Institute and professor of engineering management at the University of Alabama in Huntsville. He has ongoing research activities funded by a variety of organizations, including the Army Space and Missile Defense Command, the Army Aviation and Missile Command, the Army Aviation and Missile Research Development and Engineering Center, Aerojet General Corporation, Colsa Corporation, and Northrop-Grumman. His work focuses on weapon system technical risk assessment and avoidance, propulsion system design analysis, strategic planning, and organizational design. He serves on a number of weapon systems independent assessment ("Graybeard") panels and provides a continuing assessment of technical and programmatic risk, together with recommended mitigation approaches, to the directors of these programs. Prior to joining UA Huntsville, Rhoades held numerous positions in the Missile Research, Development and Engineering Center at Redstone Arsenal, including three senior executive service positions--Director for Propulsion, Associate Director for Technology, and the Associate Director for Systems. He received BChE and PhD degrees ,from Rensselaer Polytechnic Institute and an MS (Management) from MIT. firstname.lastname@example.org
|Printer friendly Cite/link Email Feedback|
|Comment:||Cycle time reduction in defense acquisition: the department of defense must be able to evaluate, acquire, and deploy new technology rapidly in order to accomplish its mission. a more flexible approach can bring dOd development processes more in line with commercial practices and substantially reduce cycle time.|
|Author:||Sherman, J. Daniel; Rhoades, Richard G.|
|Date:||Sep 1, 2010|
|Previous Article:||Good practices in open innovation: to access all of the promise of open innovation, organizations need tools and processes that allow them to fully...|
|Next Article:||Industry-defined fundamental research: creating an agenda for basic research: IRI's industry-defined fundamental research program is designed to give...|