Vadim GrepanProgram ManagerMiami, FL, United States
Greetings to all!
As current Project management approaches are becoming less purely Agile and more hybrid (see, for example, PMI Pulse of the Profession), what are, from your perspective, the most practical and usable methodologies/approaches for different IT industries and organizational scales?
Are there any reliable statistics available for 2025/2026?
Thank you for such a detailed and thoughtful reply, truly appreciate it!
I fully agree that a methodology itself is not a “silver bullet”; the key question is how applicable it is within a specific project and organizational context. The same framework can produce very different outcomes depending on organizational maturity, governance structure, team experience, internal policies, and many other factors.
In fact, this closely relates to a small research initiative I am currently working on, focused on methodology selection for different project environments. The idea is not that choosing the “right” methodology automatically guarantees project success, execution quality often plays an even bigger role indeed. Rather, the goal is to identify the most suitable approach based on a set of parameters and contextual factors. Narrowing the scope, selecting an appropriate methodology may be viewed as a necessary condition, but not a sufficient one, for project success.
I've started cataloging variables that should be considered when choosing a methodology/framework/approach/whatever... I'll just use "approach" for the rest of this response. I'll share the list in a moment, but first I want to share some things I've learned or realized in the process.
1) Project Managers aren't always in a position to choose their approach, but they may be able to leverage Guided Continuous Improvement and make incremental improvements over time to improve their approach.
2) Choosing an approach is often an attempt to balance uncertainty, coordination, governance, adaptability, predictability, risk, decision latency, and/or learning speed. You should define the problem(s) you want to solve and understand the problems the approach is capable of solving.
3) Some of the variables can lead to the situation where your organization will benefit from using more than one approach based on how the variables present in different projects.
Here's a short list of variable categories to consider. I'm leaving out details for the sake of space.
- The nature of the work - Risk profile - Timing/Urgency - Team capabilities - Working style, or "Way of Working" - Organizational context - Stakeholder landscape - Delivery & release environment - Value realization model - Constraints & non-negotiables - Cultural alignment and readiness
I'm toying with the idea of a decision tree, but there's a strong chance it would become a decision forest. Some of the variables may matter more than others, but that likely varies across organizations, so I haven't attempted to rank or prioritize them.
...
1 reply by Vadim Grepan
May 25, 2026 9:38 PM
Vadim Grepan
...
>>1) Project Managers aren't always in a position to choose their approach, but they may be >> able to leverage Guided Continuous Improvement and make incremental improvements >> over time to improve their approach. That's a fair point, and in practice it's a real constraint. PMs often can't simply choose their approach. Hopefully I can address this in my work, at least to some extent. If a PM frames the selection not as a matter of personal preference or intuition, but as the outcome of a lightweight, formalized analysis, the conversation shifts from "let me suggest something" to "here's what the data suggests."
>>2) Choosing an approach is often an attempt to balance uncertainty, coordination, >>governance, adaptability, predictability, risk, decision latency, and/or learning speed. >>You should define the problem(s) you want to solve and understand the problems >>the approach is capable of solving. That's true again and effectively that's exactly where Multi-Criteria Decision Analysis (MCDA) approach becomes applicable. More specifically, I am considering the use of AHP.
>>3) Some of the variables can lead to the situation where your organization will benefit >>from using more than one approach based on how the variables present in different projects. Just to add to my previous point, the outcome may not necessarily be a single recommendation, but rather a range of suitable approaches.
>>Here's a short list of variable categories to consider. I'm leaving out details for the sake of space. .. To my mind, this is probably the most sensitive and challenging part of the whole idea, as the criteria list cannot be easily formalized. It is necessary to define a set of criteria that is not too extensive while still being comprehensive enough to cover all significant factors. Another challenge is determining their relative weights, where we would likely need to rely on expert judgment.
Hybrid project management is becoming the dominant approach in IT because organizations combine Agile flexibility with traditional governance and planning. For example, startups often use Scrum and Kanban for speed, while large enterprises prefer Hybrid Agile-Waterfall models to balance compliance, budgeting, and fast delivery.
...
1 reply by Vadim Grepan
May 25, 2026 9:55 PM
Vadim Grepan
...
That's exactly what should be included in the list of criteria. I settled on the following criteria such as "Type of Project" (e.g., new business logic implementation vs. UI facelift), "Type of Product" (e.g., mass-market products, innovative products, or customized niche products), "Company Maturity," and several others.
Saving Changes...
Vadim GrepanProgram ManagerMiami, FL, United States
May 19, 2026 10:35 AM
Replying to Aaron Porter
...
I've started cataloging variables that should be considered when choosing a methodology/framework/approach/whatever... I'll just use "approach" for the rest of this response. I'll share the list in a moment, but first I want to share some things I've learned or realized in the process.
1) Project Managers aren't always in a position to choose their approach, but they may be able to leverage Guided Continuous Improvement and make incremental improvements over time to improve their approach.
2) Choosing an approach is often an attempt to balance uncertainty, coordination, governance, adaptability, predictability, risk, decision latency, and/or learning speed. You should define the problem(s) you want to solve and understand the problems the approach is capable of solving.
3) Some of the variables can lead to the situation where your organization will benefit from using more than one approach based on how the variables present in different projects.
Here's a short list of variable categories to consider. I'm leaving out details for the sake of space.
- The nature of the work - Risk profile - Timing/Urgency - Team capabilities - Working style, or "Way of Working" - Organizational context - Stakeholder landscape - Delivery & release environment - Value realization model - Constraints & non-negotiables - Cultural alignment and readiness
I'm toying with the idea of a decision tree, but there's a strong chance it would become a decision forest. Some of the variables may matter more than others, but that likely varies across organizations, so I haven't attempted to rank or prioritize them.
>>1) Project Managers aren't always in a position to choose their approach, but they may be >> able to leverage Guided Continuous Improvement and make incremental improvements >> over time to improve their approach. That's a fair point, and in practice it's a real constraint. PMs often can't simply choose their approach. Hopefully I can address this in my work, at least to some extent. If a PM frames the selection not as a matter of personal preference or intuition, but as the outcome of a lightweight, formalized analysis, the conversation shifts from "let me suggest something" to "here's what the data suggests."
>>2) Choosing an approach is often an attempt to balance uncertainty, coordination, >>governance, adaptability, predictability, risk, decision latency, and/or learning speed. >>You should define the problem(s) you want to solve and understand the problems >>the approach is capable of solving. That's true again and effectively that's exactly where Multi-Criteria Decision Analysis (MCDA) approach becomes applicable. More specifically, I am considering the use of AHP.
>>3) Some of the variables can lead to the situation where your organization will benefit >>from using more than one approach based on how the variables present in different projects. Just to add to my previous point, the outcome may not necessarily be a single recommendation, but rather a range of suitable approaches.
>>Here's a short list of variable categories to consider. I'm leaving out details for the sake of space. .. To my mind, this is probably the most sensitive and challenging part of the whole idea, as the criteria list cannot be easily formalized. It is necessary to define a set of criteria that is not too extensive while still being comprehensive enough to cover all significant factors. Another challenge is determining their relative weights, where we would likely need to rely on expert judgment. Saving Changes...
Vadim GrepanProgram ManagerMiami, FL, United States
May 20, 2026 5:48 AM
Replying to Syed Ashir Riaz
...
Hybrid project management is becoming the dominant approach in IT because organizations combine Agile flexibility with traditional governance and planning. For example, startups often use Scrum and Kanban for speed, while large enterprises prefer Hybrid Agile-Waterfall models to balance compliance, budgeting, and fast delivery.
That's exactly what should be included in the list of criteria. I settled on the following criteria such as "Type of Project" (e.g., new business logic implementation vs. UI facelift), "Type of Product" (e.g., mass-market products, innovative products, or customized niche products), "Company Maturity," and several others. Saving Changes...
The more I read through this discussion, the more I think the interesting question is not simply “Which methodology should we choose?” but rather:
“What execution system does this environment require?”
I think your point about contextual suitability is critical because the same framework can behave very differently depending on factors such as:
organizational maturity
governance structure
dependency density
stakeholder complexity
regulatory constraints
architecture coupling
leadership alignment
planning horizon stability
operational risk tolerance
In practice, most large organizations are already operating with multiple delivery models simultaneously because different work types generate different execution needs.
For example:
infrastructure/platform initiatives often require stronger coordination and governance controls
product engineering may optimize more for learning speed and iterative delivery
enterprise transformation programs usually require a blend of long-range planning and incremental adaptation
That’s why I think the idea of evaluating methodologies through weighted contextual variables is valuable — not because it produces a universally “correct” answer, but because it helps make delivery tradeoffs more explicit and intentional.
One thing I’d add is that methodology selection is probably only one layer of the larger operating model.
In many cases, project outcomes are influenced just as much (or more) by:
decision clarity
escalation paths
cross-functional coordination
incentive alignment
governance fidelity
leadership consistency
execution visibility
Two organizations can both describe themselves as “Agile” or “Hybrid” while operating with completely different decision systems underneath.
So to me, the methodology often becomes less important than whether the surrounding operating environment can support the type of execution behavior the methodology assumes.
That’s where I think this discussion becomes especially interesting.
...
1 reply by Vadim Grepan
Jun 02, 2026 10:27 AM
Vadim Grepan
...
>>The more I read through this discussion, the more I think the interesting question is not >>simply “Which methodology should we choose?” but rather: >> “What execution system does this environment require?”
Well, this is a highly relevant and closely related, but also a much more complex problem. The original question is essentially the reverse one: how does the overall project context influence which methodologies are likely to be the most effective.
>>Two organizations can both describe themselves as “Agile” or “Hybrid” while operating >>with completely different decision systems underneath. That's true, but for this selection process to work, it is essential that each methodology "label" has a clear and commonly understood meaning within the organization itself, i.e. decision-makers know what they can realistically expect when choosing Agile, Kanban, or any other approach.
>>So to me, the methodology often becomes less important than whether the surrounding >> operating environment can support the type of execution behavior the >> methodology assumes. No, methodology is not the primary reason projects succeed or fail, many reports point to the same conclusion. But if we have an opportunity to make the selection process more objective, transparent, and evidence-based, why not take advantage of it?
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
I think one of the strongest trends we are seeing is not the replacement of Agile by another single methodology, but the rise of hybrid and context-driven delivery models.
Different IT environments increasingly require different balances between:
In practice, several patterns are becoming common:
• SaaS / Product environments → Agile, Lean Product and continuous delivery approaches remain dominant. • Large ERP and enterprise transformations → hybrid models combining predictive governance with adaptive delivery are increasingly common. • Regulated industries → stronger governance and compliance layers integrated with Agile execution. • Infrastructure, embedded and hardware-heavy environments → hybrid approaches with stronger planning and systems integration disciplines. • AI-enabled organizations → growing use of adaptive governance and AI-supported coordination models.
I also think one of the biggest shifts since 2024 is that organizations are moving beyond the traditional “Agile vs Waterfall” debate.
The real challenge now is not choosing a methodology in isolation.
It is sustaining alignment, decision quality and organizational coherence across increasingly complex and fast-moving delivery ecosystems.
Regarding statistics, recent PMI research, Pulse of the Profession trends, Standish Group observations and broader industry analysis increasingly point toward hybrid and fit-for-purpose delivery approaches, especially in large-scale and complex transformation environments.
Across many studies, one consistent pattern appears: higher-performing organizations tend to adapt practices to context instead of relying on rigid methodological purity.
In many cases, the differentiator is no longer methodological purity, but the organization’s ability to integrate governance, adaptability, delivery and learning coherently at scale.
...
1 reply by Vadim Grepan
Jun 02, 2026 10:38 AM
Vadim Grepan
...
>>The real challenge now is not choosing a methodology in isolation. >> >>It is sustaining alignment, decision quality and organizational coherence across increasingly >> complex and fast-moving delivery ecosystems.
Effectively listing of possible methodologies is just first round of selection. Here how the whole process might be
STEP1: identify the delivery approaches that could at least theoretically be used in organization, (Waterfall, Scrum, Kanban, SAFe, Hybrid, Lean etc)
STEP2: identify the factors that are believed to have the greatest impact on project success. Factors are derived from organizational experience, lessons learned from previous projects, and expert judgment (project type, delivery constraints, stakeholder involvement, organizational maturity, level of uncertainty, and many others)
STEP3: Each factor is assigned a relative importance, and the candidate approaches are evaluated against those factors using expert judgment and lessons learned from previous projects.
STEP4: Use MCDA technic (AHP my preference) that aggregates these inputs and produces a ranked list of alternatives, while also checking whether the underlying assessments are logically consistent.
The result is not a mandatory answer, but a transparent and evidence-based recommendation. It provides both a decision-support mechanism for PMs and a clear rationale that can be presented to management when explaining why a particular approach is being recommended.
Saving Changes...
Vadim GrepanProgram ManagerMiami, FL, United States
The more I read through this discussion, the more I think the interesting question is not simply “Which methodology should we choose?” but rather:
“What execution system does this environment require?”
I think your point about contextual suitability is critical because the same framework can behave very differently depending on factors such as:
organizational maturity
governance structure
dependency density
stakeholder complexity
regulatory constraints
architecture coupling
leadership alignment
planning horizon stability
operational risk tolerance
In practice, most large organizations are already operating with multiple delivery models simultaneously because different work types generate different execution needs.
For example:
infrastructure/platform initiatives often require stronger coordination and governance controls
product engineering may optimize more for learning speed and iterative delivery
enterprise transformation programs usually require a blend of long-range planning and incremental adaptation
That’s why I think the idea of evaluating methodologies through weighted contextual variables is valuable — not because it produces a universally “correct” answer, but because it helps make delivery tradeoffs more explicit and intentional.
One thing I’d add is that methodology selection is probably only one layer of the larger operating model.
In many cases, project outcomes are influenced just as much (or more) by:
decision clarity
escalation paths
cross-functional coordination
incentive alignment
governance fidelity
leadership consistency
execution visibility
Two organizations can both describe themselves as “Agile” or “Hybrid” while operating with completely different decision systems underneath.
So to me, the methodology often becomes less important than whether the surrounding operating environment can support the type of execution behavior the methodology assumes.
That’s where I think this discussion becomes especially interesting.
>>The more I read through this discussion, the more I think the interesting question is not >>simply “Which methodology should we choose?” but rather: >> “What execution system does this environment require?”
Well, this is a highly relevant and closely related, but also a much more complex problem. The original question is essentially the reverse one: how does the overall project context influence which methodologies are likely to be the most effective.
>>Two organizations can both describe themselves as “Agile” or “Hybrid” while operating >>with completely different decision systems underneath. That's true, but for this selection process to work, it is essential that each methodology "label" has a clear and commonly understood meaning within the organization itself, i.e. decision-makers know what they can realistically expect when choosing Agile, Kanban, or any other approach.
>>So to me, the methodology often becomes less important than whether the surrounding >> operating environment can support the type of execution behavior the >> methodology assumes. No, methodology is not the primary reason projects succeed or fail, many reports point to the same conclusion. But if we have an opportunity to make the selection process more objective, transparent, and evidence-based, why not take advantage of it? Saving Changes...
Vadim GrepanProgram ManagerMiami, FL, United States
May 26, 2026 4:26 AM
Replying to Luis Branco
...
I think one of the strongest trends we are seeing is not the replacement of Agile by another single methodology, but the rise of hybrid and context-driven delivery models.
Different IT environments increasingly require different balances between:
In practice, several patterns are becoming common:
• SaaS / Product environments → Agile, Lean Product and continuous delivery approaches remain dominant. • Large ERP and enterprise transformations → hybrid models combining predictive governance with adaptive delivery are increasingly common. • Regulated industries → stronger governance and compliance layers integrated with Agile execution. • Infrastructure, embedded and hardware-heavy environments → hybrid approaches with stronger planning and systems integration disciplines. • AI-enabled organizations → growing use of adaptive governance and AI-supported coordination models.
I also think one of the biggest shifts since 2024 is that organizations are moving beyond the traditional “Agile vs Waterfall” debate.
The real challenge now is not choosing a methodology in isolation.
It is sustaining alignment, decision quality and organizational coherence across increasingly complex and fast-moving delivery ecosystems.
Regarding statistics, recent PMI research, Pulse of the Profession trends, Standish Group observations and broader industry analysis increasingly point toward hybrid and fit-for-purpose delivery approaches, especially in large-scale and complex transformation environments.
Across many studies, one consistent pattern appears: higher-performing organizations tend to adapt practices to context instead of relying on rigid methodological purity.
In many cases, the differentiator is no longer methodological purity, but the organization’s ability to integrate governance, adaptability, delivery and learning coherently at scale.
>>The real challenge now is not choosing a methodology in isolation. >> >>It is sustaining alignment, decision quality and organizational coherence across increasingly >> complex and fast-moving delivery ecosystems.
Effectively listing of possible methodologies is just first round of selection. Here how the whole process might be
STEP1: identify the delivery approaches that could at least theoretically be used in organization, (Waterfall, Scrum, Kanban, SAFe, Hybrid, Lean etc)
STEP2: identify the factors that are believed to have the greatest impact on project success. Factors are derived from organizational experience, lessons learned from previous projects, and expert judgment (project type, delivery constraints, stakeholder involvement, organizational maturity, level of uncertainty, and many others)
STEP3: Each factor is assigned a relative importance, and the candidate approaches are evaluated against those factors using expert judgment and lessons learned from previous projects.
STEP4: Use MCDA technic (AHP my preference) that aggregates these inputs and produces a ranked list of alternatives, while also checking whether the underlying assessments are logically consistent.
The result is not a mandatory answer, but a transparent and evidence-based recommendation. It provides both a decision-support mechanism for PMs and a clear rationale that can be presented to management when explaining why a particular approach is being recommended. Saving Changes...