OPINION: Utilization of Hybrid Project Management Methodology in Infrastructure Projects- Part 2: Theoretical Concept Evaluation

INTRODUCTION

In today’s fast paced constantly changing environment, some of our infrastructure projects are being delivered by more progressive contractual models such as Progressive P3, Alliance, Design-Build-Finance-Operation-Maintenance (DBFOM), DBOM, and other similar collaborative models, to distribute the risk and guarantee the success of project.

In these projects, the functional requirements or service levels in addition to the overall budget and timelines indicated in the initial feasibility studies or business cases are the overall project limits. However, the solution is not provided, neither the detailed scope. Instead, teams are working in big consortiums, and collaborating with project sponsors, owners, and stakeholders to define their own scope, and ultimately budget and schedule. The explained concept is closer to what is being considered in agile methodology.

The fixed constraints vs planned estimates in agile and waterfall methodologies have been demonstrated in Exhibit 1.

This may change the best applicable project management methodology for such projects. Therefore, using some of agile principles, tools, and techniques may help to facilitate adjustment with this fundamental change.

Considering all limitations of agile methodology application in infrastructure projects, also insufficiencies of waterfall methodology, Hybrid models might be a good solution to manage these types of projects.

DEFINITIONS OF AGILE AND WATERFALL PROJECT MANAGEMENT METHODOLOGIES

The Waterfall Project Management approach is a sequential, linear process of several discrete phases. No phase begins until the prior phase is complete. Waterfall management does not allow to return to a previous phase. This approach focuses on planning and analyzing the projected future in-depth for anticipated risks and relies on an early phase planning and a detailed breakup of milestones and tasks for the entire development process.

On the other hand, Agile methodology caters to focusing on adapting quick scope changes and project reality. As with the waterfall model, with this methodology you still plan, schedule, identify key milestones and dependencies. But this model provides more flexibility in the path to the end goal, which accommodates changing requirements along the way

WHY AGILE PRINCIPLES MAY CREATE VALUE IN INFRASTRUCTURE PROJECTS

Manifesto for Agile Software Development states:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Replace “software” with “solution” and read it again. Does it sound familiar and meaningful in your industry or project?

Some imbedded attributes of major infrastructure projects such as known technology and standards, repeatable practices, the scale of project and the number of involved teams and stakeholders which demands more comprehensive documentation, the overall project duration, and lack of flexibility during construction phase, etc. makes us believe that Waterfall is the best methodology for these projects. For the same reason, it may not be possible nor beneficial to fully implement agile methodology in these projects. However, today’s environmental, cultural, and economical changes encourage us to consider and maybe adapt some of agile principles, values, tools, and techniques such as the following ones in our projects:

More functional output specifications and less detailed scope are being provided by project owners to encourage innovative, most efficient, and cost-effective solution rather than predefined scope. In collaborative and progressive contractual and project delivery models which necessitates consideration of iterative approach by the project team to identify the best solution, then define and refine the related technical scope. As an example, we can refer to multiple iterations among operation, rolling stuck supplier, design, construction, and economical teams in DBFOM or DBOM projects during conceptual and preliminary design phases.
Focus on incremental value creation rather than completion of the predefined scope; why to wait for completion of the full scope of work to create and release project values? Is there a way to release value incrementally and via separate phases rather than spending multi-billion dollars, wait several years and maybe decades to gain values? In this concept “value”, may have broader meaning than economical or business profits. The project owners are the main source of identification and prioritization of potential values.
More collaborative approach among the involved teams, project owners and sponsors: Progressive contractual models require closer collaboration between different involved parties to distribute the risk, increase the efficiency, reduce the bureaucratic procedures, accelerate work, and guarantee successful project delivery. The issue is neither of our traditional project delivery models, nor our organizational culture have not been fully adjusted to accommodate the needs of these contractual models.
Technology based components of the projects such as systems and software components; in many cases technology-based components need more iterations considering rapid technology changes comparing to the infrastructure components. In many projects for the same reason, systems design starts later than infrastructure and causes considerable delays in overall project schedule. It might be advantages to manage technology-based components with agile and infrastructure detailed design and construction with waterfall and compile them with hybrid techniques.
Numerous changes and the required flexibility in responding to change. This may need higher risk acceptance level by project owners and some financial adjustments to assist project teams to be more flexible.
Being able to respond rapidly and properly to the unknown risks.
Retrospectives and lessons learnt are a very productive solution to adopt a continuous improvement method during project implementation. Unlike waterfall methodology and instead of recording lessons learnt at the end of project, after each sprint, iteration or milestone, the team gathers to identify the unproductive areas and discuss how they can improve for the next sprint, iteration, or milestone.

WHY HYBRID APPROACHE

As explained in the previous section, agile may not be the best methodology for infrastructure projects. However, considering the changes in our environment, preferred contractual models and many other factors may urge to adopt newer project management methodologies that match better with our selected contractual models. One solution might be application of Hybrid models to bring the benefits of both agile and waterfall to the table. It is important to keep in mind that customized format, tools and techniques for infrastructure projects comparing to what has been applied in other industries might be required.

HYBRID is a project management approach that combines linear strategies of waterfall approach with the adaptability of agile.

Based on the limited case studies, articles, and books I have read so far, Hybrid models can be applied in different circumstances or might be pertained in different shapes and formats. Some can be summarized as follows:

To use agile or waterfall for different components of the project and connect them through milestones, the release plans, acceptance criteria, etc. As a simple example we can refer to any projects that has some high tech and software components in addition to the building or infrastructure components. It’s not difficult to guess which component to follow what methodology.
To use iterative and agile approach for some specific sprints or phases that need refinements, crosschecking and multiple rounds of work like conceptual or preliminary design and waterfall for overall project or the phases with more clarity about scope of work such as detailed design and construction. We may need bigger teams and longer sprints for these iterations comparing to what have been considered and used in agile projects.
A combination of both methods which in my opinion will be more applicable in most of projects.

CONCLUSION

In addition to important agile principles such as facilitation of collaborative approach, continues improvement, etc. that are applicable to all our projects, before utilization of Hybrid methodology there are some critical areas that should be discussed, evaluated, and agreed among the project owner, project team, and main stakeholders such as:

Project requirements identification, prioritization, and track. The final list of prioritized and tracked requirements will create the scope of work. All parties need to assist and agree on this task.
Acceptance criteria for different project components.

What are the project values and how to deliver them incrementally during the project lifecycle?

What type of hybrid model may create more value for our project and why, and
how to integrate the overall schedule, release plan and acceptance criteria of different components or phases that are following different methodologies to guarantee project success and create incremental value release.
Acceptable level, areas, and timelines for change which should be agreed among stakeholders in advance.
Roles and responsibilities of each party and level of authority in decision makings.