Seven Fallacies That Delay Project Management Maturity

All too often, companies embark upon a journey to implement project management only to discover that the path they thought was clear and straightforward is actually filled with obstacles and fallacies. Without sufficient understanding of the looming roadblocks and how to overcome them, an organization may never reach a high level of project management maturity. Their competitors, on the other hand, may require only a few years to implement an organization-wide strategy that predictably and consistently delivers successful projects. One key obstacle to project management maturity is that implementation activities are often spearheaded by people in positions of authority within an organization. These people often have a poor understanding of project management, yet are unwilling to attend training programs, even short ones, to capture a basic understanding of what is required to successfully bring project management implementation to maturity. A second key obstacle is that these same people often make implementation decisions based upon personal interests or hidden agendas. Both obstacles cause project management implementation to suffer.

The fallacies affecting the maturity of a project management implementation do not necessarily prevent project management from occurring. Instead, these mistaken beliefs elongate the implementation time frame and create significant frustration in the project management ranks. The seven most common fallacies are explained below.

Fallacy 1: Our ultimate goal is to implement project management.

Wrong goal! The ultimate goal must be the development of project management systems and processes that consistently and predictably result in a continuous stream of successful projects. A successful implementation occurs in the shortest amount of time and causes no disruption to the existing work flow. Anyone can purchase a software package and implement project management piecemeal. But effective project management systems and processes do not necessarily result. And successfully completing one or two projects does not mean that only successfully managed projects will follow.
Additionally, purchasing the greatest project management software in the world cannot and will not replace the necessity of people having to work together in a project management environment. Project management software is not:

  • A panacea or quick fix for project management issues.
  • An alternative for the human side of project management.
  • A replacement for the knowledge, skills, and experiences needed to manage projects.
  • A substitute for human decision-making.
  • A replacement for management attention when needed.

The right goal is essential to achieving project management maturity in the shortest time possible.

Fallacy 2: We need to establish a mandatory number of forms, templates, guidelines, and checklists by a certain point in time.

Wrong criteria! Project management maturity can be evaluated only by establishing time-based levels of maturity and by using assessment instruments for measurement. While it is true that forms, guidelines, templates, and checklists are necessities, maximizing their number or putting them in place does not equal project management maturity. Many project management practitioners – me included – believe that project management maturity can be accelerated if the focus is on the development of an organization-wide project management methodology that everyone buys into and supports.

Methodologies should be designed to streamline the way the organization handles projects. For example, when a project is completed, the team should be debriefed to capture lessons learned and best practices. The debriefing session often uncovers ways to minimize or combine processes and improve efficiency and effectiveness without increasing costs.

Fallacy 3: We need to purchase project management software to accelerate the maturity process.

Wrong approach! Purchasing software just for the sake of having project management software is a bad idea. Too often, decision-makers purchase project management software based upon the bells and whistles that are packaged with it, believing that a large project management software package can accelerate maturity. Perhaps a $200,000 software package is beneficial for a company building nuclear power plants, but what percentage of projects require elaborate features? Project managers in my seminars readily admit that they use less than 20 percent of the capability of their project management software. They seem to view the software as a scheduling tool rather than as a tool to proactively manage projects.

Consider the following example that might represent an average year in a mid-size organization:

  • Number of meetings per project: 60
  • Number of people attending each meeting: 10
  • Duration of each meeting: 1.5 hours
  • Cost of one fully-loaded man-hour: $125
  • Number of projects per year: 20

Using this information, we can calculate that the organization spends an average of $2.25 million (US) for people to attend team meetings in one year! Now, what if we could purchase a software package that helped us reduce the number of project meetings by 10 percent? We could save the organization $225,000 each year!

The goal of project management software selection must be the benefits that the software provides to the project and the organization, such as cost reductions through efficiency, effectiveness, standardization, and consistency. A $500 software package can, more often than not, reduce project costs just as effectively as a $200,000 package. Project management maturity can be supported by purchasing software only if the people who select the software focus on how much money using the software will save rather than on its packaged features.

Fallacy 4: We need to implement project management in small steps with a small breakthrough project that everyone can track.

Wrong method! This works if time is not a constraint. The best bet is to use a large project as the breakthrough project. A successfully managed large project implies that the same processes will work on small projects, whereas the reverse is not necessarily true.

On small breakthrough projects, some people will always argue against the implementation of project management and find numerous examples why it will not work. Using a large project generally comes with less resistance, especially if project execution proceeds smoothly.

Fallacy 5: We need to track and broadcast the results of the breakthrough project.

Wrong course of action! Expounding a project’s successful results benefits only that project. Illuminating how project management caused a project to succeed benefits the entire organization. People then understand that project management can be used successfully on a multitude of projects.

Fallacy 6: We need executive support.

Almost true! We need visible executive support. People can easily differentiate between genuine support and lip service. Executives must walk the talk. They must hold meetings to demonstrate their support of project management and attend various project team meetings. They must maintain an open-door policy for problems that occur during project management implementation.

Fallacy 7: We need a project management course so our workers can become Project Management Professionals (PMPs).

Once again, almost true! What we really need is lifelong education in project management. Becoming a PMP is just the starting point. There is life beyond the PMBOK® Guide. Continuous organization-wide project management education is the fastest way to accelerate maturity in project management.

Needless to say, significantly more fallacies than discussed in this paper are out there, waiting to block your project management implementation and delay its maturity. What is critical is that your organization implements project management through a well thought-out plan that receives organization-wide buy-in and support. Fallacies create unnecessary delays. Identifying and overcoming faulty thinking can help fast-track your organization’s project management maturity.

© 2010  This post was originally written on March 05, 2009.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s