Implications of Pressure for Shortening the Time to Market (TTM) in Defense Projects

Introduction

In recent years, government and prime contractors have been expressing a growing demand, requesting that their defense R&D contractors shorten the Time To Market (TTM). This paper presents a study aimed at investigating the implications of shortening TTM in defence projects. In the context of defense projects aimed at developing tailored systems, TTM is the length of the development time, i.e., the time from signing the contract until the first prototypes are validated and accepted by the customer.

Speed has its price, which might take the form of greater development expenses, reduced product performance, higher risk, and staff burnout (Smith, 2004). Frequently, TTM is shortened by skipping steps in the development process, thus compromising quality. The problem is that skipping a step might not only undercut quality, but can also lengthen development time if the skipped steps must be completed or repeated later. Furthermore, a primary means of reducing TTM is to allocate more engineers and programmers to the project team; therefore, a faster project may also be more expensive.

The most common strategies for shortening TTM are: Giving the project high priority; speeding up all processes; recognizing that not all steps need to be completed for every project and skipping the unnecessary steps; applying tools and techniques that enable the shortening of certain steps or stages and automating activities; involving the customer/user; simplifying organizational structure; reducing parts and components; training and rewarding of employees; stimulating interfunctional cooperation; minimizing resources; cutting decision-making time; making the change process more flexible; overlapping stages (applying concurrent engineering methods), and applying systems engineering and project management processes such as risk management, project planning, resource management and more (Millson, Raj & Wilemon, 1992; Smith & Reinertsen, 1998, Calantone & Di Benedett, 2000; Langerak & Hultink, 2005; Swink, Talluri & Pandejpong, 2006). Zirger and Hartley (1996) found that fast developers had teams that were cross functional, dedicated, included fast time to market as a development goal, and overlapped development activities more than slow developers.

Systems engineering offers fast, as well as, traditional (step-by-step) development approaches. In software engineering, the fast approaches are often called “agile” (i.e. Cockburn, 2001; Larman & Basili, 2003; Abrahamsson et al., 2003; Boehm & Turner, 2004); however, in recent years this term has been used to label hardware-software embedded projects in which a fast development approach is taken (i.e. Hallberg, Andorsson & Olvander, 2010). The most common traditional, step-by-step, development strategies are the waterfall model (i.e. Royce, 1970; NASA, 2004, Eisner, 2008) and vee-model (i.e. Forsberg & Mooz, 1991; Defense Acquisition University, 2001) approaches, while the most common agile strategies are the spiral model (Boehm, 1986; Nelson et al., 1996), prototype model (i.e. Alavi, 1984, Davis et al., 1986; Tripp & Bichelmeyer, 1990; Gull et al., 2009) and sawtooth model (Sherrell & Chen, 2001). The leading principle as regards the former strategies is that before moving on to the next stage, all development activities in the previous stage must first be completed, verified and validated. On the other hand, using the latter strategies, the development progress is achieved through repeated cycles (iterations) and in smaller portions at a time (incremental); sometimes moving on to the next stage, even if all of the data is still not available, and not all the activities of the previous stage have been completed. This is a sort of trial-and-error process, involving the use of numerous models, simulations, mockups and preliminary prototypes.