an implementation plan that defines the order in which the product?s functional components will be developed and integrated. Using automated source code control. According to the view expressed by Figure 1, adding processes like these, as is shown in Figure 2, is pure overhead and simply takes time away from productive work. Figure 2. This point of view has intuitive appeal. At the beginning of a project (shown by the darker shaded areas), a focus on process certainly does take time away from productive work. If that trend were to continue throughout a project (shown by the lighter shaded areas), it wouldn?t make sense to spend much time on process. Experienced View of Process Based on software industry experience, however, for medium and large projects the trend shown in Figure 2 does not continue throughout the project. Projects that don?t pay attention to establishing effective processes early are forced to slap them together late, when slapping them together takes more time and does less good. Here are some examples: In the middle of the project, team members agree informally to implement a wide variety of changes that are proposed to them directly by their manager or customer. They don?t begin controlling changes systematically until late in the project. By that time, the scope of the product has expanded by 25 to 50 percent or more, and the budget and schedule have expanded accordingly. Projects that don?t set up processes to eliminate defects in early stages fall into seemingly interminable test-debug-reimplement-retest