Hybrid project management: When Agile and PMI must coexist

In industrial Engineering, Procurement, and Construction (EPC) projects, management rarely fails due to lack of effort; it fails because of the nature and complexity of the work. Critical procurement and construction require sequence, permits, inspections, traceability, and contracts. Engineering, on the other hand—especially in early stages—coexists with uncertainty: interferences, operational constraints, incomplete data, environmental regulations, and evolving client decisions.

Trying to manage an EPC project with a single management style often leads to two scenarios: either you become so rigid that decisions are delayed and the sequence (engineering-procurement-construction) is stalled, or you become so flexible that you lose control, rework increases, and claims arise. The technical answer is not to choose a side or style but to design a system that knows where you need certainty and where you need learning. That system is called hybrid project management. Learn more below.

The real problem in EPC

In EPC, the dependency chain punishes approach errors. If engineering is frozen too early to meet a plan, packages are released with hidden uncertainty, and costs appear later during construction. If engineering releases nothing until everything is perfect, procurement and construction wait, and the project loses momentum. In both cases, the typical result is the same: late changes, rework, more hours, and a schedule that no longer represents reality.

What the industry requires is an operational balance: maintain contractual control and governance while creating a mechanism to validate uncertainty early. And that is achieved with structure.

What is hybrid project management?

Hybrid project management is an approach to designing and governing a project by intentionally combining two management logics: predictive (plan–control–compliance) and adaptive (iteration–feedback–learning). It is not about doing a bit of everything; it consists of deciding which parts of the project must be stable and controlled and which parts should evolve with early validations, maintaining coherence among principles, method/methodology, frameworks, and practices (Vila Grau & Capuz Rizo, 2022).

To understand it clearly, it’s helpful to see it by levels:

1. Approach (the why and how governance is done)

This is the highest layer; it defines governance principles, priorities, and decision logic. In hybrid project management, the approach is summarized as: predictive, where the cost of change is high and interfaces are rigid (contracts, critical procurements, construction, and assembly), and adaptive, where uncertainty is high and early validation reduces risk (engineering by packages, integration, automation, system commissioning, and progressive documentation). This segmentation by nature of work is the essence of hybrid: Agile or PMI is not applied to the entire project but where they add value.

2. Method/Methodology (the working system)

This defines the operational way to implement the approach. It specifies the full system managing the project or a significant part of it: rules, procedures, management deliverables, decision roles, governance, change control, and coordination mechanisms. In EPC, a hybrid method often combines traditional components (phases, milestones, baselines, and integrated control) with adaptive components to design, validate, and release deliverables incrementally. For example, SixSigma.us describes the hybrid as a strategic combination between traditional waterfall models and iterative agile methodologies, based on careful selection and integration to preserve structure and adapt to context (SixSigma.us, 2024).

3. Project Management Frameworks (how work is organized)

A framework does not always cover the entire management system but provides a reusable structure to organize execution in a work type. Simply put: if methodology defines the entire system, the framework defines how you operate daily with specific rules and routines organizing the work. For example, Scrum organizes work by iterations and defined roles; Kanban organizes work by flow, WIP limits, and explicit policies; and in construction, frameworks like Last Planner organize collaborative planning and constraint management.

In a hybrid, frameworks are selected by domain: Scrum is not imposed on construction, nor is early engineering managed solely by Gantt; the framework that best controls risk in that project segment is chosen.

4. Practices and Techniques (what the team does and delivers)

Practices are concrete techniques that make the system work: acceptance criteria, flow boards, constraint management on site, risk logs, WBS to break down deliverables, early review sessions, configuration control, and release cycles. In hybrid project management, these practices must align with the approach; otherwise, the iceberg problem occurs: copying visible rituals but not the foundation (values, criteria, authority to decide), and the system does not sustain results (Vila Grau & Capuz Rizo, 2022).

In conclusion, the approach defines governance; the method/methodology defines the complete management system; frameworks define how work is executed in each domain; and practices are the concrete actions that make everything work.

