Introduction to Part 2
In Part 1 of this paper we described the operating environment of information system (IS) departments working in the public and private sectors. In particular, their need to maintain, enhance or upgrade existing software systems, or respond with entirely new software to satisfy new corporate business initiatives. We suggested that their operating environment generally includes a variety of stakeholders with differing goals, a lack of stable requirements, and is often subject to ponderous management direction.
Further, their software development programming itself is not necessarily done "in-house", but rather, these services may be acquired from outside suppliers under contract. This adds difficulty because the corporate acquisition process may well be that of traditional capital project acquisition based on a fixed price quotation for a total product, even though the details of that product are often highly fluid.
In spite of the cry that "Software development projects are different!" we questioned that assumption. In our view, the real issue is not that software projects are really different but that the nature of the product requires an appropriate project management methodology. The crux of the matter is the project's life span, which we described for reference purposes, and how the work should be properly advanced and controlled. In this light, we examined a number of methodologies such as the Project Management Institutes so called "PMBoK", the "waterfall", the systems engineering approach, and the "spiral" model, and listed the strengths and weaknesses of each.
In this Part 2, we will also examine "Rapid Prototyping" and then move on to suggest reasons why "linearity" really doesn't work for IS department software development. We will also look at some of the "people" problems associated with software development and try to suggest some answers considering that the answers have probably been around for a long time, if only we would look at them.
So, what is the best approach, or methodology? Well, it all depends see our conclusions!
|