Over the years I have seen many methodologies for managing projects. Virtually all of them are effective - for a unique set of business and project conditions. Difficulties arise when a methodology that is not appropriate for the current set of business and project conditions is imposed upon an organization or project. When this happens I typically see one of three destructive organizational responses.
One typical response is that those involved with project management, either at the project or the portfolio level, quickly realize that the methodology does not fit the business and project conditions and choose to ignore the methodology. Unfortunately, even the project teams managing projects for which the methodology is a fit begin to ignore the methodology - since everyone else is - and no benefit from the methodology is realized. When this response occurs, the organization usually maintains the status quo on project performance, despite the improvement efforts associated with implementing the new methodology. Everyone continues to interact with projects in the way they have in the past, and the business's ability to improve its strategy implementation remains unchanged. This often leads to a very cynical view of project management systems and methodology in general, with many individuals in the organization thinking they don't work or at least they don't work "here."
A second response occurs when the methodology is imposed on the organization and compliance is required. This leads to a mixed response within the organization. For those projects and business conditions where the methodology does fit there is typically an improvement in several measures of project performance. In those cases, the project teams often become strong advocates of the use of the methodology. For those projects and business conditions where the methodology does not fit, major problems in project planning and execution are often created. Sometimes the methodology creates massive amounts of useless work addressing issues that do not apply on the project. Sometimes particular tools are required that do not help the project team deal with the unique project risk, but rather mask the risk creating larger problems once the risk finally comes to the forefront. Sometimes the methodology requires unnecessary reviews and meetings where there is no change in status to report and no decisions to be made. Other times the methodology does not ensure timely reviews or that timely decision making occurs. For those projects where the methodology does not "fit," it is resented by the project team. The overall result for the business often leads to loss of morale, dysfunctional behavior and inconsistent performance.
The third category of response we have seen is when an organization embraces the new methodology and uses it to both manage and screen projects. In this case, projects that don't fit the inherent business and project conditions assumed by the methodology are never started. This leads to several organizational responses. The responses include 1) a curtailment in what strategic options are considered, 2) a major effort to outsource the incompatible projects, or 3) the development of a "shadow" project management approach where the projects that don't fit the methodology are done behind the scenes until the project conditions can fit the methodology when they are then brought forward.
As an example, one company we have worked with implemented a new product development methodology that has led to this third category. Their methodology requires complete, clear, and fully supported product, market, and business specifications before any new product project can be initiated. This methodology is suitable when the new product is a derivative of existing products within existing markets. However, for next generation products and emerging markets the project specifications can not be completed because there is no data with which to define the detailed product or market requirements. To work around this problem, individuals in the business have numerous "shadow projects" underway to create enough data to write specifications that are required to introduce the project into the new product development project management methodology. These "shadow projects" are lengthy, under-resourced, and haphazard in focus. There is no direct management oversight of "shadow projects." Therefore there is limited coordination and prioritization between functions. For those products with next generation technology or emerging markets, much of the project activity is accomplished before a "real project" is approved. When that happens, the "real project" becomes a paperwork exercise. The project team uses the project management methodology to document all of the work that was conducted in the "shadow" mode. The result is that valuable resources and effort are expended on "shadow projects" that should be directed towards those that are approved and support strategy. And the effort conducted on approved projects is perceived as bureaucratic and redundant.
The solution to the problem of the wrong project management methodology is not to avoid having a project management methodology. That approach leads to poor project risk management and communication, and ultimately to failed projects and failed business strategy. The solution is to devise a methodology, or family of methodologies, that are appropriate for the "real world" of your business and projects. In a future article I will explore several of the frameworks for analyzing the business and project context that allow you to define a methodology. Each of these frameworks provides valuable insight into determining the characteristics of the project management tools, techniques, and processes that are well suited to a unique set of business and project conditions.
