In this post, I am borrowing a section from an internal document. This document addresses our views on the leading projects performance inhibitors. In other words, the root causes of why organizations do not do as well as they could in managing their organizational projects and products delivery. What is missing in their project management current state of practice?
The Four Leading Projects Performance Inhibitors
First, we must stress that we are not talking about causes for a given project to fail. This is not about a single project, it is about the organization’s projects performance. In other words, as an organization what are the factors that limit their abilities to have a better performance? This could be for an organization that wants to go from good to great or failure to fair, as a first stem.
As a result, there are numerous factors and inhibitors. However, we will only list the most significant factors; four significant inhibitors that affect projects performance.
No 1: Project Management as a formal function
What we believe to be the leading projects performance inhibitor is that organizations and their executive teams have not yet recognized the value of project management.
Executives in most non-industrial organizations have not reached the mindset that accepts project management as an independent domain. A domain that should not be left to accidental project managers. These executives have not recognized project management as an organizational function. A formal function, equal to marketing, human resource, information technology, finance, and other functions. This is one of the reasons we do not see project management departments or divisions in companies and government organizations.
Instead, what we see is a diluted version called PMO, Agile PMO, Next Generation PMO, and so many other names of “offices” that may exist for 2 to 3 years. Consequently, organizations fail to achieve optimal projects performance.
No 2: Organizational Divide
The recent trends and hype about Agile[i] and business analysis are indicators of the divide that exist in organizations between the “business” and “IT” or product development. When we hear about Agile Project Management and IT Projects, these are clear examples of organizations not able to see projects as business initiatives. Rather they see them as pieces. Each piece is led by another party over the fence or behind a virtual wall. What these organizations fail to see is the need to view these “projects” as business projects. Projects that must be managed end-to-end, across a full project life cycle.
Consequently, when we hear Agile Transformation, we expect to hear the future scream that like generic certifications, “Agile Project Management” did not deliver the value promised; because there is no “Agile Project Management.” Hence the focus of our last book titled, Project Management beyond Waterfall and Agile. Therefore, we need to recognize that it is not about certification or Agile, it is about viewing and leading projects concept to success!
No 3: Absence of Organizational Project Management
The third projects performance inhibitor is the lack of organizational systems to support building the project management function and lack of methodological approaches to take projects concept to success. The organizational project management system is about the proper governance, policies, processes, and overall framework for managing the portfolio of the organization, inclusive of projects and programs.
Along with this system, or its absence, there is a lack of organizational knowledge, history, and lessons learned, which end up causing the organization to be in the business of reinventing the wheel, almost with every project; not learning the lessons.
No 4: No Methodology-Driven Enablers
This fourth projects performance inhibitor might seem to be focused on software but it is a broader issue.
There are hundreds of software products mislabeled as “project management software”. Most of what exists are for timesheet, some team collaborations, task management, cost or schedule development, etc. These are tools that would be available for a project manager, assuming the project manager is experienced and know how to use them. We have seen projects personnel use MS Project as a to-do list because they do not know how to schedule.
On the other side, major organizations could invest millions to custom-build a project management product (software). However, many do not, and a large percent of small to medium, even large organizations do not have any proper project management system. Further, even if they do, it could be quite basic and not highly effective.
To our knowledge, there are no methodology-driven software products in the market that guide a project manager or an organization to lead projects concept to success. Therefore, this is lead to situations where there are nothing and the business of recreating the wheel; or spending millions to build the same thing that some others have built.
Projects Performance and the Project Management Current State of Practice
In summary, what we see is:
- Organizations should transform their culture and mindset and move toward building their project management functions; inclusive of the proper organizational structure and recognition.
- The need to go beyond the hype and what is popular. Therefore, they need to address what is needed and essential for success. What is essential is managing projects end to end, concept to closure by breaking the organizational barriers and silos.
- The absence of well-defined, proper, and sustainable organizational project management systems with the right processes and knowledge base.
- The absence of accessible and comprehensive methodology-centric online software solutions.
What are the solutions?
In conclusion, there are many possible solutions that could be used for the diversity of types of projects. Further, there are various types of organizations. In another post, we will address what we in SUKAD Corp are doing about it. Our attempt to positively affect the project management state of practice.
Stay tuned
[i] When we use the term Agile with a capital A, the reference is to the Manifesto of Agile Software Development.