This paper was first published by ICFAI PRESS, Hyderabad in Projects & Profits Special Issue, March 2003, p18.

Published here May, 2003.

PART 1 | Introduction | Rapid Prototyping | Reasons Why Linearity Doesn't Work
People Problems | So What is the Answer? | Conclusions


From the forgoing examination, we conclude that software development projects, in the environment we described, really are different from "traditional" project management, i.e. projects involving well-established technology. So, if you are an IS software development project manager and your first need is to identify the best methodology for your project, here are some suggested questions for determining the best selection.

  • Who is the sponsoring organization, how much documentation do they usually expect and are they willing to support it? This will establish the degree of rigor to be applied to the whole process and the extent of data management required.
  • How big is the project, specifically is it "complex", i.e. how many elements are there in the system and/or how many stakeholders are there that need to be satisfied, and in what way? This will determine the number of interfaces and communication channels to be coordinated and hence the level of project management required.
  • What is the risk "profile" of the project, that is, how "risky" are the various elements of the project's scope, or how risky are any of the proposed technologies that will be involved? That is to say, does the customer really understand what they want, or only have a general objective? This will determine the priorities for tackling the system elements to mitigate the risks as early as possible. It will also indicate the level of risk management and contingency allowances required.
  • Which of the four project management constraints of scope, quality, time or cost predominates? That is, which of them has real priority for the top position and which, in the last analysis, can give ground? For example, is there a "time window" such as meeting a market opportunity? This will determine the pace at which the project must be conducted and consequential constraint on the extent and number of iterations permissible.
  • Another way of asking the last question is: What are the measurable key success indicators (KSIs) by which the product will ultimately be judged and against which decisions can be taken during the project? And, what is the order of priority amongst the KSIs? This will establish the basis for effective project management and necessary executive control.

Given the answers to these questions, a suitable methodology may suggest itself. In any case, your solution to the selection dilemma should include some judicious compromise between prototyping or iteration, and serialization. If you can surmount that hurdle then it only remains to apply standard project management techniques. That is, adopt a suitable organization, leadership style and communication, and apply the right competent skill sets to the selected methodology. You will then be well on our way to a successful project.

Meantime, instead of lauding one software development methodology over another, perhaps we should be examining each of them in the context of the variables identified, to establish the best approach to methodology selection. That is, how to select a software development methodology for a given project environment that leads to the highest probability of a successful outcome. On a large project that could well include several of the methodologies described above, but applied separately to different elements and/or to progressive phases of the project.

So What is the Answer?  So What is the Answer?

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page