Challenges and Opportunities of Hybrid

Projects in Complex Environments

Sebastian L. Sohn Singapore Chapter +1 - February 5, 2021
Sebastian Sohn holds both Project Management Professional (PMP)® and PMI Agile Certified Practitioner (PMI-
ACP)® certifications in addition to being a Professional Scrum Master I (PSM-I). He also holds a master’s degree in
management.

SHARE
Topics: Agile, Knowledge Shelf
Abstract
The use of hybrid project approaches comes with a number of challenges and opportunities, in
particular in complex environments. One of the benefits is that hybrid projects help to leverage the
advantages of agile approaches within projects that need to be managed in a more traditional way
(e.g., for reasons such as complexity or organizational requirements). Combining agile, iterative,
incremental, and traditional project management methods may have some obstacles though. This
article gives guidance to overcoming these challenges and provides examples of practical methods
for approach selection, status reporting, and risk and assumption management.

Introduction
The Agile Practice Guide (PMI, 2017b) defines hybrid projects (referred to as hybrid life cycles) as a
combination of elements from different project approaches. This way, agile elements and traditional
project management can be used side by side in the same project. Both approaches can be
balanced following the needs of a project and the maturity of an organization.

According to PMI’s latest Pulse of the Profession® 2020 in-depth report, “Research Highlights by
Region and Industry” (PMI, 2020b), agile has become an established approach to projects in various
industries—including financial services (FS), healthcare, IT, manufacturing, and telecom as agile
frontrunners—with adoption rates between 23–31%.

The value and aim of “organizational agility” can be even more common in some industries, with an
adoption rate of up to 43% in the IT sector.

The report shows that hybrid project approaches, however, tend to be less popular than agile
projects in industries such as FS, government, IT, and telecom. Only in industries with a generally
low adoption rate of agile approaches, such as manufacturing and construction, do hybrid projects
tend to be more common than agile projects, although at a generally lower level. Aggregated across
all industries, the adoption of hybrid approaches lags behind that of agile projects (see Figure 1).
 Figure 1: Agile and hybrid adoption rates per industry
according to the PMI Pulse of the Profession® 2020 (PMI, 2020b)

The data do not provide further insights into the underlying reasons for this gap. However, we can
observe that the industries with the largest gaps (except the government sector) also show the
highest rates of adoption of agile approaches, as well as an above-average use of hybrid
approaches.

This may suggest that it is possibly the nature of some of their projects that keeps these
organizations from using hybrid or agile approaches in all of them. The size of project teams, cross-
divisional subject matters, overall complexity, regulatory and legal environments, and organizational
requirements are examples of factors that make traditional project management approaches appear
more suitable.

However, choosing from agile versus traditional project approaches does not have to be a “black-or-
white decision.” Hybrid approaches pose an interesting alternative in many cases. They can help
realize the benefits and set off the disadvantages of both agile and traditional approaches within the
same project.

The Challenges of Complexity in Projects

In many organizations, the default approach to tackling complex subject matter is often a traditional
project management setup. This approach selection may be driven by organizational, legal, and
regulatory requirements as well as complex environments.

Sources of Complexity
In this section, we are looking at some of the internal and external drivers of complexity that may be
typical and relevant in a broad range of projects. (This is a non-exhaustive list.)

• Internal Drivers

The subject matter and technical environment of a project are obviously two of the main drivers of
complexity.

Although it is not a static correlation, the complexity of managing projects can be somewhat
proportionate to an organization’s size. However, smaller projects can also come with their fair share
of complexity, although this is often from other sources.

Large and global projects often involve several parts of an organization, e.g., different subsidiaries,
divisions, countries, legal entities, joint ventures, etc.

While a joint project is usually set up to generate benefits (or avoid pitfalls) for all entities involved,
the interests and perspectives of stakeholders may differ.

This kind of environment can be a challenge in managing projects within a single organization.
However, it can increase the complexity of projects across different entities even more.

• External Drivers

Depending on the kind of project, external stakeholders can also increase the complexity and
interdependencies that a project must address.

For instance, nongovernmental organizations (NGOs) and the broader public could be—or could
demand to be—involved in certain projects. Governments, politicians, and social and mass media
may also influence the goals and progress of projects.

One of the most common challenges in projects of all sizes is the regulatory environment and the
expectation of regulators and supervisors as indirect, external stakeholders. It goes without saying
that these are highly important aspects to be considered as properly managed companies aim to
comply with all regulatory requirements.

In practice, however, legal and regulatory requirements may be hard to understand, tending to be at
a high level and sometimes even requiring further interpretation when applied to operational
procedures and matters. At the same time, time lines tend to be tight, with high stakes, as
noncompliance is usually not a legitimate option.

