Today’s business leaders rely on a vast array of project management methodologies. Instead of getting overwhelmed by this wealth of options, learn the highlights of each and make an informed choice for your business.
With this knowledge, you can understand the lingo other managers use, analyze their methods, and emulate their best practices!
Many businesses use the Waterfall Method, the simplest way to plan a project. Tasks flow down the list in sequential order, just like a waterfall. In this basic system, a team must complete one step before starting the next. Managers find this system very straightforward and easy-to-implement.
Just make a list of the steps you need to accomplish a deliverable item and get to work! Team members can quickly understand waterfall processes, saving project managers valuable communication time.
More managers use the Waterfall system than any other, especially in the construction and software development industries. Business leaders have created many varieties of this PM methodology, but remain consistent with these general components:
The Waterfall method best suits teams in manufacturing and construction that create physical products and follow precise assembly orders. They can easily copy plans from previous projects and apply them to their current work with little or no adjustment. Teams that need to change their plans as their projects progress, however, will find this method quite limiting.
Management experts created the CPM project management methodology over a half-century ago to highlight tasks that teams can’t begin until finishing others. For example, construction workers find it best to install toilets and light fixtures only after plumbers and electricians have run pipes and wires through the walls. And, of course, they save drywall and painting for last.
CPM managers make strings of tasks that each depend on the other. These sequential items form a team’s critical path. For example, once workers have laid a foundation and raised the frame of a house, they can conduct a number of non-dependent tasks: plumbing, electric, cabinetry, etc. However, carpet installers should wait until everyone else has finished their tasks and left the house clean and dust-free.
By determining a critical path and focusing on these important tasks above all others, managers can avoid frustrating bottlenecks. They can allocate more resources to any items on a critical path that lag behind and threaten delays.
With the CPM, managers can pull workers from non-essential tasks when they need to “unkink” the chain of events in their critical path. Because workers can complete non-essential tasks at any time, the company can continue working at a normal pace, despite changes in worker allocation.
Managers use the CCPM methodology (an extension of CPM) to prioritize critical resources. Though contractors on projects like home-building often run the risk of certain teams waiting for others to finish, they must also time out the delivery of critical supplies.
For example, a team leader might delay an order with a concrete company if they experience delays while digging a foundation. If the cement workers were to arrive and there was no place to pour concrete, they would have to dump their loads or risk its setting inside their trucks!
To avoid bottlenecks and disruptions in the ordering of resources, managers put time buffers around critical tasks. Though this slows down project completion slightly, it dramatically reduces their risks of expensive resource re-orders. These buffered tasks form a “critical chain” of the most sensitive tasks on a critical path.
A group of software development experts developed the basics of the Agile System just over 15 years ago. They created a new way to deliver value to and interact with consumers that featured four key aspects:
Project managers must value individual interactions over systems and tools.
Software should work well and not require extensive documentation.
Teams and customers should collaborate, not haggle over contracts.
Companies must prioritize responsiveness over rigid adherence to plans.
In just a short time, PM experts have expanded these concepts into many implementation frameworks, including:
Scrum Project Management
Kanban Project Management
Adaptive Project Framework (APF)
Though the linear Waterfall PM strategy suits many organizations, managers in certain fields find it quite limiting. By planning only at the beginning of a project, they lose the benefit of the knowledge and experience they gain while completing it.
Instead of creating detailed specifications for end products at the beginning of an endeavor, Agile managers only identify priorities. As their teams work towards their goals, these managers remain flexible, communicate with all stakeholders, and change product requirements whenever necessary.
The Agile PM methodology suits businesses that seek to quickly and consistently provide products to consumers. Software development companies prefer this “light-touch” management style which facilitates rapid production cycles.
With this system, team leaders can create responsive and transparent workplace cultures. By sharing responsibility with their team members, they can optimize their awareness of and reactivity to market trends and changes in demand.
Agile teams work in short “sprints” or burst of work. Team leaders quantify each of these sprints as small, deliverable units. Teams stay motivated by working on series of small, fast projects (such as software updates) and tracking their progress.
Companies increase their responsiveness to customer demands and changes in the marketplace. Software companies, for example, create Agile teams to rapidly adjust their offerings to new challenges like emerging platforms and operating system updates.
For those of you not raving rugby fans, a scrum is a tangle of heavy people who strain against each other to acquire a small, oblong, whitish ball. As business managers find such behavior undesirable in production teams, they employ the Scrum method of project management.
Scrum teams meet for monthly Scrum sessions in which they break down their projects and deliverables into 15- or 30-day chunks, called “sprints.” By working toward these small increments, teams avoid the process overwhelm typical of other PM methodologies. By re-prioritizing their efforts each month to meet consumer demand, they can stay flexible and motivated – increasing both productivity and customer satisfaction!
Dev teams often apply the popular Scrum variation of Agile Project Management. Managers find Scrum easy to implement and very effective in addressing issues affecting software development teams.
Team members enjoy the way Scrum helps them untangle complex development cycles, redefine end goals during a project cycle, and get quality products to market very quickly.
In this system, no one holds the title of “project manager.” Instead, they split up their responsibilities by taking on certain roles: ScrumMaster, product owner, and team member:
The ScrumMaster (despite their impressive-sounding title) does not take on the title of manager or team leader. This person oversees the Scrum process, not the job itself. They ensure everyone on the team communicates well on daily projects, eliminates distractions, and clears obstacles in the group’s path.
This person, either a key user or a marketing expert, gives the team a consistent vision of their initial goal: to meet customer needs. Because a team’s concept of their end product can change as they work, the Product Owner performs a vital “grounding” function.
Teams meet daily to discuss their completed work and identify any roadblocks to further progress. The Scrum Master agrees to deal with these roadblocks; the Product Owner collaborates with the team to optimize product targeting.
The Scrum Method works best for small teams that work together in one environment and focus on only one project at a time. It facilitates open communication and creativity, as well as rapid development/testing cycles.
Scrum works especially well when teams have substantial support from upper management, in the form of open financial and time budgets.
Originally developed by Toyota in the 1940s, Kanban means “signal card” in Japanese. This method relied on Kanban cards, which indicate the need to reorder certain supplies. Many managers consider Kanban a Lean Manufacturing system because it eliminates wasted time and resources. In short, Kanban makes companies “lean and mean.”
Many project managers use Kanban concepts in conjunction with Agile methods. The genius of Kanban is “on-demand” production, in which customer orders “pull” items through a production facility.
This idea replaces the traditional method of producing large amounts of products and warehousing them in anticipation of an estimated demand. In a software development setting, this idea of customer demand powering a system fits hand in glove with Agile.
In the workplace, Kanban teams originally visualized their workflow as cards moving from left to right across a Kanban board. They grouped tasks and projects into broad categories:
In Queue (a U.K./Commonwealth term meaning “in line”)
Modern Agile/Kanban managers use virtual “cards’ to represent units of work flowing through their systems. By engaging visually with their workflow, team members and managers can easily estimate and prioritize upcoming tasks.
When assigning new tasks (inspired by customer demand), executives use Kanban boards to assess a team’s current workload. They can easily estimate the effects additional tasks would have on a team’s current productivity.
The Agile/Kanban hybrid project management methodology works best for small teams that work in a single, shared location. Even people who work independently find this PM method useful.
Like all Agile systems, Extreme Programming focuses on teamwork and customer satisfaction. It features five basic tenets:
Extreme Programming teams work in shorter sprints typical for Agile/Scrum companies. These shorter cycles allow them to maintain rigid task structures. EP teams don’t embrace as much flexibility as other Agile teams, undertaking tasks in a strict priority order.
The EP methodology mandates specific engineering practices such as test-driven product development, automated testing, simple and elegant design, refactoring, etc. Experts recommend teams begin with Scrum and adopt EP slowly as they determine their own best practices and engineering protocols.
The Adaptive Project Framework allows Agile teams to work with optimal flexibility and epitomize the idea of “agility.” Sometimes teams must improvise their systems and protocols as they work, due to roughly-defined goals and outcomes.
The APF framework best suits unique challenges which don’t call for one size fits all solutions. This approach empowers teams because they aren’t expected to blindly follow pre-ordained scripts.
In this model, clients work directly with Agile teams and select the exact features they need in finished products. Consumers appreciate not having to accept products that meet some, but not all, of their needs.
Regardless of the flavor of Agile you choose, they all share certain commonalities. Agile teams:
Maintain clear project objectives, though final product may change as they work.
Work in iterative cycles, constantly evaluating their results.
Optimize their deliverables to meet consumer needs.
Collaborate continuously with each other, stakeholders, and customers.
Another project management methodology preferred by software development teams, the Rapid Application Development model facilitates interaction via certain, structured techniques.
RAD teams create prototypes to determine user needs and redefine their designs. They repeat this cycle many times throughout the development process to optimize product quality and user experience.
RAD teams move quickly, putting off large design improvements to future production/software update cycles. These nimble organizations often re-use components of other software systems to focus on immediate customer demands. RAD managers focus on consumer data gathered from focus groups and workshops to rapidly deliver desirable products.
The RAD method works best for teams that don’t require long interactions and deep development of complex functions. RAD teams excel at light applications and rapid development cycles.
Business leaders use the NPI methodology to focus on certain steps of a task, not the management of entire projects. For example, NPI teams don’t spend time creating Work Breakdown Structures (WBS) and mapping out tasks and budget allocations across vast, complicated projects. Instead, they focus on communication with all stakeholders in a project – both inside and outside of an organization.
The NPI project management strategy works best for product-based teams because NPI managers shepherd single products through their entire development process. These managers create teams from all sectors of an organization involved in creating a new product. With their teams, they guide and shape a product all the way through to its launch.
Project leaders use the PER project management methodology to redesign a product or system from the ground up. By taking a fresh look at a company’s offerings and redesigning them completely, PER teams can shed outdated assumptions and organizational habits.
PER managers help organizations stay true to their commitment to growth with regular reviews of the modification process. They create and maintain corporate cultures of innovation and help their colleagues let go of old ways of doing things. With the potent PER method, companies can change rapidly to address changes in consumer demand and maximize their returns on investment.
Not to be confused with the PMBOK, the Project Management Institute’s Project Management Body of Knowledge (a best-practices resource), PRINCE2 is a complete project methodology system.
Used by the U.K. government and many private-sector organizations across the globe, PRINCE2 has much to offer U.S. organizations:
Greater Resource Control
Increased Project Risk Management
Clear and Structures Responsibility Allocation
A focus on End-User “Whos, Whens, and Whys”
Consistent, Organized Planning and Execution
Regular Review Justification Cycles
The Motorola company originally developed the highly-disciplined Six Sigma system to eliminate defects. They wanted their products and services to conform completely to their original specifications throughout the entire design, production, and delivery process.
Some experts consider Six Sigma more of a quality-control and apparatus than a true project management methodology, due to its focus on gathering data and improving processes. Companies typically use this method to increase efficiency, raise productivity, and deliver uniform products to consumers.
Six Sigma Managers use 5 process steps, collectively called DMAIC-S:
Define customer needs. By identifying and profiling ideal customers and understanding how to serve them, managers can shape the scope and purpose of a project.
Measure the performance of a process. By creating appropriate metrics for gathering data on productivity, managers can determine how well a system meets consumer needs.
Analyze common problems. Six Sigma managers examine performance gaps to determine their root causes and back up their observations with hard data.
Improve systems. Executives design, test, and execute new systems to address the root causes of systemic problems. They continue to rely on data in their evaluations of these solutions (and the implementation of these fixes).
Synergize these results throughout the company. Six Sigma managers know that changes to one area of operations affect all other parts of a business, to some degree. They share the experience and knowledge they have gained from an optimization cycle with their colleagues and supervisors.
Some managers follow the DMAIC method without employing the entire Six Sigma management strategy. They use this data-driven method to improve, optimize, and stabilize their designs, processes, and systems.
The International Development Research Center (IDRC) developed the outcome mapping project management methodology. Many charitable organizations which bundle large donations into grants for developing countries use this system.
With the Outcome Mapping PM methodology, charities can measure the effects of their efforts on secondary beneficiaries. They take care to ensure that the recipients of large grants create benefits for large groups of people and facilitate positive behavior changes.
Organizations that use this PM methodology divide their tasks into two distinct phases:
Design– Project leaders write essays in which they identify their direct partners (governments and local organizations who receive funds) and indirect partners (people in need who receive benefits). They determine progress markers, appropriate actions for partners to take, and suitable metrics for later record-keeping.
Record-Keeping – Outcome mapping organizations keep three types of journals: performance (meeting minutes and organizational progress), strategy (tasks completed in the overall plan), and outcomes (realization of stated goals and desired results).
Outcome mapping works best for groups that contribute to others instead of creating products and services. Organizations outside the philanthropy sector rarely use this PM methodology.
Some, but not all, managers consider the PMI’s Guide to the Project Management Body of Knowledge (PMBOK) a PM methodology in its own right. Others consider it more of a reference book. Certainly, the PMBOK provides an essential set of conventions and standardizes the professional terms used by PM experts.
Regardless of opinion, the PMI has influenced managers to break projects into five steps:
Your tools must match your aims and strategies. Consider the following attributes of your current (and desired) PM software:
The companies that developed your PM software platform probably shaped it to suit a particular strategy. For example, RAD methodologies sync well with object-oriented programming languages like Java and C++. Services like MeisterTask and Trello offer interactive “boards” that mesh perfectly with Kanban corporate structures.
Check with your software platform provider to see what management strategies work best with their systems – and which variants (especially of Agile) they support. You and your team will love the smooth workflow that comes from matching the right software and the right PM methodologies with the right people!
And keep in mind: Toggl Track integrates with most project management software out there, so check out our tools page and start tracking your time from within the PM software of your choice.
Teams of 10+ are eligible for a personalized demo to see how Toggl Track can meet your time tracking goals