There is no single project management methodology that fits every team. A product group discovering what customers need works under different conditions from a construction project with fixed drawings, suppliers, and handover dates. The practical question is not which method is fashionable, but which one makes uncertainty, dependencies, ownership, and progress easier to manage.
This guide compares 12 approaches and offers practical guidance for assessing them in your work.
For a broader foundation, see Project Management Fundamentals for Entrepreneurs (in Russian) and How to Choose a Project Management System.
Contents:
1. Agile
Agile is an umbrella term for adaptive ways of working. Instead of trying to define the entire project in detail at the start, a team works in short cycles, produces a usable result, gathers feedback, and adjusts the next step. This is useful when the goal is clear but the best solution is still being discovered.
Works best for: digital products, services, research, and other work where requirements may change as the team learns.
Main advantage: the team can test assumptions early and reduce the cost of building the wrong thing.
Main risk: flexibility can become disorder if priorities, decision rights, and the definition of done are unclear. Agile still needs disciplined planning and transparent change control.
When planning a short cycle, decide in advance what finished result the team will show at its end. For example, discuss a result for the coming week and how it will be checked. Acceptance, payment, and putting the result into use depend on the project and agreements; they do not by themselves determine whether the team is using Agile. Keep visible what is done, what is in progress, what is blocked, and which scope changes have been agreed or are still under discussion. For construction and renovation, discuss whether short cycles fit the specific site, work methods, and change agreements: see Agile in Construction (in Russian). Agile involves working with change. Without an agreed process for assessing its schedule and cost implications, there is a risk of uncontrolled growth in work.
2. Waterfall
Waterfall organizes work as a sequence of phases: requirements, design, execution, testing, and delivery. A phase is normally completed before the next one begins. The approach is easiest to manage when the expected result, constraints, and acceptance criteria can be specified in advance.
Conditions to assess: how clearly requirements can be defined in advance and how costly late changes would be. An engineering project, a regulated project, or a fixed-scope implementation can serve as examples for this assessment. Agree on requirements and a process for revising the plan before work begins.
Main advantage: milestones, documentation, budgets, and responsibilities are easy to align with a baseline plan.
Main risk: late feedback can reveal a requirements error that requires completed work to be redone. Set a change process in advance: a formal request, impact assessment, decision, plan update, and recorded agreement.
3. Scrum
Scrum is a lightweight framework for solving complex problems through short, fixed-length iterations called sprints, no more than one month long. Work is ordered in a product backlog. During each sprint, the team focuses on a sprint goal and creates a usable increment, then reviews the result and improves its way of working.
Works best for: small cross-functional teams that can deliver and inspect a meaningful result every few weeks.
Main advantage: sprint planning, daily synchronization, review, and retrospective events create a reliable feedback rhythm. The Product Owner is responsible for priorities and the value of the result; the Scrum Master supports the process and helps remove impediments; the team does the work and is responsible for quality.
Main risk: teams sometimes copy the meetings but ignore the underlying commitments and accountabilities. The team needs to split work into small, verifiable results and deliver each iteration. If each sprint ends with work that is only almost ready, Scrum becomes a reporting ritual.
4. Kanban
Kanban visualizes work as it moves through a workflow. The team limits work in progress, monitors flow, and improves the system continuously. New work can enter when capacity becomes available, so Kanban does not require fixed sprints.
Contexts to consider: support, operations, agency workflows, maintenance, content production, and teams receiving a continuous stream of requests.
Main advantage: bottlenecks and overloaded stages become visible. Work-in-progress limits encourage finishing before starting more. They limit how many tasks are in progress at once, reducing parallel work that can make everyone look busy while deadlines slip and quality suffers.
Main risk: a board without explicit policies and flow metrics is only a task list. Define when an item can move, who can pull it, and how blocked work is handled.
If a project depends on a critical sequence of deadlines, you can supplement the board with a schedule and explicit dependencies.
5. Scrumban
Scrumban combines elements of Scrum and Kanban. Teams use different sets of rules, so agree in advance on the planning rhythm, prioritization, visualization of flow, and work-in-progress limits.
Adaptation to discuss: a team handling project tasks and urgent requests could retain regular planning and prioritization while agreeing on explicit policies and work-in-progress limits for accepting new work. This is an example for discussion, rather than the only required form of Scrumban.
Planning check: confirm that the planning rhythm and flow limits have a clear purpose for the team.
Rules to agree: for this adaptation, define what counts as urgent, who may change priorities, and when a prepared task can enter the workflow.
6. PRINCE2
PRINCE2 is a structured project management methodology. It brings together management principles, practices, and processes from project initiation to closure, and defines participants’ roles and responsibilities.
Conditions to assess: whether the project needs an agreed process for decisions, communication, and responsibility. A contract project or a large implementation can serve as examples for discussing this process.
Questions to clarify: who approves, who performs the work, who checks the result, and how information is shared.
Tailoring: adapt the methodology to the project’s needs, size, complexity, and context. For a small project, decide in advance how much control and documentation is needed, keeping management meaningful.
7. Six Sigma
Six Sigma is a data-driven approach to reducing defects and variation in a process. A common improvement cycle is DMAIC: define the problem, measure current performance, analyze causes, improve the process, and control the result so gains are sustained.
Works best for: repeatable processes where quality, consistency, and measurable error rates matter.
In service companies, defects can include data errors, missed service-level agreements (SLAs), rework, or excessive time spent on approvals.
Main advantage: decisions are based on evidence and root-cause analysis rather than intuition alone.
Task assessment: for research work, such as finding a market for a product, exploring a design, or testing hypotheses, first clarify which measurable process problem needs to be solved. You can consider the repeatable part of the work separately; choose the approach with the task and available data in mind.
8. Critical Path Method
The Critical Path Method, or CPM, models project activities, durations, and dependencies to identify the sequence that determines the calculated project duration. In the network model considered here, critical activities have zero float. With other conditions unchanged, increasing the duration of a critical activity moves the calculated project finish date. Activities outside the critical path may have float, allowing some delay without moving that date.
Works best for: construction, installation, launches, and other projects where activities have clear dependencies and estimated durations.
Main advantage: managers can see which tasks deserve the closest schedule attention.
Main risk: the result depends on the dependency map and duration estimates. Update the network with actual progress, record changes, and recalculate dates. Assess resource needs and financial consequences separately: a basic critical path calculation is not itself a budget model.
9. Managing with the Critical Path
CPM becomes useful when it guides daily decisions: plan, calculate the critical path, check actual progress, recalculate, and make management decisions. Decide who updates the plan, who confirms completed work, and who approves replanning. A practical operating cycle is:
- Break the project into activities and deliverables (a work breakdown structure, or WBS) so that completed work can be checked and accepted.
- Connect real dependencies and identify work that can run in parallel.
- Estimate durations with the people responsible for the work and record the assumptions.
- Calculate the critical path and available float, and identify bottlenecks.
- Set a daily or weekly rhythm for updating actual progress and agree on replanning rules. Review the path and act on emerging delays.
- Record scope changes and their effect on time and money.
When deviations occur, consider options such as accelerating a critical activity, changing a permissible sequence, adding capacity, revising scope, or agreeing on a new date. Check each option’s technical feasibility, agreements, cost, and effect on the recalculated plan separately.
10. Lean
Lean management starts with customer value and seeks to remove work that does not contribute to that value. Teams map the flow, reduce waiting, handoffs, rework, excess inventory, and other forms of waste, then improve the process continuously.
Examples to investigate: standard renovation jobs, repeated builds, regular services, and opening new branches from a template. Look for waiting, rework, or unnecessary approvals, and test changes against actual data.
Improvement focus: investigate changes to the system and evaluate their effect on speed and quality.
Main risk: over-optimizing work that needs variety can remove useful learning. In creative or exploratory projects, some apparently extra activities help the team learn and reduce the risk of a wrong turn. Remove disorder while preserving learning.
11. PMBOK Guide
The PMBOK Guide is a body of project management knowledge, principles, and performance domains rather than a step-by-step methodology. It gives teams a shared vocabulary for areas such as schedule, cost, risk, procurement, quality, communications, stakeholders, planning, delivery, measurement, uncertainty, and tailoring.
Works best for: organizations that need a broad professional reference and a common management language across different project types.
Main advantage: teams can select practices and artifacts that fit the context instead of forcing every project into one lifecycle.
A three-week project and a year-long project need different levels of planning, control, and documentation, while still addressing goals, scope, schedule, budget, risks, and acceptance. For daily work, start with a project charter or goal, a work breakdown structure, a schedule, a budget, a risk register, and a change-management process.
Main risk: treating the guide as a checklist creates unnecessary documentation. Start with the decisions the project must support, then choose the lightest useful artifacts.
12. Extreme Programming (XP)
Extreme Programming is an Agile software development method that emphasizes rapid feedback and technical quality. Common practices include test-driven development, continuous integration, refactoring, pair programming, simple design, and frequent small releases. Although XP comes from software development, the useful principle applies more broadly: build quality into the process rather than try to catch defects at the end. These short-feedback practices reduce the risk of spending a month on the work only for everything to break afterwards.
Works best for: software teams facing changing requirements where automated tests and close collaboration are feasible.
Main advantage: engineering discipline keeps the code easier to change as the product evolves.
Main risk: practices fail when adopted in isolation. Frequent releases without tests increase risk, while pairing without shared ownership becomes a scheduling burden.
Consider XP for development with regularly changing requirements when the technical context allows automated checks. If a team rarely releases changes, has no tests, and integrates manually, one possible starting point is an automated quality check on every change.
How Do You Choose the Right Project Management Methodology?
Choose from the characteristics of the work, not from the label. Start with five questions:
- How stable are the requirements? Stable, regulated, or physically constrained work often benefits from predictive planning. Discovery-heavy work needs shorter feedback loops.
- How expensive is change? If late changes are costly, invest more in definition and sequencing. If experiments are cheap, learn through small increments.
- How does work arrive? A continuous request stream may suit Kanban; frequent delivery of usable results may benefit from Agile or Scrum with short iterations; dependency-heavy delivery may need CPM, a Gantt chart, and regular schedule recalculation.
- What governance is required? If management control and reporting determine success, consider PRINCE2 and PMBOK as a basis for the processes. Multiple sponsors and staged approvals may justify formal controls, while a small team can use a lighter approach.
- Which evidence matters? Process defects may call for Six Sigma, flow problems for Lean or Kanban, and software quality risks for XP practices.
Within one business, you can discuss combining approaches: calculate dates using the critical path, consider changes in short cycles, and visualize incoming requests with Kanban. Check what problem each practice addresses and how the practices connect.
Review the approach at meaningful checkpoints. If decisions are slow, work stays blocked, plans become stale, or reporting consumes more effort than delivery, adjust the system. A methodology is a tool for coordination, not a goal in itself.
Keep Delivery and Project Finance in the Same Picture
A sound methodology explains how work moves, but managers also need to see the financial facts behind each project: planned and actual income, expenses, commitments, and the effect of delays on the result. When operational progress and finance live in separate files, a team can finish tasks while missing the business outcome.
For practical work, connect the project plan with financial records and documents. In 101, the project finance tools cover income, expenses, supporting records, reports, and analytics.
For practical guidance, see Project Accounting Without a Bottleneck (in Russian) and How to Manage a Project Budget in the 101 App.
A live demonstration of the 101 App can help map responsibilities and identify where time and money are being lost, connecting the chosen management approach to financial records and reporting.
As the number of projects grows, managers need to consider project comparisons, shared expenses, and business resilience throughout the season separately. For company finances, PRO+ includes the Company Fund and tools for distributing profit among participants; details depend on the service’s current terms.