Thus, the legal and regulatory environment (including supervision and internal organization control
frameworks) is often one of the main sources of complexity (see Figure 2), in particular in heavily
regulated industries such as financial services.
 Figure 2: Illustration of project complexity drivers

Complexity versus Agility

Agile approaches have gained increasing popularity over the past decades, and 30% of
organizations have moved toward a more agile way of working, with 22% applying agile in their
projects (PMI, 2020a).

Agile projects are known for a number of advantages which include, but are not limited to, their fast
delivery of incrementally created results, high responsiveness to change, and ongoing feedback
processing (Beck et al., 2001).

As the PMI statistics indicate, this is recognized and adopted by organizations to a certain extent. On
the other hand, a significant share of responses state that traditional project management
approaches remain the project management standard used for a majority of projects.

Although the statistics do not show the details, it seems reasonable to assume that project
complexity is one of the main drivers for using a predictive approach.

Such an environment typically requires a high degree of planning as well as thorough management
of interdependencies and risks.

While these are obvious advantages of predictive project management, focusing exclusively on
traditional approaches may cause organizations to miss out on the opportunities and benefits that
agile, incremental, or iterative methods can create.

The Case for Hybrid Projects

The application of a hybrid approach can resolve the trade-off of an “agile versus traditional”
decision when selecting a project methodology. In situations where nontraditional methods promise
considerable benefits while the project itself cannot be fully agile, a hybrid approach can unlock the
opportunity to combine the advantages.

The Agile Practice Guide (PMI, 2017b, p. 17) defines four generic project types, the so-called life
cycles:
 • Predictive (the traditional project management approach): Fixed requirements, single
delivery, and a focus on planning;
• Iterative: Dynamic requirements, with repeating activities to create a single deliverable;
• Incremental: Dynamic requirements and fast delivery of small deliverables, so-called
increments;
• Agile: Dynamic requirements, with repeating activities for frequent small deliverables, for
which feedback is sought for subsequent enhancements.

Classified with the dimensions of “responsiveness to change” and “amount of planning,” these
approaches could be illustrated as shown in Figure 3.

Figure 3: Different approaches can be used for different phases or workstreams of a project

In a hybrid project, the most appropriate approach can be chosen for either the project as a whole or
separately for each phase or work package.

This can include, for instance, combining the flexibility and responsiveness of incremental and agile
approaches in certain work packages with a traditional project management approach overall.

Thus, a hybrid approach can help meet the organizational or regulatory requirements for projects in
areas such as planning, documentation, or risk management. At the same time, the project remains
open to feedback in its day-to-day work and is able to quickly respond to changes in requirements or
assumptions. Tools, techniques, roles, and practices of both spheres can be leveraged.

PMI’s 2017 Pulse of the Profession stated that hybrid projects in both high- and low-agility
environments tend to be more successful than agile or predictive (traditional) approaches (PMI,
2017c) (see Figure 4).
 Figure 4: Percentage of projects meeting original goals and business intent by the most
common approach to projects within the organization (PMI, 2017c)

While these advantages are compelling in theory, hybrid projects come with some constraints,
requirements, obstacles, and challenges in practice.

Application of Hybrid Approaches

To set up a hybrid project, a number of strategic, operational, and structural considerations are
required. These include, but are not limited to:

1. Selecting the right approach for different parts of a project,

2. Project management and reporting,
3. Assumptions management, and
4. Risk management.

1. Approach Selection
For different parts of a hybrid project, different approaches (agile, incremental, iterative, or
predictive) can be applied.

The selected approach should be the best fit for the type of work in a workstream or project
phase. There should be clear selection criteria that are assessed for each part of the project.

Criteria could be the required responsiveness to change and the need for planning. In addition, legal
requirements and expectations of internal and external stakeholders may impact, and even limit, the
choice of approaches that could be used.

To use different approaches within a project or an organization, it is necessary to assign them clearly
to parts of a project and communicate the assignment and its consequences accordingly.
Example
Figure 5 illustrates a way to select approaches based on the expected frequency and degree of
changes, and the project’s influence on the content of these changes.

Figure 5: Illustrative criteria for the project approach selection

For instance, if a legal requirement changes, a project needs to address this change without being
able to influence its content. A project may choose to manage requirements with an iterative
approach in connection with an assumptions management process, thus ensuring that changes are
properly understood and implemented across the whole project.

On the other hand, the design and development of a piece of software may be subject to changes
throughout a project, e.g., if spikes or user feedback suggest changes to the design of features. The
expected number of changes is high, and so is the project's influence on the way it responds to
these changes. Subject to other technical and organizational requirements or constraints, developing
this software with an agile approach can be a worthwhile consideration.

