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
|