Difference between a true hybrid and a makeshift mix

A well-designed hybrid project is recognized by explicit and verifiable rules: what “done” means for each deliverable (Definition of Done, DoD), who accepts it and with what evidence, how prioritization is done (value, risk, constraints), how change is managed without losing contractual traceability, and how progress is reported (accepted deliverables + milestone control). Without these rules, there is no hybrid management: there is improvisation with labels. In EPC, this is costly because it generates rework, blockages, late change orders, and schedules that no longer represent reality.

Foundations of the predictive approach

The predictive approach, common in PMI environments, relies on a central principle: define a baseline and manage the project by measuring reality against the plan. In EPC, this is not bureaucracy; it is contractual survival and multi-actor coordination.

Its foundations, applied on the ground, are the baseline (scope, time, cost), formal change management to avoid silent changes that explode later as claims, risk management to anticipate technical and commercial impacts. Governance by milestones and phases with approval criteria, and discipline in procurement and quality to ensure purchase, inspection, documentation, and compliance.

In other words: PMI provides the project’s nervous system. Without this structure, EPC projects with high exposure become reactive and fragile.

Foundations of the Agile approach

Agile in industry is not doing things fast or working without a plan. It is managing uncertain work with a system that transforms uncertainty into decisions through short cycles, verifiable deliverables, and frequent feedback.

Operational foundations of the agile approach applied to EPC include verifiable incremental delivery (small but usable advances), prioritization by value and risk (first what unlocks procurement/construction or closes critical interfaces), early feedback and partial acceptance (early review prevents late changes), flow transparency (visible work and blockages), limits on work in progress (less multitasking, more real closure), and an objective definition of done to release quality deliverables.

In EPC, agile is especially valuable during engineering and integration because it allows releasing packages ready to buy/install without waiting for 100% completion, maintaining strict criteria.

Where did Agile come from, and why was it needed?

Agile was born as a reaction to environments where detailed upfront planning is insufficient because requirements change or are discovered along the way. Its formal milestone is the Agile Manifesto (2001), born in software, where changes are frequent and iteration cost is relatively low (Beck et al., 2001).

What is significant for industry is not copying software but understanding the why: when knowledge builds progressively, managing with learning cycles is advantageous.

NASA documents this well with a case that mirrors EPC: achieving agile engineering within traditional governance (their “waterfall world”). Their key was applying process rigor when it matters and building a definition of done that includes artifacts and traceability without unnecessary bureaucracy. This is accurately the EPC conversation: comply with standards/contracts but without freezing technical learning.

Fit for Purpose: The hybrid’s golden rule

PMI sums up the hybrid rationale well: there is no one-size-fits-all recipe for projects. The discipline is moving toward a fit-for-purpose approach—adapting the method to the context, not vice versa. On the PMI blog, Conforto (2024) describes this paradigm shift as prioritizing fit for purpose rather than imposing a single framework across the organization.

He adds an important fact: adoption of hybrid projects grew 57.5% from 2020 to 2023. Hybrid projects grow because real projects combine rigid components (contracts, construction, QA/QC) with dynamic components (engineering and integration). Fit for purpose is the guiding principle for Agile and PMI to coexist without friction, adopting specific and customized solutions (Conforto, 2024).

Common mistakes mixing Agile and PMI (and how to avoid them)

1. Agility without contractual discipline

 This occurs when trying to be agile without respecting EPC’s contractual weight. Changes are managed informally: decisions in meetings without minutes, approvals via chat, uncontrolled review submissions, or agreements never formalized as changes with impact. Initially efficient, costs emerge later as rework or wrong purchases.

When defending time and cost impacts, traceability is insufficient. The fix is clarity: separate operational from contractual changes, define approval flows by criticality, keep version control (“issued for…”), and require minimal evidence to release deliverables affecting procurement and construction.

2. Cycles without DoD (Definition of Done)