The implementation and deployment of software normally need to comply with organizational
requirements that are often outside the power of a project, e.g., an organization’s release calendar
and its playbook for deploying software. This could be addressed by managing the implementation-
and go-live-related tasks with a traditional management approach (“predictive life cycle”).

The approach to testing may involve further differentiation with respect to the types and phases of
testing activities. User acceptance tests and defect fixing, for instance, could be integrated with the
agile development process or addressed in iterative ways. However, requirements for integration
testing may share more similarities with those for implementation and deployment. Following the
approach selected for the implementation may be more appropriate for that type of testing.

2. Project Management and Reporting

Hybrid projects require the project manager and the project management office (PMO) (if existent) to
bridge the gaps between the different approaches in areas such as planning, controlling, and
reporting (Conforto et al., 2014).

Managing a hybrid project, therefore, requires project-individual adjustments to the management

styles and techniques, project controlling and status measurement, and reporting. As an overarching
goal, a hybrid project needs to be manageable while its progress needs to be communicable,
regardless of the underlying mix of approaches.

• Controlling and Reporting

This includes identifying the right success measures and key performance indicators (KPIs) for each
part of a project. It also concerns the staffing and coaching of resources and determining the right
amount of planning.

A point to tackle is the difference in the definitions of “progress” and “completion.” For instance, if a
traditional project reports 50% completion, it means that 50% of the planned work has been
completed. Measuring completion in agile projects, on the other hand, typically focuses on
completed deliverables only.

In a traditional project, 50% progress could be reported based on the conducted work without having
completed any deliverable yet. An agile project would report 50% only if half of the deliverables are
completed. It would not report the amount of work done for incomplete deliverables as a measure of
progress.

This example illustrates different controlling and reporting methods in agile and traditional
approaches, and emphasizes the importance of a project-wide definition of success measures,
status reporting standards, and their consistent application.

• Collaboration and Communication

In a project that applies different approaches, the methodological choices and their rationale need to
be clearly communicated to the team members and stakeholders. It may also require additional
coaching to increase the understanding of, and familiarity with, these approaches.

In software development, for instance, agile could be the right choice if the processing of feedback
and implementation of changes are important. On the other hand, the implementation and
deployment in an organization’s IT architecture could follow traditional approaches if a high degree
of planning and management of interdependencies are the key concerns.

Irrespective of the approach chosen, the project’s different workstreams need to be able to interact
with each other: In a phased structure (e.g., design, development, testing, or deployment
workstreams), a functional project organization (e.g., sales, accounting, or controlling), or other
organizational structures, pieces of work are regularly passed from one workstream to another.

If the workstreams choose different approaches, appropriate handshakes and collaboration models
need to be set up to ensure efficient collaboration. They need to clarify the communication channels
and frequency, the “definition of done,” documentation requirements/expectations, feedback loops,
and other collaboration aspects.

There should be clear guidance, for instance, if a team that applies a traditional approach (waterfall)
wishes to align its technical design with an agile workstream that is working with backlogs and
storyboards.

• Stakeholder and Team Commitment

Working with a combination of different approaches requires a certain commitment from teams and
stakeholders. They should be willing to adapt to different approaches (to the extent necessary), in
particular, if team members work across different workstreams.

During approach selection and staffing, a project manager needs to consider the technical and
methodological skills of the team.
Functional organizations and work packages in traditional projects may require a high level of
specialization while members of agile teams are required to have a much broader, more generalistic,
and product-/customer-centric perspective (Groll, 2017).

Depending on the type and culture of an organization, the availability of such resources may pose a
challenge.

3. Requirements and Assumptions Management

Requirements in projects may be subject to changes when market conditions, strategies, the legal
environment, or other internal and external factors are fluctuating.

While changes in traditional projects initiate change control/management processes and require
comprehensive replanning, agile and hybrid projects can tackle changes quicker.

A product owner or PMO (with subject matter expertise) can manage assumptions as part of the
requirements catalog or project backlog. They can then process and communicate changes to all
affected workstreams and help facilitate their interpretation and implementation.

Requirements and assumptions management also requires prioritization of requirements. This can
be based on the three dimensions, for instance:

• The criticality of a requirement with respect to the project goals (in some agile approaches,
this is referred to as “maximizing the value”);
• The complexity of a requirement (the dimension “risk” can also be used instead); and
• The clarity and stability of a requirement (which reflects the expected amount and extent of
changes to a requirement throughout a project).

A sample classification of requirements is illustrated in Figure 6:

Figure 6: Illustrative classification of requirements by criticality, complexity, and

stability/clarity

