Maybe you’re new to project management; maybe you need a refresher session on the simple structures that underpin your job – maybe you’re just winging it. Whichever category you fit into, here’s a cut-out and keep overview of how to deliver a project.
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 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.
The characteristics of a good methodology based upon integrated processes include:
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:
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:
At the working levels, methodologies can also fail if they:
Other reasons why methodologies can lead to project failure include:
1. J. Charvat, Project Management Methodologies (Hoboken, NJ: John Wiley & Sons,), 2003, p. 4.
This is an edited extract from Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 12th Edition by Harold Kerzner (Wiley, 2017)