A project management methodology brings order into this environment. It clarifies activities and decisions. It sets expectations and identifies problems and issues. A project management methodology enables proactive management rather than reactive fire-fighting as the future state is created. But the wrong project management methodology can make things worse. It can create confusion, frustration, delays, overruns and ultimately project failure.
There seems to be hundreds of gurus and experts touting their project management methodology as the best. In reviewing these, there are three categories of project management methodology that emerge. Each of these has strengths and weaknesses. Each of these is appropriate for some types of projects and not others. Each of these has many variations as they are uniquely applied to different projects, different industries and in different organizations. The three are sequential/waterfall, adaptive/concurrent, and agile/scrum.
This is the approach most often associated with traditional project management. In this approach, the project starts with a clear and specific set of requirements. A detailed project plan is created where each organization or individual is assigned a specific task that is to be done at a set time and for a set amount of resources. As one project task completes, the results are handed to the next individual or organization in the planned sequence.
This approach relies on the development of a detailed project plan. The classic project management tools such as a Work Breakdown Structure (WBS), Gantt Chart, Critical Path Analysis, Responsibility Matrix, and Earned Value Analysis are ideally suited for this type of project. These tools are used to optimize the project during the planning phase in order to meet the requirements within the best overall time or cost.
This approach is well suited for those projects where the requirements are known and stable. It provides order and predictability to project activities. However, it is not very flexible. In an unstable environment or when the requirements are only general in nature and not specific. The project manager either cannot form a plan or they must make many assumptions, some of which are sure to be wrong, in forming the plan. Changes to the plan with this approach are often time-consuming and expensive, so this approach should not be used with a highly dynamic environment.
This is the approach that is often used with complex projects. In this approach, a cross-functional or multi-disciplinary team manages the project through a series of phases. As the project starts, the team is considering requirements and options to decide a framework for the project result. The team reaches a decision and they start on the next phase. The project progresses from phase to phase with all disciplines participating in the work concurrently and then agreeing on the project decision before moving to the next phase. The project adapts as the team is able to use the results and conclusions from one phase to influence the activities and decisions of the later phases.
This approach relies on a highly collaborative project team. Rather than a detailed prescriptive project plan, the team uses key milestone decisions to guide the project activities. The work is often iterative in nature as each of the team members builds on the solution from the preceding phase. These projects are often managed by a series of checklists for each milestone decision point. Project management tools that help to managed complexity such as the Network Diagram, Responsibility Matrix, and Risk Register are particularly useful with this approach.
This approach is well suited for those projects where the requirements are general in nature and the details must be determined during the course of the project. In addition, this approach works well when cross-functional decisions are required to reach an optimal project result. However, this approach requires a high level of interactive participatory project management. The detailed plan is continually changing which requires a high level of project integration activities. This approach is not appropriate for organizations that do not work well in a collaborative dynamic environment.
The agile methodologies came onto the scene in 2001. Several agile methodologies were created for software development. The Scrum approach has become the most widely adopted and is now used in many settings beyond software development. This approach has provided structure to an age-old practice of putting a dedicated team on an urgent business problem to resolve it – the crisis project. In this approach a dedicated team is assigned for a short duration to work on focused and prioritized set of requirements, known as a sprint. The team does as much as it can in the specified time and delivers whatever it completes. Requirements not completed within the time period are either dropped or transferred to a new project. On larger projects, a series of sprints may be used.
This approach relies on dedicated self-organizing team to work collaboratively to complete as much as they can in a short time. The classic project management tools are not used. Instead, the team relies on a prioritized list of requirements and two visual control charts, a Scrum Board and a Burndown Chart to track progress.
This approach is ideal for relatively small projects where time is critical and the scope can be flexible. The project duration can be shortened by an order of magnitude, but it is essential that the team be fully dedicated and fully empowered to do the project work. In a highly regulated environment with externally specified requirements and extensive documentation, the benefits of this approach or lost. Also, when the project team needs to be very large, this approach is inappropriate.
So to choose the best approach, consider your situation – both the project and the organization. You may find the need to modify one of these a little, or even use a hybrid where one approach is used for a portion of the project and another for the remainder.