Home > Articles

  • Print
  • + Share This
This chapter is from the book

Common Project Management Methodologies

There are a surprising number of project management methodologies. Some are broad-based tools appropriate for a wide variety of projects, industries, or activities; others are more narrowly focused in a particular area. Some of the most common are listed alphabetically and discussed below. In interesting contrast to The PMBOK Guide—which enjoys near universal agreement with the information it presents—project management methodologies are the subject of some disagreement. In fact, there isn’t even consensus on what to call them; some refer to these methods, techniques, and practices as methodologies, some call them processes, others frameworks or tools, and still others use all these (and other) terms interchangeably. The following list presents some of the most widely known methods of project management:

Agile—As the name implies, this method focuses on speed. There are multiple approaches to Agile Project Management, but in general the project manager (PM) or team manages the project in small “iterations” or sections. As each iteration is nearing completion, it is reviewed and critiqued, and a decision is made on the next step of the project. This method preserves flexibility and works well on projects where a large number of changes, issues, or uncertainty is anticipated. One important caveat: To be optimal, the PM or team must be empowered to make decisions quickly without taking them to a champion, committee, or oversight board.

Figure 1.8

Figure 1.8 Agile Project Management contrasted with the PMBOK Guide’s Process Groups.

Source: http://www.agileconnection.com/sites/default/files/article/2012/XDD10365imagelistfilename1.gif

Figure 1.9

Figure 1.9 Example of a critical path work breakdown structure (WBS)

Source: http://www.codeproject.com/KB/recipes/CriticalPathMethod/CPMTestCase.png

Critical Path—The critical path method assigns a time duration to each project task, and then deploys resources necessary to accomplish the task within the scheduled timeframe. Only a very few of the many project tasks are “critical” (with regard to time); this method is very much focused on due date performance. A noncritical task can miss its due date, or “slip”—sometimes significantly—without impacting the overall schedule due date. If a critical task slips, the overall project date is adjusted accordingly (or the PM team takes other intervening actions to mitigate the lost time).

DMAIC—Similar to (or perhaps a subset of) Six Sigma and typically used in improvement projects, DMAIC is an abbreviation for Define, Measure, Analyze, Improve, and Control. All five steps are required for a DMAIC project and are accomplished in the prescribed order.

Kanban—Like DMAIC, the focus in Kanban is usually process improvement. Some argue neither of these two are true project methodologies; others disagree. It begins with a unique project; the results of that project are usually incorporated into ongoing operations (for example, improved method of managing a process). Kanban is a visual process management system that aims to reduce waste by controlling what is produced, when it is produced, and how much is produced.

PRINCE2—An acronym for PRojects IN Controlled Environments, PRINCE2 enjoys widespread recognition and use in the United Kingdom and internationally. Like the PMBOK Guide, it is a body of knowledge and presents best practice project management guidance in a nonproprietary manner.

Figure 1.13

Figure 1.13 RAD illustration; compared with traditional development

Source: http://www.softtrust.com/images/TRADvsRAD1.gif

RAD—Rapid Application Development is another process improvement methodology applicable for software development. It is structured and disciplined and involves the customer. Similar to Agile and Scrum, it emphasizes development speed.

Scrum—Scrum is a type of agile project management where small teams work independently on various tasks or subsections. The PM is known as a scrum master, and the teams meet daily to collaborate and focus on common project interests. Similar to agile, scrum focuses on speed, and tasks (or iterations) are worked quickly, exclusively, and with high intensity. Scrum is typically used in software development but is also well-suited for projects requiring work from multiple disciplines. I recently used scrum to establish an organic C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) depot for the U.S. Air Force and employed various team of logisticians, supply chain managers, avionic technicians, facility engineers, industrial engineers, software engineers, and electricians. This approach allowed multiple subprojects to be accomplished concurrently and was completed ahead of schedule and under budget.

Six Sigma—This method is typically deployed as a tool to find solutions to problems and prevent their recurrence by resolving the root cause. Many similarities exist between Six Sigma and the PMBOK Guide, but there is also disagreement; some think it more broadly applicable (beyond the discipline of project management) than the PMBOK Guide, yet others consider it more narrowly focused. There appears to be at least broad agreement that Six Sigma is a compliment (but not necessarily a replacement) of the PMBOK Guide and may be used on many projects.

Traditional—Traditional Project Management is a step-by-step approach of managing the project through five stages: initiation, planning, execution, monitoring, and closing. This method is commonly used in construction and other projects where relatively little change is anticipated during the life of the project. Project stages are accomplished in chronological order; a stage begins only after a preceding stage has been accomplished.

Waterfall—Waterfall Project Management is used primarily in software development. It employs a linear approach, and usually each event is a distinct stage of software development and is finished before the next begins. There is a unique review stage where the customer reviews and approves requirements before development work begins. This should prevent unpleasant surprises at the end of the project, but communicating about requirements in ways that are meaningful for customers can be difficult and often represent the most troublesome aspects of software development projects.

  • + Share This
  • 🔖 Save To Your Account