![\"Diagram](\"/article-assets/metodologie-project-management/metodologie-project-management-waterfall.jpg\")
In most companies the dilemma shows up the same way. Something that starts as \"a quick job\" — a new management system, opening a new site, launching a product line — turns into a construction site with slipping deadlines, rising costs and responsibilities that stay implicit. At that point someone suggests \"going Agile\" or \"doing Waterfall,\" often without a clear distinction between the two terms.
\nProject management methodologies are established ways of organizing a project — defining its phases, responsibilities, review cadence and adaptation mechanisms — developed and tested over decades of practice and research. The main ones are Waterfall, Agile (with its operating frameworks Scrum and Kanban), Lean and the hybrid approach that combines elements of the others.
\nThis article briefly outlines the features of each methodology, the situations where it works best, the constraints it imposes and the typical company settings where it proves a good fit. The logic is one of choice, not ideological allegiance: no methodology is \"the best\"; there is a suitable methodology for every combination of project and context.
\nThe goal is not to turn the business owner into a certified Scrum Master. It is to provide a practical map for deciding, when the next major project comes along, which methodology to adopt and why.
\nHow often, within the same project, do the people involved use the same word to mean different things? More often than you would expect: it is the leading cause of slippage, ahead of time or budget constraints.
\nIt is common to face a major initiative — a new management system, opening a new site, launching a service — and discover that the people involved use the term \"Agile\" or \"Waterfall\" to mean different things. Confusion between methodologies, frameworks and processes is the first source of operational misalignment. A paper by Conforto and colleagues in the Project Management Journal shows that the number one enabling condition for any methodology is a shared, clear understanding of what is being done [5]. This section sets out the working definition, distinguishes the three most commonly confused terms and explains why, in a company without a dedicated project manager, a deliberate choice is worth more than blind adherence to a fashionable method.
\nWorking definition. A project management methodology is a coherent set of principles, phases, roles and control mechanisms that guide how a project is carried out — a project being a temporary initiative with a specific goal, a beginning and an end. It is not a business process, which is recurring and repeats the same sequence for predictable outputs (e.g., issuing an invoice, onboarding a customer). Nor is it simply a framework, which operates at a more operational level.
\nThree terms that are often confused — and how to tell them apart.
\nMethodology vs. framework. The methodology is the structural level: the principles that guide how the project is managed. The framework is the operational level: the concrete rules and roles. Example: Agile is a methodology, Scrum is one of its frameworks. You can apply the Agile philosophy without adopting Scrum, and you can \"claim to do Scrum\" without truly being Agile.
\nMethodology vs. business process. A process is recurring and produces standardized outputs. A methodology handles the uniqueness of a project, where the output is new and the path is partly yet to be built. Confusing the two leads to rigidly \"proceduralizing\" a project when adaptability is needed, or vice versa.
\nAgile vs. Scrum. Agile is a philosophy with four values and twelve principles (Agile Manifesto, 2001). Scrum is one of the frameworks that implements it, with well-defined roles, events and artifacts [2]. You can do Agile without Scrum (for example with Kanban), and you can \"say you do Scrum\" without being Agile.
\nTwo technical terms to keep in mind for the rest of the article: a stakeholder is anyone with a direct interest in the project (client, end user, supplier, company manager); a deliverable is the tangible, verifiable result produced in a phase (a document, a prototype, a released feature, a completed installation).
\nFor a broader overview of project management as a discipline, see the guide on project management for business owners.
\n\n\n
How many projects start with the requirements already written down in black and white, and how many define them along the way? The answer to this single question already rules out two methodologies out of five.
\nMethodologies are not chosen for their cultural affinity with the business owner; they are chosen based on the characteristics of the project and its context. Three variables explain most good and bad choices: how certain the requirements are at the start (do we already know what we want, or will we find out along the way?), the size of the team involved (three people or fifteen?) and the tolerance for changing course midway (can we readjust as we go, or not?). For Italian firms, the Bank of Italy documents that structured management practices — tracking indicators, setting goals, incentives — are positively associated with productivity and are less widespread where the company remains family-run and locally managed [7]: the way a company is run therefore affects which methodology it can sustain. This section explains how to recognize each variable in your own context before looking at the methodologies.
\nVariable 1 — How certain the requirements are. At the start of every project, it helps to ask one question: are the requirements — that is, the characteristics of the expected result — already defined precisely enough to be written into a contract, or will they become clear during the work? If the requirements are stable (e.g., a regulatory compliance project, an installation with predefined technical specifications), a sequential methodology works well. If instead the requirements change or emerge along the way (e.g., launching a new service, software development with iterative customer feedback), iterative methodologies are a better fit. The peer-reviewed evidence from Conforto and colleagues confirms that this variable is the strongest predictor of methodological success or failure, more than team size or industry [5].
\nVariable 2 — Team size and commitment. A team of three people spending 50% of their time on the project has radically different dynamics from a team of ten working full time. Methodologies with structured rituals (such as Scrum, with Sprint, Planning, Daily and Retrospective) require a stable team that is committed enough to sustain the pace. In small, part-time teams, the rituals become a burden. In small companies, full-time commitment to a single project is rare: the same people almost always follow several initiatives in parallel, and it is worth checking this against your own staff before choosing the method.
\nVariable 3 — Tolerance for change midway. Some organizations and some types of project (construction work, public contracts, industrial installations) do not tolerate changes of course: the client wants scope and costs defined upfront. Others — especially in digital, marketing or R&D settings — consider adapting along the way a feature, not a flaw. This variable depends on the type of client, the nature of the deliverable and the contractual framework.
\nThe company's context as an implicit fourth variable. ISTAT data on the adoption of management software in Italy show a size gap that is still wide: ERP is used by 48.8% of Italian companies with 10 to 249 employees and by 85.9% of large companies [8]. Fewer formal tools supporting project management means the chosen methodology must also work with simple tools (shared spreadsheets, paper boards) without requiring a sophisticated digital ecosystem.
\nWhen the next major project comes along, which of these methodologies would produce the fewest surprises? For most companies the answer is a combination, not a single choice — as long as it is designed and not improvised.
\nThe six main options — Waterfall, Agile, Scrum, Kanban, Lean and the hybrid approach — cover nearly all the projects a company without a dedicated project manager has to handle. Each has specific origins, a declared primary or secondary source and a natural area of application. The most common mistake is choosing the \"fashionable\" methodology without looking at the real constraints: peer-reviewed studies show that the fit between methodology and context matters more than the methodology itself [4][6]. The profiles that follow present each option in a compact format: definition, primary source, when it works, when it does not, typical context in a company without a dedicated PM.
\nThe waterfall model originated in 1970 with Winston Royce's work on complex software systems [1]. The logic is a linear sequence of phases — requirements, design, implementation, testing, release — where each phase is closed before the next one opens. It is worth remembering that Royce himself, in the original paper, pointed out the limits of a rigidly linear application and recommended iterative feedback mechanisms: collective memory has reduced the model to the sequence, ignoring the author's caveats.
\nWhen it works: regulated projects, public contracts, construction, certifications, implementations with contracted scope.
\nWhen it does not work: projects with unstable requirements, a high likelihood of changes along the way, output that cannot be defined upfront.
\nIn a company without a dedicated PM: suited to regulatory compliance projects, construction work, industrial installations with predefined technical specifications.
\nAgile is a philosophy formalized in the 2001 Agile Manifesto by seventeen software professionals. Its substance consists of four values — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan — and twelve operating principles.
\nWhen it works: launching new products or services, digital marketing projects, internal software development, R&D initiatives.
\nWhen it does not work: projects with rigid contractual constraints, a client unwilling to interact frequently, regulations that require complete documentation upfront.
\nIn a company without a dedicated PM: suited to product development initiatives, website redesigns, complex marketing campaigns [5][6]. It does, however, require the client or the business owner to be available to take part on a regular schedule.
\nScrum is defined by Ken Schwaber and Jeff Sutherland in The Scrum Guide, whose updated edition dates from 2020 [2]. Three roles (Product Owner, Scrum Master, development team), five events (Sprint, Sprint Planning, Daily, Sprint Review, Retrospective) and three artifacts (Product Backlog, Sprint Backlog, Increment) make up its backbone. The Scrum Guide specifies that the framework is lightweight, intentionally incomplete and non-prescriptive about tools.
\nWhen it works: a stable team of 3–9 people, incremental output that can be released at the end of each sprint, a client or delegate who is available.
\nWhen it does not work: teams that are assembled only at the start of the project, people whose commitment is fragmented across several projects, non-incremental output.
\nIn a company without a dedicated PM: applicable in dedicated digital product teams; harder in teams that work on the project part time, because Scrum rituals require continuity.
\nKanban originated as a visual system in the Toyota Production System and was applied to knowledge work by David J. Anderson in 2010. The peer-reviewed reference that tests its effectiveness against other methodologies is the study by Cocco and colleagues [4]. The logic is simple: visualize the workflow on a board with columns (To do → In progress → Done), limit work in progress (WIP limit) and optimize lead time.
\nWhen it works: ongoing flow-based work (evolutionary maintenance, support tickets, editorial work, pipeline-managed sales), teams that absorb heterogeneous requests.
\nWhen it does not work: projects with a single, contracted deadline; teams that need formal review milestones.
\nIn a company without a dedicated PM: perhaps the most immediately applicable option in companies with no tradition of formal project management, because it builds on tools already in widespread use (paper boards, Excel, management systems with status fields) [4]. Reducing WIP improves the predictability of the flow and reduces implicit multitasking.
\nLean was systematized by James Womack and Daniel Jones in Lean Thinking (2003) [3], drawing on the Toyota Production System. Five principles — define value for the customer, identify the value stream, make the flow run, pull from the customer, pursue perfection — guide the systematic elimination of activities that do not create value.
\nWhen it works: optimizing recurring processes, reducing waste in production and services, cross-functional continuous improvement.
\nWhen it does not work: as the sole methodology for a stand-alone project, because Lean was born for the continuous flow of value, not for a temporary initiative.
\nIn a company without a dedicated PM: often used as a complement to another methodology (Lean + Waterfall, Lean + Kanban) rather than on its own. The logic of reducing waste also applies well to small organizations, without requiring a complete reorganization.
\nThe hybrid approach has no single founding father, but its effectiveness is documented empirically. The study by Bianchi, Marzi and Guerini (2020) on a sample of 471 companies compares pure Agile, Stage-Gate (similar to Waterfall) and hybrid approaches: hybrid approaches outperform pure Agile and pure Stage-Gate in settings of medium complexity with partially known requirements [6].
\nWhen it works: projects of medium complexity, mixed constraints (some fixed deadlines + adaptable parts), teams with uneven experience of the methods.
\nWhen it does not work: as an excuse not to choose (\"let's just see how it goes\"); a hybrid is designed upfront, not improvised after the fact.
\nIn a company without a dedicated PM: according to the peer-reviewed evidence [6], it is often the most effective operating default for smaller companies, where fixed contractual deadlines coexist with the need for continuous adaptation. A common example: Waterfall-style initial planning (high-level phases and deadlines) + Kanban-style internal execution (visualizing and limiting WIP) + Lean logic (reducing waste in handoffs).
\nSummary comparison table
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Methodology | Core logic | When to use it | Main constraints | Typical context without a dedicated PM |
|---|---|---|---|---|
| Waterfall | Sequential phases, scope defined upfront | Clear requirements, contractual constraints | Low tolerance for change midway | Regulatory compliance, construction, installations |
| Agile | Iterations, continuous feedback | Unstable requirements, new product | Requires an available client | Product development, digital marketing, R&D |
| Scrum | Sprints, defined roles and ceremonies | Dedicated team of 3–9, incremental output | Stable, ongoing team | Dedicated digital teams |
| Kanban | Continuous flow, WIP limit, visual board | Flow-based work, heterogeneous requests | Less suited to projects with a single deadline | Maintenance, support, editorial, sales pipeline |
| Lean | Eliminating waste in the value stream | Process optimization, continuous improvement | Does not manage a single project on its own | Complement to other methodologies |
| Hybrid | Designed combination of elements | Medium complexity, mixed constraints | Must be designed upfront, not improvised | Operating default in many smaller companies |
scroll the table →
\nHow many of your most recent projects had an explicit choice of methodology at the start, and how many simply \"inherited\" an informal method? The difference between the two columns measures how many of the accumulated delays were avoidable.
\nHaving five methodologies plus the hybrid option to choose from does not make the choice easier; it makes it harder. A three-step selection matrix reduces the decision from \"which is the best methodology\" to \"which combination of variables am I facing.\" The first step classifies the project on three axes (requirement certainty, team size, tolerance for change). The second narrows the field to one or two compatible methodologies. The third checks compatibility with the company's context — client availability, tools already in use, the team's prior experience — before confirming the choice.
\nStep 1 — Classify the project on the three axes.
\nAxis 1 — Requirement certainty: high (you can write a specification) / medium (you know the work areas but not the details) / low (you find out along the way).
\nAxis 2 — Team size and commitment: small and part-time (1–5 people, 20–50% of their time on the project) / medium with variable commitment (5–15 people) / large and dedicated (15+ people full time).
\nAxis 3 — Tolerance for change: low (rigid contract, regulatory requirements, legal deadlines) / medium (some flexible parts, a client willing to negotiate) / high (iterative output, feedback built into the process).
\nStep 2 — Narrow the field.
\nHigh certainty + small/part-time team + low tolerance → simplified Waterfall (clear phases, review milestones, little formal documentation).
\nLow certainty + available client + high tolerance → Agile/Scrum if the team is stable and dedicated, Kanban if the work is a continuous flow or the team is part time.
\nMedium complexity + mixed constraints → Hybrid: high-level Waterfall planning + Kanban/Agile execution.
\nGoal of optimizing a flow (not a single project) → Lean as a complement.
\nThe evidence from Cocco and colleagues confirms that Kanban reduces WIP and improves flow predictability even in non-software settings, while Scrum supports throughput where requirements are unstable [4]. The study by Bianchi and colleagues supports the hybrid approach in settings of medium complexity [6].
\nStep 3 — Check compatibility with the context.
\nThree questions before confirming: (a) Is the client or their delegate available to take part as often as the methodology requires? If not, rule out the options that assume continuous feedback. (b) Does the team already have experience with the chosen methodology? A team with no Scrum experience does not start with Scrum: it starts with Kanban and migrates later if needed. (c) Are the tools already in use compatible? There is no need to invest in a dedicated application if the project can be managed with tools you already have.
\nWorked example. A project to open a new site: the scope can partly be defined upfront (location search, lease agreement, fit-out) and is partly adaptable (furniture, technology, layout). The team has 4 people, each with other operational commitments. Tolerance for change is medium. Result of step 2: hybrid. Step 3: the tools already in use include a shared spreadsheet and a company chat — enough for a simple Kanban board and high-level Waterfall planning. The choice is sustainable.
\nFor choosing and using digital support tools, see the article on project management tools.
\nHow many of the projects that look \"out of control\" today are truly out of control, and how many are simply following a methodology that was never explicitly chosen? There is always a methodology, even when nobody has written it down — and when nobody has written it down, it is almost always the worst one available.
\nMethodologies rarely fail because of intrinsic limits; they fail because of the wrong way of adopting them. Bank of Italy surveys of Italian firms [7] show that structured management practices are less widespread in family-run, locally managed companies; when a formal method does arrive, it often runs into five recurring patterns: choosing the methodology because it is fashionable, failing to adapt it to the context, a gap between the declared methodology and the one actually practiced, ritual overload, and rigidity in changing direction as the project evolves. Recognizing them before you start significantly reduces the cost of learning.
\nMistake 1 — Adopting a methodology \"because it's trendy\" rather than because it fits the context. A three-person team doing digital marketing that adopts full Scrum because \"that's what everyone uses\" often does not need formal Sprints, Planning and Daily meetings: Kanban would have been enough [4]. The cost of an ill-suited ritual outweighs the benefits of the methodology. First rule: choosing a methodology starts from the variables of the project and the context, not from what you read on LinkedIn.
\nHow to avoid it: apply the three-step matrix before making any choice. If the natural answer to the three axes is Kanban, do not start with Scrum.
\nMistake 2 — Skipping the step of adapting to the context. Methodologies are born in specific contexts (software development, Japanese manufacturing, large aerospace projects). Peer-reviewed evidence shows that outside their original context they require an explicit translation, not a copy-and-paste [5]. Waterfall applied to a product launch project without requirement-review clauses produces a plan that becomes obsolete within weeks.
\nHow to avoid it: for each methodology you adopt, explicitly identify what needs to be adapted to your context (team size, review frequency, tools) before starting the first project.
\nMistake 3 — Confusing the declared methodology with the one actually practiced. \"We do Agile,\" said in a meeting, followed in practice by carrying on as always, is a recognizable pattern. Test: if an outside observer watched the team for two weeks, would they recognize the declared methodology? If the answer is no, the methodology has not really been adopted.
\nHow to avoid it: make the methodology's artifacts visible (Kanban board, Sprint Backlog, project Gantt chart) and update them publicly. What is not seen is not practiced.
\nMistake 4 — Overloading the team with rituals without explaining their value. Daily stand-ups, retrospectives and Sprint Planning make sense if the team sees them as useful. Imposed from above without explanation, they generate resistance and then abandonment. They tend to create the paradox of \"spending more time talking about how to work than working.\"
\nHow to avoid it: introduce rituals one at a time, starting with the most immediately useful one (often the board that visualizes the work), and measure whether they produce a benefit the team perceives within the first four weeks.
\nMistake 5 — Not revisiting the methodology when the project changes nature. A project that starts with clear requirements (Waterfall) and then pivots to a new customer segment requires updating the methodology, not carrying on out of inertia. The methodology is a tool serving the project, not the other way around.
\nHow to avoid it: build at least one formal methodology review into the plan (e.g., every 8–10 weeks), in which you check whether the methodology adopted still fits the project's variables [5].
\nThe considerations in this article apply mainly to companies with small teams (2–20 people) and no dedicated project manager. Large companies with formalized PMO structures operate in a different context, with methodologies that are often hybrid and formal certifications (PMP, Prince2, SAFe).
\nThe peer-reviewed sources used — Cocco et al. (2011) and Bianchi et al. (2020) — were conducted mainly in software development or advanced manufacturing settings; their results carry over to non-software companies with caution, as Conforto and colleagues also point out [5]. The Bank of Italy study [7] is based on the 2019 wave of the Invind survey, which covers Italian manufacturing and service firms with at least twenty employees: it measures structured management practices, not project methodologies, and micro-enterprises are excluded by design. No Italian statistical survey tracks the adoption of project management methodologies.
\nChoosing a methodology is not a one-off event: it should be revisited when the project's variables, the team's composition or the organizational context change.
\nWhat is the practical difference between Agile and Scrum?\nAgile is a philosophy with values and principles; Scrum is the most widespread operating framework that implements it, with specific roles and rituals. You can be Agile without using Scrum (for example with Kanban); you cannot \"do Scrum\" without adopting at least its main roles and events [2].
\nDoes Kanban only work in software?\nNo. Kanban applies to any continuous-flow work: handling support tickets, editorial work, sales pipelines, evolutionary maintenance of physical products. The logic of the WIP limit and of visualizing the flow is industry-agnostic [4].
\nCan a company without a dedicated project manager really apply a methodology?\nYes, but the methodology must be chosen in proportion to the resources available. Kanban and a simplified hybrid require the least methodological infrastructure. Full Scrum, without someone who at least informally fills the Scrum Master role, tends to implode in small organizations.
\nWhen should you revisit the methodology during a project?\nWhen one of the three key variables changes: the requirements become much more stable (or much more unstable) than expected at the start, the team's size or commitment changes significantly, or the client's tolerance for change midway shifts.
\nIsn't the hybrid approach just a way to avoid choosing?\nIt can be, but it does not have to be. A designed hybrid is a deliberate choice that combines elements of different methodologies to respond to mixed constraints. The \"default\" hybrid — doing a bit of everything with no criteria — is indeed the worst of all approaches. The difference lies in being aware of the combination chosen and why [6].
\nChoosing a project management methodology for your company comes down to three variables: requirement certainty, team size and commitment, and tolerance for change. Applying the three-step matrix lets you narrow the field from six options to one or two compatible ones, which you then check against the tools available and the team's experience.
\nWaterfall for certain requirements and rigid contractual constraints. Kanban for continuous-flow work with part-time teams. Agile/Scrum for stable, dedicated teams with unstable requirements. Hybrid for settings of medium complexity — which, in companies without a dedicated project manager, are the norm. Lean as a complement to reduce waste in any base methodology.
\nThe principle to keep in mind: the most effective methodology is not the most sophisticated one; it is the one the team actually adopts and that fits the project's real context.
\nProject management methodologies are not competing doctrines; they are working tools with precise areas of application. Waterfall works where requirements are known, Agile where they become clear along the way, Scrum where there is a stable, dedicated team, Kanban where work is continuous and flow-based, Lean where the goal is to reduce waste, and the hybrid when the project faces mixed constraints — a recurring case in smaller companies. A deliberate choice is worth more than blind adherence to a fashionable method.
\nTo build the adjacent skills, it is worth exploring the broader picture of project management for business owners, looking into the project management tools that suit small organizations, and connecting project work to the business owner's weekly planning. For those who handle internal organization, the natural bridge is business systemization, because a well-chosen project methodology works better in a company whose recurring processes are already under control.
\nWhen the chosen sequence needs to be laid out on a timeline, with durations, dependencies and milestones in view, the tool is the Gantt chart.
\nWhen choosing a methodology stops being random and starts being designed, projects stop draining energy invisibly. Deadlines become negotiated, not endured; surprises decrease; the business owner's time is freed up for the decisions that truly move the needle. It is a small step, but in many companies it is worth points of productivity that are currently left on the table.
\n[1] Royce, W. W. (1970). \"Managing the Development of Large Software Systems\", Proceedings of IEEE WESCON, August 1970, 1-9. Copy held by the University of Washington: https://faculty.washington.edu/hazeline/misc/reserve/royce_waterfall.pdf
\n[2] Schwaber, K., & Sutherland, J. (2020). The Scrum Guide — The Definitive Guide to Scrum: The Rules of the Game. scrumguides.org. Available at: https://scrumguides.org/
\n[3] Womack, J. P., & Jones, D. T. (2003). Lean Thinking: Banish Waste and Create Wealth in Your Corporation, 2nd ed., Free Press / Simon & Schuster. ISBN 978-0-7432-4927-0.
\n[4] Cocco, L., Mannaro, K., Concas, G., & Marchesi, M. (2011). \"Simulating Kanban and Scrum vs. Waterfall with System Dynamics\", in Lecture Notes in Business Information Processing, Vol. 77, Springer, pp. 117-131. Available at: https://link.springer.com/chapter/10.1007/978-3-642-20677-1_9
\n[5] Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). \"Can Agile Project Management Be Adopted by Industries Other than Software Development?\", Project Management Journal (Wiley), 45(3), 21-34. DOI: 10.1002/pmj.21410
\n[6] Bianchi, M., Marzi, G., & Guerini, M. (2020). \"Agile, Stage-Gate and their combination: Exploring how they relate to performance in software development\", Journal of Business Research, 110, 538-553. DOI: https://doi.org/10.1016/j.jbusres.2018.05.003
\n[7] Baltrunaite, A., Formai, S., Linarello, A., & Mocetti, S. (2022). \"Ownership, governance, management and firm performance: evidence from Italian firms\", Banca d'Italia, Questioni di Economia e Finanza no. 678, March 2022. Available at: https://www.bancaditalia.it/pubblicazioni/qef/2022-0678/QEF_678_22.pdf
\n[8] ISTAT — Imprese e ICT, Anno 2025, Statistiche report, December 15, 2025. Available at: https://www.istat.it/comunicato-stampa/imprese-e-ict-anno-2025/
","headings":[{"level":2,"text":"Introduction","id":"introduction"},{"level":2,"text":"Choosing a project management methodology: boundaries, benefits and initial criteria","id":"choosing-a-project-management-methodology-boundaries-benefits-and-initial-criteria"},{"level":2,"text":"The three variables that decide which methodology to adopt","id":"the-three-variables-that-decide-which-methodology-to-adopt"},{"level":2,"text":"The six options compared: operating profile and table","id":"the-six-options-compared-operating-profile-and-table"},{"level":3,"text":"Waterfall: projects with clear requirements from the start","id":"waterfall-projects-with-clear-requirements-from-the-start"},{"level":3,"text":"Agile: projects whose requirements become clear along the way","id":"agile-projects-whose-requirements-become-clear-along-the-way"},{"level":3,"text":"Scrum: the most widespread Agile operating framework","id":"scrum-the-most-widespread-agile-operating-framework"},{"level":3,"text":"Kanban: managing the continuous flow of work","id":"kanban-managing-the-continuous-flow-of-work"},{"level":3,"text":"Lean: reducing waste across the entire value stream","id":"lean-reducing-waste-across-the-entire-value-stream"},{"level":3,"text":"Hybrid approach: combining elements of several methodologies","id":"hybrid-approach-combining-elements-of-several-methodologies"},{"level":2,"text":"A three-step selection matrix to find your bearings","id":"a-three-step-selection-matrix-to-find-your-bearings"},{"level":2,"text":"Five common mistakes when adopting a methodology (and how to avoid them)","id":"five-common-mistakes-when-adopting-a-methodology-and-how-to-avoid-them"},{"level":2,"text":"Limits and conditions of applicability","id":"limits-and-conditions-of-applicability"},{"level":2,"text":"FAQ","id":"faq"},{"level":2,"text":"Operational summary","id":"operational-summary"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Sources and references","id":"sources-and-references"}],"tldr":"Should you pick a formal project management methodology, or adapt your approach each time based on the project and the people available? There is no single answer. It depends on three variables that many business owners never pin down: how certain the requirements are at the start of the project, how large the team involved is, and how much tolerance there is for changing course midway.","tldrItems":null}