On Monday, a friend asked me to recommend a project management methodology for IT. I wasn't trying to be awkward, but my answer was "that depends".
Let me explain.
Any activity that a business performs (whether it's a process, or part of a process, or related to the result of a process such as a product or service) is transient. In other words an activity's characteristics change over time.
For example, the use of CRM (customer relationship management) systems was a new activity in the mid 80s however today it has become widespread. CRM has transformed from something novel, with little or no literature and a relatively undefined problem space to something which is common, backed up by a wealth of literature and a well defined problem space. I've marked this transition on figure 1 which shows a graph of ubiquity (from new to common) against certainty (from an undefined problem that few have solved to a well defined and specified problem that has been solved many times before).
If you take an snapshot of a company at any time, you will find that it consists of a mass of different activities. At one end, you have those activities that are truly novel within the industry and because of their novelty they are relatively undefined. Such activities are the innovations, the differentiators and the potential sources of competitive advantage. On the other extreme you have those activities that are common or ubiquitous within the industry and hence because of this, they are well defined (to the point of best practice solutions and step by step how to guides). They are the commodity like activities and a likely cost of doing business. I've shown this on figure 2.
Now this is only a snapshot in time. Any activity (as per CRM) is on a path from innovation to commodity and hence its position on this graph will change over time. As an activity moves down this path, it changes from a highly variable dynamic class of problem to a more fixed static class of problem. Its characteristics change and hence the method by which it is best managed. I've tried to show this in figures 3-4.
Figure 4 - Effective methods for dealing with an activity at different stages of its lifecycle
In order to know how to manage something, you need to know where it is on this curve. Hence my original answer. The project methodology depends upon what you are doing and most importantly when you are intending on doing it.
The methodology I would use to manage a CRM project has changed drastically, but that is only because CRM is no longer an innovation - it has become more of a commodity.
This is also why there are no single, magic bullet solutions to project management. When dealing with a commodity, your focus is to eliminate variation. No business wants variability in its power supply or telephone or internet connection. Innovation, however, requires deviation from the accepted norms of today - it's something new. So on one extreme you need methods to eliminate variation whilst on the other you needs methods to encourage and cope with variation.
In my opinion, the simple solution is just to use different methods and to learn when to use them.