The problem is not working in cycles but doing so without an objective definition of done. In EPC, DoD means the deliverable is truly ready to enable the next step without risk. Without DoD, false progress appears: reports show deliverables at 90% or under review, but almost nothing is approved or usable. Incomplete work inventory accumulates: open notes, unresolved interferences, inconsistent materials lists, pending QA/client criteria.

The project pays with RFIs, stoppages, rework, and late changes. The solution is tying each cycle to accepted and versioned deliverables with acceptance criteria by document type (IFC drawing, datasheet, MTO, procedure) and a simple rule: if it doesn’t meet DoD, don’t release to procurement or construction.

3. Ceremonies without decisions

Meetings with agile names are copied but lack authority to prioritize, accept deliverables, or remove blockers. Meetings become repetitive status updates; blockers reappear, reviews end with “we checked and will inform you,” and the team concludes Agile is just more meetings. In a healthy hybrid, each ceremony has purpose and output: reviews close approvals or rejections with criteria; daily stand-ups raise real impediments; retrospectives generate concrete actions that improve the system. Without decisions, there’s no agility—only fatigue.

4. Excessive multitasking: too much open work, little closure

Happens when projects try to advance everywhere at once: engineering opens too many packages simultaneously, procurement issues purchase orders prematurely, documentation saturates, and construction starts fronts with unresolved constraints. The system congests, cycle times rise, quality falls because work gets stuck in multiple trays. The fix is treating it as a flow problem: prioritize by value and risk, limit work in progress at bottlenecks, define entry criteria to start activities. On site, commit only to executable work; in engineering, finish and release before opening more fronts.

5. Freezing too early

 To meet plans, engineering is frozen before enough information is available. On paper this seems like control, but uncertainty shifts to the most expensive place: the field. When IFCs are issued with known clashes, equipment is purchased without validated interfaces, or assembly sequence is fixed on immature info, site reality breaks the plan and triggers late changes.

A professional hybrid avoids premature freezing, works by packages and maturity criteria, not arbitrary dates. It defines technical gates to release critical purchases and issues for construction, validates uncertainty early (walkdowns, interdisciplinary coordination, interface closure), and aligns the master schedule with real maturity so the plan represents the project, not wishful thinking.

The following video shows the differences between these two approaches to project management. Source: KodeKloud.

Conclusions

The practical future of EPC is neither purely agile nor purely predictive: it is hybrid by design. Hybrid project management maintains control and governance where the cost of change is high and applies adaptive approaches where uncertainty must be reduced with incremental deliveries, real acceptance, and visible flow. When rigorously implemented, PMI no longer feels like bureaucracy, and Agile no longer sounds like rhetoric: both become a coherent system that improves reliability, reduces rework, and protects schedule and cost commitments.

Here’s a closing question for honest technical reflection: Is your project managed by habit or by purpose? Specifically, do you clearly define where you need predictive control and where you need short cycles to reduce uncertainty before work reaches the field? That answer often marks the difference between a hybrid that organizes the project…and one that just changes the names of meetings.

References

1. Conforto, E. (2024). The Hybrid Era: Project management embraces the fit-for-purpose approach. Project Management Institute (PMI). The PMI Blog. https://www.pmi.org/blog/project-management-embraces-the-fit-for-purpose-approach
2. KodeKloud (2025). DevOps vs. Agile: Are they really different? https://youtube.com/shorts/7vBPfGIg2EY?si=xJezSwuro04F6g6b
3. NASA (2024). Agile Software Engineering in NASA’s Waterfall World.
4. SixSigma.us. (2024). Hybrid project management: The ultimate guide to blending Agile and Waterfall methodologies. SixSigma.us. https://www.6sigma.us/project-management/hybrid-project-management/
5. Vila Grau, J. L., & Capuz Rizo, S. (2022, July 5–8). Hybrid project management according to PMBOK and PRINCE2 models. 26th International Congress on Project Management and Engineering, Terrassa, Spain.