An Editorial Observation
Software development flows from the corporate requirements of information system (IS) departments working in the public and private sectors. These departments are created to serve organizations that range in size from medium to large. Unlike other areas of software development, such as "shrink-wrap" or "commercial-off-the-shelf" software development, the needs of the IS department are to maintain, enhance or upgrade existing software systems, or respond with entirely new software to satisfy new corporate business initiatives. 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.
However, software development programming itself is not necessarily done "in-house". Instead, these services may be acquired from outside suppliers under contract. This makes it even worse 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 not yet entirely known. Thus, responding software developers face even bigger hurdles.
Understandably, these service-provider developers cry: "Software development projects are different! Software development just doesn’t work the same way as "regular" projects!" Well are they? After all, for all projects time is linear and there is no "time undo" button to undo anything not to your liking. The best you can do is go back and fix it. And projects are essentially linear, too. That is, they have a start and a finish "and a bit in the middle". So, what's the problem? The problem is that in spite of the best efforts using some of the best methodologies, project software development results are still disappointing in terms of cost and schedule.
We must be clear on what constitutes a project result that is "not disappointing". For this we turn to the definition of "A well-managed project". "A well-managed project is one that is optimized for effectiveness in its planning phases but emphasizes efficiency in its implementation phases, that include commissioning, startup and close out. ".
In the case of software, we should add something like "And, in the eyes of the customer, is perceived as satisfactory in use." This definition has important implications for software project management. It is about planning and control. That is, in a project life span that has four major "generic" phases, in the first phase of "Conception" you establish the "vision" for the product.
You also justify the project in a "Business Case" document that requires executive or upper management approval before proceeding further.
In the second phase of "Definition" you determine content based on requirements, and develop a plan for execution that you describe in a "Project Charter", project brief or similar document. This, too requires executive approval, especially since this approval will set aside major funding for the work of the project.
In the third phase of "Execution", that is the actual software program development, you create the product, and test and verified it for "customer satisfaction".
In the final phase, you transfer the product to the users, complete with documentation and any training needed, and you formally close the project, following acceptance and approval by the executive. We call this aspect of project management "Executive Control".
Along the way, you will inevitably encounter the need for decisions, compromises, tradeoffs and changes. To support sensible decisions, you should know the order of priority of the four core project management variables of scope-quality-time-cost and the level of risk associated with each. For example, in an air traffic control system, quality would obviously have the highest priority at the expense of time and cost. On the other hand, software designed to facilitate some public exhibition must meet the opening date so time would obviously be at the top of the list.
An accounting or tracking system project, whose scope includes a number of features of varying degrees of desirability, could be scaled back if limiting cost against budget is the major concern, and so on.
In selecting a software development project management methodology, there is also the issue of complexity. By complexity we mean the number of separate stakeholders you need to satisfy and/or the number of system elements that you have to integrate.
It is against this background that we must hold up to critical scrutiny the more popular project management methodologies.