Published here April, 2003.

Introduction | The PMI's Guide to the PMBoK | The "Waterfall" Process
The Systems Engineering Approach | The Spiral Model Approach | PART 2

Introduction

The focus of this paper is on software development that flows from the corporate requirements of information system (IS) departments working in the public and private sectors. IS departments are typically 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 IS departments 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, the 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" as Professor Rodney Turner[1] is fond of saying. 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. So, let's examine some of the better-known methodologies in the context of software development-type project management.

However, before doing so, we must first 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. [D02129]".[2] To this, 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, trade-offs 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 examine some of the more popular project management methodologies.

 

1. Rodney Turner, author and editor of The International Journal of Project Management, and Professor of Project Management at Erasmus University, Rotterdam
2. Project Management Guidelines (Private BC Corporation), 1995, Wideman Comparative Glossary of Project Management Terms v3.1, 2002
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page