Based on such a classification, the list of requirements can be prioritized. It may start with “high-
complexity—high-criticality items” with a clear and stable definition (represented by the green points
in the top-right quadrant), followed by clearly defined high-criticality—low-complexity requirements
(green items in the top-left quadrant).

For all partially or totally unclear items, a “latest starting date” can be estimated, based on its
expected implementation time. This “latest starting date” poses the deadline for their respective
clarification processes. If clarification cannot be obtained by that time, an iterative implementation of
that requirement should be considered, i.e., an assumption-based design and development that is
refined when more information becomes available.

Requirements and assumptions management is an ongoing process and subject to “progressive

elaboration” (PMI, 2017a) rather than a one-off exercise.

4. Risk Management
Every project, regardless of its approach, is exposed to risks. These include internal and external
dependencies and risks, for example:

• Dependencies on vendors, divisions, other projects, IT implications, regulatory requirements;

• Resource availability and commitment;
• Dependency on key resources;
• Disasters;
• Data privacy and compliance risks; and
• Other risks.

In addition to project risk management, the management of assumptions and related risks is
necessary if requirements are not yet fully clear (see previous section for more details).

The ways the different approaches deal with these risks are fundamentally different. Therefore, the
project manager or PMO should consistently assess, monitor, and manage these risks and
assumptions across the different parts and approaches of a project.

Conclusion and Reflection

According to PMI’s latest Pulse of the Profession report (PMI, 2020a), the adoption of hybrid project
approaches lags behind traditional and agile approaches. This holds true even for organizations that
describe themselves as being one with “high organizational agility.”

However, a hybrid project setup has the potential to leverage the advantages of both worlds. In this
article, we have discussed a few methods and examples of how this can be achieved in practice.

Hybrid projects come with a few challenges and disadvantages though. The use of different methods
and project approaches within the same project can be confusing for stakeholders and team
members. The approach chosen for certain workstreams or technical areas might eventually turn out
to be wrong, which will require corrective action during a project. Technical and organizational
necessities, as well as staffing and political considerations, could limit the extent to which hybrid
development approaches can be leveraged (this list of potential obstacles is, by far, not exhaustive).

So, is “hybrid” the ultimate answer? At the very least, it is a worthwhile consideration for cases
where organizations with a considerable affinity for agile need to manage medium- to high-
complexity projects that require traditional project management to a certain extent (Griffiths, 2020). It
can be challenging for stakeholders, project managers, and team members to deal with different
approaches within the project and the organization. However, it has the potential to yield great
returns in terms of effectiveness, efficiency, quality, and stakeholder satisfaction, as PMI’s
2017 Pulse of the Profession results proved (PMI, 2017a).

References

1. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor,
 S., Schwaber, K., Sutherland, J., Thomas, D. (2001). Manifesto for agile software
development. AgileManifesto.org.
2. Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & Magnanini de Almeida, L.
F. (2014). Can agile project management be adopted by industries other than software
development? Project Management Journal, 45(3), 21–34.
3. Griffiths, M. (2020). Playing in the gray of hybrid. ProjectManagement.com.
4. Groll, J. (2017). From I-shaped to T-shaped – Why DevOps professionals need to be
multi-skilled. DevOpsInstitute.com.
5. Project Management Institute (PMI). (2017a). A guide to the project management body of
knowledge (PMBOK® guide) – Sixth edition. Author.
6. Project Management Institute (PMI). (2017b). Agile practice guide. Author.
7. Project Management Institute (PMI). (2017c). Pulse of the Profession® in-depth
report: Achieving greater agility. Author.
8. Project Management Institute. (2020a). Pulse of the Profession® 2020. Author.
9. Project Management Institute. (2020b). Pulse of the Profession® 2020: Research
highlights by region and industry. Author.

Suggested Reading

1. Fridman, A. (2016). The massive downside of agile software development. Inc.com.

2. Poliacik, I. (2012). Objective comparison of project complexity and performance of project
managers in the banking environment. ProjectManagement.com.
3. Sullivan, K. (2020). Scrum framework team roles and transitioning to an agile
approach. ProjectManagement.com.
4. Stellman, A., & Greene, J. (2017). Head first agile, (1st ed.). O’Reilly Media Inc.

About the Author

Sebastian Sohn holds both Project Management Professional (PMP)® and PMI Agile Certified
Practitioner (PMI-ACP)® certifications in addition to being a Professional Scrum Master I (PSM-I). He
also holds a master’s degree in management.

As a managing consultant, Mr. Sohn advises clients, mainly from the financial services industry, in
strategic, regulatory, and IT-related areas. During his more than 15 years of professional experience,
he has worked on projects for more than 30 clients in Europe and Asia, where he applied agile,
hybrid, and traditional project approaches.