Strategy Ain t Methodology

Strategy Ain't Methodology

Project development strategy is about the overall game plan of how you plan to undertake the project. For example, you may be planning to develop the whole product in one hit or alternatively, break up the product into subproducts and develop the subproducts as independently as possible.

The most common misunderstanding about project development strategy is that strategy is often confused with methodology or task lists. As we discuss in Chapter 12, "Analyze Risk," projects move through a number of development phases, steps, or tasks (often called methodology ). In a software development project, we may commence with a phase involving analyzing requirements (a similar phase would be found in developing a new insurance policy, e.g.). The analyzing requirements phase may involve lower level tasks such as interviewing clients and so on.

The project development strategy is independent of the particular methodology being used for your project. For example, as we discuss later in this chapter, if you are using a sequential release strategy in your project, you'll undertake the analyzing requirements phase (and its related subtasks ) for as many releases as you are developing.

The first mention of project development strategies that we are aware of was in the famous NATO Software Engineering Conferences in 1968 and 1969. During a chaired discussion in 1968 on large projects and lessons learned from them, John David from Bell Labs indicated that it was Bell Labs' experience "that any software system that cannot be completed by some four or five people within a year can never be completed." ^[2] Fred Brooks (1975) also indirectly discussed project development strategies in his classic book The Mythical Man Month , discussing lessons learned from IBM's OS/360 project development. However, in 1976, Paul Melichar from the IBM Systems Science Institute wrote a great paper, "Management Strategies for High-Risk Projects." ^[3] In this landmark paper, Melichar clearly identified three project development strategies and provided some excellent guidelines on what type of project would be ideal for each of the strategies.

^[2] Of course, it is amazing to us (though it shouldn't be) that in 1995, some 27 years after Bell's comments, the concept of 6 x 6 and 3 x 3 projects became very popular with some new-breed IT gurus ( NATO Software Engineering , Naur & Randell, 1968, p. 84).

^[3] This paper was an internal IBM document and, to our knowledge, was never published.

Since that paper, our group has further developed and refined Melichar's original model. As we discuss in this chapter, strategy is critical to planning your project and in managing changes in scope, objectives, quality, and risk during your project.