The capital project-delivery process has changed very little over the past few decades.1 Projects progress through a set of well-defined stages: concept engineering, detailed engineering, procurement, construction, and commissioning. Project managers and engineers may tout the rigorous approach taken to approve the passage of the project from one stage to the next, as well as project—management tools—such as cost and schedule baselines—used to control the project and keep it on time and on budget.
Pressed further, however, they may admit that certain organizational structures, while well meaning, have common flaws that lead to schedule and cost overruns. The root causes tend to be threefold:
- Risk aversion requires decision making by committee. Often this translates into needing a meeting for every decision, which slows the pace of progress.
- Control mechanisms such as stage gates or model reviews can lead to inventory building up between stages, which expands the schedule.
- Silos between disciplines create inefficiencies. As each silo controls for its own interest, negotiation about handoff criteria and acceptance slows down progress, and poor coordination among trades hampers productivity.
Over the past 20 years, industries that face similar challenges (such as manufacturing) have followed the lead of software engineering in adopting a new approach—agility—to overcome organizational inefficiencies.2 In an agile approach to execution and development, self-organizing and cross-functional teams—sometimes extending to suppliers, customers, and end users—collaborate to create and continually refine requirements and solutions. While the use of agile methods in capital projects is still uncommon, some early adopters have been able to reduce capital expenditures by a minimum of 10 percent and increase productivity and reduce completion times by 10 percent each. These examples of the potential for agile to transform the capital-project process are beginning to pique the interest of industry leaders.
How agile works in capital projects
A typical capital project is designed as a rigid, linear, sequenced process, with each stage handled by its own team of specialists.3 An agile project, on the other hand, is designed to be more nimble and dynamic: while a stable backbone defines clear deliverables and work packages at the standard project gates, dynamic capabilities are overlaid to react quickly to changes and allow projects to move more seamlessly through each stage.4
The key characteristic of an agile project is the empowered, cross-functional team, which works across silos to create end-to-end accountability. Work is carried out in shorter, more iterative “sprints” that enable the teams to quickly test and adjust ideas, minimizing risk of miscommunication or overdesign. Next-generation technology and a clear, shared purpose are crucial. These principles can be applied across the project life cycle—concept selection, engineering and procurement, and construction and commissioning—to compress schedules and improve productivity while maintaining safety and quality performance.
Would you like to learn more about our Capital Projects & Infrastructure Practice?
Concept selection
When projects are in the concept phase, teams usually generate multiple concepts and then select the most attractive through screening, further studies, and cost evaluation. In this phase, significant engineering capacity tends to be dedicated to the development of ideas that prove too difficult to integrate into a cohesive design, meaning more time and energy is expended than needed to get to the final answer.
In contrast, agile concept-engineering teams can switch to a new delivery model that prioritizes project features and the decisions required to get to the final answer. This would mean less time spent developing whole concepts and more time spent framing the right questions to help the team get the best answer that possesses the most possible desirable qualities. This approach can provide more time for value engineering, which reduces project costs, and significantly compresses the concept-engineering schedule.
One oil and gas company was working on a subsea tieback construction project to connect a new field to its production facility. But several open questions were outstanding, and waiting for functional silos to have capacity to answer them was stalling the project schedule. The company adopted an agile approach by challenging the team to focus on the most critical decisions and what features would determine which decision to make. The company was able to narrow down options enough to significantly reduce the amount of functional work, commercial-evaluation time, and subsurface studies, and to resequence several of the milestones. This certainty also gave the team enough confidence to place long-lead orders before the final investment decision without increasing the project’s risk profile.
As a result, the company shortened the schedule for concept selection by 60 percent, reduced capital expenditure in the engineering and procurement phase through nonbespoke design, and cut the time to first oil by around 35 percent, which improved the overall net present value (NPV) of the project.
Engineering and procurement
Engineering teams, particularly for smaller projects, are often staffed with part-time discipline leads who work on multiple large projects at once, with dedicated oversight provided by a small number of project managers and project engineers. These fragmented workforces often lead to bottlenecks when hand-off timings don’t line up and multiple commitments stall project progress.
Agile capital projects are characterized by smaller work packages that are more frequently integrated into the overall design, with multidisciplinary teams convened to tackle specific challenges in sprints lasting one to two weeks. Sprints will differ based on project maturity. Early sprints for projects that are just starting will focus on designing or setting and aligning on project requirements. More-mature projects will have sprints focused on core design aspects of the project, and sprints during construction will be broken into small work packages to enable detailed tracking and application of learnings from earlier packages. This approach requires a much more dynamic staffing model that assigns people for weeks, not months or years, and dedicates people at a much higher percentage to fewer projects at once. Doing this allows organizations to significantly reduce complexity, reduce spending, and compress schedules.
One national oil company had traditionally organized its engineers in asset-specific staffing pools. The company had been experiencing large schedule overruns and high levels of rework from functional silos. The company abandoned its top-down hierarchy and implemented an agile flow-to-work model, in which individuals are staffed to projects rather than specific tasks.5 This approach enabled it to dynamically match project needs to the skill sets of engineers throughout the organization and optimize project staffing. The model enabled the company to achieve higher productivity—freeing up about 25 percent of engineering capacity while accelerating schedules by 50 percent.
Voices on Infrastructure: The project of the future
Construction, commissioning, and turnover
The traditional approach to capital projects is managing the front line reactively to achieve preset milestones, handing out tasks to crews in a stage-gated, sequenced process. This approach can optimize earned value and productivity within disciplines. But it fails to consider follow-on impacts to subsequent disciplines and inventory buildup between disciplines that expand the schedule.
Instead, agile capital projects approach construction as a network of interconnected and defined tasks and resources. To reduce inventory and shorten the schedule, they break down the silos between disciplines by setting up cross-functional production teams and managing the flow of finished packages through to system completion.
A basic-materials manufacturer was embarking on a $500 million capital project to build a new facility to produce a cutting-edge, high-strength product. At its peak, the construction workforce involved 650 craftsmen. At 50 percent complete, the project team realized that delays to critical engineered equipment would result in delays to the final completion date. To minimize the risk, the company created a cross-functional team including stakeholders from project controls, engineering firms, and contractors, who together optimized construction interfaces and sequences. The team took a project-level view, facilitated sprint-planning sessions to identify critical activities, and proactively removed constraints and variability. By analyzing the project at this granular level, the team was able to create workflows and processes that reduced the impact of delayed equipment and reprioritized resources to recover time where possible. This approach enabled the project team to deliver the project 17 percent faster, and with 124 percent higher productivity than was previously achieved on the project.
Getting started
Capital-project organizations have been slow in introducing agile into their project-delivery processes partly due to some common myths and misconceptions. Some believe, for example that agile methods do not allow for meetings and or planning. Others find agile methods a tough sell when the typical structure of a project’s division reinforces both siloed communication and the rigid project stage-gates that drive traditional project development.
However, as pockets of case studies appear in capital projects, it becomes more clear that agile represents a transformative opportunity for the sector. To combat these common challenges to deploying agile, the next step for owners and engineering, procurement, and construction companies (EPCs) is to apply agile principles on a minimum-viable-product (MVP) basis—identifying a few specific areas to address, or “use cases,” that agile could productively target. This way, their people can start to recognize what agile can achieve. Early successes can create an appetite for more—ideally leading to agile applied on an end-to-end basis for an entire project or stream of value. Among the most advanced organizations, an enterprise-wide agile transformation is the eventual result.
Apply the agile playbook in specific use cases. An MVP starts by identifying isolated opportunities in a part of a project where it’s possible to deploy and test agile ways of working. Examples might include proposal writing, concept selection, or strategy sourcing—processes that typically benefit from cross-functional teams, are time bound, and have clearly defined targets. Establishing an agile team, following the principles, and dedicating the required resources enables the iterative learning that’s at agile’s heart. Mindsets also matter: selecting team members who are excited about testing this new way of working and are keen to try new things and build capabilities helps build momentum and positive word-of-mouth.6
Find a candidate project within your portfolio for deploying agile end-to-end. Limited use cases will likely have limited impact until they build into something more comprehensive. Moreover, skeptics may wonder whether ideas that have been applied to narrow problems will work in their projects or functional area. To limit these risks, the next step after the MVP is to look for a project or moderately sized department that offers the potential for significant improvement in productivity, schedule reduction, or similar metrics—and then win support from the highest levels of leadership. Their commitment will be essential both for the agile changes to take hold, and for other parts of the organization to take notice.
It’s important to note that agile might not work in every situation, and its use must be tailored to the project. A core understanding of the full agile way of working is critical. But agile could revolutionize how capital projects are delivered. If capital projects were to achieve half of what has been demonstrated in other industries, this could easily bring projects in budget and on schedule, and drive further improvements to NPV. It’s worth the effort.
This article was part of the Global Infrastructure Initiative’s September 2020 issue of Voices.
