Project management methodologies: a definition
by Harold Kerzner / 2/6/2018 10:23:06 AM
Achieving project management excellence, or maturity, is more likely with a repetitive process that can be used on each and every project. This repetitive process is referred to as the project management methodology.
If possible, companies should maintain and support a single methodology for project management. Good methodologies integrate other processes into the project management methodology, as shown in Figure 1. Companies have all five of these processes integrated into their project management methodology.
In the coming years, companies can be expected to integrate more of their business processes in the project management methodology. This is shown in Figure 2. Managing off of a single methodology lowers cost, reduces resource requirements for support, minimizes paperwork, and eliminates duplicated efforts.
Fig 1: Integrated processes for the twenty-first century.
Fig 2: Integrated processes (past, present and future)
The characteristics of a good methodology based upon integrated processes include:
- A recommended level of detail
- Use of templates
- Standardized planning, scheduling, and cost control techniques
- Standardized reporting format for both in-house and customer use
- Flexibility for application to all projects
- Flexibility for rapid improvements
- Easy for the customer to understand and follow
- Readily accepted and used throughout the entire company
- Use of standardized life-cycle phases (which can overlap) and end of phase reviews
- Based upon guidelines rather than policies and procedures
- Based upon a good work ethic
Methodologies do not manage projects; people do. It is the corporate culture that executes the methodology. Senior management must create a corporate culture that supports project management and demonstrates faith in the methodology. If this is done successfully, then the following benefits can be expected:
- Faster “time to market” through better control of the project’s scope
- Lower overall project risk
- Better decision-making process
- Greater customer satisfaction, which leads to increased business
- More time available for value-added efforts, rather than internal politics and internal competition
FROM ENTERPRISE PROJECT MANAGEMENT METHODOLOGIES TO FRAMEWORKS
When the products, services, or customers have similar requirements that are reasonably well defined and do not require significant customization or numerous scope changes, companies develop often inflexible methodologies to provide some degree of consistency in the way that projects are managed. These types of methodologies are often based on rigid policies and procedures with limited flexibility but can be successful especially on large, complex, long-term projects.
These “rigid” approaches are commonly called waterfall approaches, where work is done sequentially and can be easily represented by Gantt charts. The waterfall approach begins with well-defined requirements from which we must determine the budget and schedule to produce the deliverables. This approach thrives on often massive and costly documentation requirements. The approval of scope changes can be slow because rapid customer involvement may not be possible.
For some types of projects, for example in software development, the waterfall approach may not work well because the requirements may not be fully understood at the beginning of a project. We may not have a clear picture of the approach/solution we must take to create the deliverables.
We may need some degree of experimentation which could lead to a significant number of scope changes. Customer involvement must occur throughout the project in order to address changes quickly, which mandates collaborative involvement by all participants, including stakeholders.
In this case, we may start out with a fixed budget and schedule, and then have to decide how much work can be done within the time and cost constraints. The requirements can evolve over the life of the project. For these types of projects, a more flexible or agile approach is needed.
As companies become reasonably mature in project management and recognize the need for a more agile approach on some projects, the policies and procedures are replaced by forms, guidelines, templates, and checklists. This provides more flexibility for the project manager in how to apply the methodology to satisfy a specific customer’s requirements. This leads to a more informal or agile approach to project management.
Today, most projects are managed with an approach that is neither extremely agile nor extremely rigid; it is an in between approach with some degree of flexibility and more informal than formal. Because the amount of flexibility can change for each project, this approach is sometimes called a framework.
A framework is a basic conceptual structure that is used to address an issue, such as a project. It includes a set of assumptions, concepts, templates, values, and processes that provide the project manager with a means for viewing what is needed to satisfy a customer’s requirements. A framework is a skeleton support structure for building the project’s deliverables.
Frameworks work well as long as the project’s requirements do not impose severe pressure upon the project manager. Unfortunately, in today’s chaotic environment, this pressure exists and appears to be increasing. Project managers need framework methodologies to have the freedom to meet the customer’s needs.
METHODOLOGIES CAN FAIL
Most companies today seem to recognize the need for one or more project management methodologies but either create the wrong methodologies or misuse the methodologies that have been created. It may not be possible to create a single enterprise-wide methodology that can be applied to each and every project.
Some companies have been successful doing this, but there are still many companies that successfully maintain more than one methodology. Unless the project manager is capable of tailoring the enterprise project management methodology to his or her needs, perhaps by using a framework approach, more than one methodology may be necessary.
There are several reasons why good intentions often go astray. At the executive levels, methodologies can fail if the executives have a poor understanding of what a methodology is and believe that a methodology is:
- A quick fix
- A silver bullet
- A temporary solution
- A cookbook approach for project success1
At the working levels, methodologies can also fail if they:
- Are abstract and high level
- Contain insufficient narratives to support these methodologies
- Are not functional or do not address crucial areas
- Ignore the industry standards and best practices
- Look impressive but lack real integration into the business
- Use nonstandard project conventions and terminology
- Compete for similar resources without addressing this problem
- Don’t have any performance metrics
- Take too long to complete because of bureaucracy and administration2
Other reasons why methodologies can lead to project failure include:
- The methodology must be followed exactly even if the assumptions and environmental input factors have changed.
- The methodology focuses on linear thinking.
- The methodology does not allow for out-of-the-box thinking.
- The methodology does not allow for value-added changes that are not part of the original requirements.
- The methodology does not fit the type of project.
- The methodology uses nonstandard terminology.
- The methodology is too abstract (rushing to design it).
- The methodology development team neglects to consider bottlenecks and concerns of the user community.
- The methodology is too detailed.
- The methodology takes too long to use.
- The methodology is too complex for the market, clients, and stakeholders to understand.
- The methodology does not have sufficient or correct metrics.
1. J. Charvat, Project Management Methodologies (Hoboken, NJ: John Wiley & Sons,), 2003, p. 4.
- Charvat, Project Management, p. 5.
This is an edited extract from Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 12th Edition by Harold Kerzner (Wiley, 2017)