How you do things is the core element of project management, which is why there are numerous project management methodologies in practice. The popularity of these rational and systematic approaches to work is one of the sources of increased productivity. At the same time, there is growing consensus in the project management profession on standards, the PMBOK™ being a prime example, which is aligning the profession. Yet, despite the abundance of approaches and the wider acceptance of standards, many Project Managers that are in the trenches often find their methodology of choice lacking in some fundamental way. It is usually because the methodology is no longer appropriate for the organization. The following factors are for Project Managers to consider when selecting a methodology or reviewing one that is in use, to assure it is a good fit for your organization.
Does the methodology make a clear distinction between product management (what is being produced) and project management (how the product is produced)? The two are interrelated but are not the same. The product represents the initial need and final result. The project is the sum of the activities and, most importantly, the constraints that impact the development of the product. Many methodologies contain elements product and project management but without a clear distinction, it is easy for a Project Manager to believe that by managing the details of the product they are actually managing the project. An argument can be made that a Project Manager does not need much knowledge about the product at all, since project management activities like cost and time management are relatively constant regardless of the product. Some methodologies focus on either product or project management, resulting in a cursory treatment of the other. If your organization has a solid core of product experts, then you need a methodology that focuses on project management. Your organization may have excellent project management expertise but a wide variety of products and will require a stronger focus on product management. Some organizations need a methodology that covers both equally. Whatever is selected, the methodology should be clear on which activities are related to the project management and which are focused on developing the product to minimize any confusion.
Are your projects wide in variety (scope, cost, time, type of product and type of industry) or relatively similar?
By design, the adoption of a methodology excludes using others, but one methodology is often not appropriate for
all types of projects. If your organization conducts a wide variety of projects then the methodology should be
flexible. Otherwise, the alternative is trying to apply an inappropriate methodology to a project or having multiple
methodologies in use. If your organization's projects are relatively similar then flexibility is not a concern.
A related consideration is how many other organizations are involved with your projects. Many of us have seen situations
where different methodologies do not mesh well amongst different organizations. If most of your projects are conducted
with partners then your methodology should be the same as theirs or at the very least compatible.
Most methodologies claim to be flexible. However, if no guidelines are provided for tailoring the methodology odds
are it is not. If there are guidelines then a judgment must be made on how effective the tailoring activities appear
to be. If the tailoring guidelines are almost the same size as the original methodology, consider it a bad sign.
How comprehensive a methodology do you need? It may seem counter-intuitive, but the more comprehensive a methodology
is, the less useful it may be for your business. It depends on the stability of your organization. If your organization
is constantly changing then the methodology should provide you with the minimum baseline to manage a project and
some guidance or building blocks for more comprehensive elements that can be added and removed as things change.
A relatively stable organization can make better use of a comprehensive methodology since it has the depth and
time to absorb it.
Many methodologies are quite sophisticated and cover many aspects of project management. A way to judge them is
to compare their weight rather than content. It costs money to develop a methodology and to recoup the investment
the methodologies must be sold. The target market for methodologies are usually large organizations, therefore,
the methodological tomes are geared to their needs. To also make it more marketable, the methodology must cover
as many project concerns as possible which adds more girth to the documents. As a result, many methodologies are
simply too much for small and medium businesses. Even for large organizations, not all that is in a methodology
is needed and tailoring becomes an exercise in cutting bits out rather than adding portions to a stable baseline.
It is not unusual for a vendor to intertwine their methodology with their proposed solution or product. The areas
of coverage in a methodology reveal a lot about the organization that developed it. For example, what would extensive
coverage on risk management but only a few pages on communication say to you about their experience and approach
to projects?
Many methodologies and the PMBOK™ itself have an underlying assumption that a single Project Manager will have sufficient authority to manage a project. In reality, this is often not true and responsibilities must be shared within an organization. Governance issues often arise in projects because of the complex interrelationships between the groups involved. For example, quality is an essential element of project management. Many organizations also have quality departments who look after quality concerns. The Project Manager usually does not have direct authority over the quality department. Therefore, a governance arrangement must be made to share responsibility for quality on the project. Another example comes from the common arrangement to have one department as the client of a project and another as the product or solution provider. Is Risk Management a joint activity, done separately or some combination of the two? The methodology that is chosen should reflect the realities of your organization's project governance, or be flexible enough to adapt to it.
The dawn of the web era and the 90-day software development project is just the beginning. For all industries,
technology, globalization and volatile markets are shortening the time to complete projects. The methodology you
choose has to be appropriate for the speed at which you must produce. If you must produce products quickly then
the methodology must be lighter on process and push decision making down to the front lines. The methodology must
also consider the industry or types of products you will produce. If your product impacts people's safety, then
the methodology needs to have more safeguards and checks put in place.
Your organization may have other factors to consider before selecting a methodology (such as the obvious like cost).
The important thing is to select what is appropriate for your organization. These five factors represent a good
starting point for assessing any candidate methodology. One final warning - a methodology is just a tool. Like
all tools, you should be able to replace them as needed. However, because methodologies directly influence how
you do your work, it is a short journey for a methodology to evolve into policy and eventually your corporate culture.
If your organization is engaged in dogmatic struggles over the 'true' meaning of a methodology rather than applying
common sense then it is time for a new methodology. The business you conduct should influence the tools you choose,
not the other way around.