Equipment
9th July 2021

Integrating Capital Projects into a Turnaround Event

Article by Gordon Lawrence CEng FIChemE

Early, timely input and support is key, says Gordon Lawrence

THIS article discusses the fact that project teams are often blamed by turnaround managers for problems with meeting turnaround event schedules. It goes on to examine the key areas that need to be addressed when integrating a project into a turnaround event and highlights the point that these areas need to be discussed and resolved during the project front-end development, not merely during the turnaround front-end development. It closes by pointing out that proper integration needs early, timely input and support from the turnaround team and the project and turnaround steering teams. It cannot be left to the project team alone.

Why project teams get involved in turnarounds

Maintenance turnarounds (sometimes called shutdowns or outages) are significant events in the long-range plan of any refinery, petrochemical plant, offshore production asset or other facility that uses large, continuous production process plant. They consume a lot of time, money and resources and they represent a considerable lost production opportunity while the facility is shut down for this essential maintenance, inspection and cleaning work. Consequently, it is in the site’s interest to keep the period in which the plant is shut down as short and predictable as possible, in order to minimise the lost production opportunity.

However, a turnaround is often the only time when capital project work can be tied in to a process plant that otherwise is operating continuously. The recent economic environment, of increasing legislation to reduce emissions, increasing pressure to reduce operating costs and increasing pressure to improve plant flexibility has driven many sites to implement numerous capital projects, both small and large, to take account of these pressures. This has led to an increase in capital project scope needing to be installed during a turnaround event.

The issue with integrating projects into a turnaround

Ask any turnaround manager what the leading causes of schedule overruns are on their turnaround and there is a strong chance that they will blame the capital project teams and start talking about drawings that were late, materials that didn’t arrive, and construction teams that didn’t understand the meaning of the word “urgent”.

But is it true that capital project work is associated with turnaround delays? And is it fair to blame the project teams for those delays? To address the first point, there is evidence to suggest that having more project work to be executed in a turnaround is associated with greater risk of overrun. The benchmarking firm, Asset Performance Networks has previously published data which shows exactly that¹. But is it fair to blame the project team, or should the blame be spread a little wider?

Thinking about why adding project scope might increase the risk of overrun, as a first point, it is obvious that adding project scope to an event adds to the overall event size and complexity. All other things being equal, larger, more complex events inevitably increase their risk of schedule and cost overrun.

Secondly, there is the obvious concern that projects are developed and managed by project teams that think, plan, schedule and execute work-scope in a different way to that which a turnaround maintenance team is used to. Project teams think in terms of discipline design packages, whereas maintenance teams think in terms of discrete work packages; project teams execute field work on schedules stretching to many months, whereas maintenance teams plan work by the hour and by the shift; and so on.

Thirdly, for larger projects, the project team may be a corporate function, remote from the site and hence not have had an opportunity to build a relationship with the site maintenance and turnaround team. The project team may be unfamiliar with local site conditions; they may not be familiar with any local quirks in the permit-to-work system; they don’t know the layout of the site as well; and so on.

The topics that need to be integrated

So what can be done to ameliorate these potential risk areas? Below we discuss the key areas on which every project and turnaround team should align.

Which projects to include in the event

It is important to agree up front which projects are to be included in the event planning. This has several benefits including making clear at the start which project teams need to be included in discussions, and setting a baseline from which to challenge (and hopefully reject) the inevitable requests from process engineers to add their latest brilliant project idea to the event. (See the discussion of late scope changes later.)

Alignment on objectives

Another key issue is to ensure that everyone is aligned on the objectives for the turnaround event. Turnaround event teams inevitably have a desire to minimise the scope that needs the plant to be shutdown for execution. If there is a safe way to execute some or all of the scope “on-the-run”, while the plant is still operating, instead of during the event window, when the plant is shutdown, then the turnaround team will want that scope done “on-the-run”. But for projects, designing their installation scope in this way can potentially lead to more cost for the project.

One example of this, that I witnessed, is in the replacement of a set of pumps. To keep costs down, the project team proposed to reuse the existing pump plinths. This meant that the pumps would need to be installed in the turnaround event window, after the old pumps were dismantled. But unsurprisingly, the turnaround team preferred that the new pumps be built on new plinths, adjacent to the old ones, prior to the turnaround. In that way the only scope in the turnaround event window would be to swap the inlet/outlet to the pump. A major argument then ensued.

Designing the project for discrete phases

The next topic to consider is one that I routinely see ignored by project managers, with consequent significant problems for progress reporting and material tracking. It is to ensure that the design, engineering and procurement are set up for separate construction phases; pre-turnaround, turnaround and post-turnaround. Most project teams fail to do this. Instead, they proceed with design and engineering of the project as a whole. The result is that there is no transparency on progress reporting for pre-turnaround work versus turnaround work; no focus on prioritising work that needs to be done before the turnaround; and no transparency on delivery of equipment or other material that is needed for three different “required on site” (ROS) dates.

Integrating the field execution contracts

This topic is a major issue. The question is whether the project team and the turnaround team will use the same mechanical contractor, on the same contract terms during the event window². The most efficient, from a turnaround event point of view, is for the project to add their scope to the work being done by the event turnaround contractors and allow the same contractor to do both maintenance and project work. However, this requires the project team to hand over control of the event window installation work to the control of the turnaround team. It also means that the project team may need to stand-down their contractor for the pre-turnaround work, until after the turnaround is over. Furthermore, it splits responsibility for installation quality control. For all these reasons, many project teams are reluctant to properly integrate with the turnaround team on the topic of contractors. Nevertheless, in my experience, full integration typically gives the best result for the event. Full integration then further implies integration of execution schedules and integration of work package format.

Integrating the field execution schedules

The schedule of the work being done in the field during the turnaround event window by projects needs to be coordinated with the schedule of the work being done by the maintenance team. There are several ways to do this, but the most effective is for the project team to provide information on their work scope to the turnaround event planners and schedulers and allow the turnaround to control and develop the schedule. In order for this to work, there need to be a number of conditions in place, including agreement on what work package information the project will provide to the planners, and agreement on a target date for providing the information.

I have seen situations where both the project and the turnaround develop their own schedules. This requires extensive coordination between the project and the turnaround and I have never seen it work well.

Project construction packages

The next issue, related to integration of the contracts, is the development of work packages. The turnaround contractor will receive construction information from the maintenance planners in “work packages”; ie a package of information for each maintenance job. However, project teams are used to providing packages of information as “construction packages”, each one encompassing all work to be done by a specific discipline.

If the turnaround contractor is going to be expected to install the project work alongside the maintenance work, and if the turnaround scheduler is going to schedule the project work in the same detail as the turnaround work, both the contractor and the scheduler need project information delivered to them in “work packages”, not project construction packages.

Developing work packages from a construction package is typically not something a project team is used to doing. Nor do they typically have money to do this in the project budget. The most effective solution is therefore to agree that the maintenance planners will prepare the project work packages, and that the project team will provide the “issued for construction” (IFC) construction packages to the planners, in an agreed format (with the information the planners need), and by an agreed date. The planners then need to allow resources, time and budget for compiling the project work packages, alongside their work in compiling the maintenance work packages.

In my experience, agreeing what should be in the IFC package handed to the planners is usually fairly straightforward. But agreeing (and meeting!) the date by which those IFC packages will be delivered to the planners (ideally around T-10 or 12 months, to allow time for the planners, schedulers and contract managers to do their work) is far harder.

Material procurement, warehousing and distribution

Another issue related to the integration of contracts is how to handle material procurement and warehousing. Examples of issues to consider are:

Agreeing a common ROS date for materials that will be used in the turnaround event window.
Verifying alignment on what will be bought by the owner and provided as “free issue” to the contractor and what the contractor is expected to purchase and supply itself. (Typically, maintenance teams provide everything as free issue, whereas project teams quite often expect the contractor to provide small, bulk items as part of their scope of supply. One example that I experienced is when the project team expected the contractor to provide pipe supports, but the maintenance team was free-issuing material for its work.)
Verifying alignment on inspections for receipt of goods; for example, who does positive material identification (PMI) and when?
Reviewing whether separate warehouses are being used for project and maintenance materials. If so, there needs to be a method agreed that will allow the contractor to quickly and easily know which warehouse to go to for which material.
Agreeing consistency on how materials will be issued to the contractor. Maintenance teams often want to retain control of materials and issue each day on an “as required” basis. Whereas project teams sometimes prefer to issue everything to the contractor at the start and make the contractor responsible for storage, "bag-n-tag", replacement of lost items, etc.

Field construction supervision

Another potential area for friction and confusion is deciding who supervises the contractor in the field and what the chain-of-command is for construction queries. For supervision, it makes sense for the project engineers to be allowed to get involved in supervising the field installation. However, it’s also important to make them subservient to the overall event leadership in order to ensure that there is a clear decision route for any questions about which work is done on which day, or who should get priority of access to a workface in the event of a clash. If the project engineers are not allowed to be involved, this gives the project a problem in that the engineers need to find something else to do for the duration of the event; and it gives the turnaround a problem because the owner’s people who are most intimately familiar with the design are not on the spot to help with installation.

Handover documentation

Occasionally, and usually in situations where the project team is from a corporate office, off-site, there are situations where the documentation required from the contractor in order to hand over completed work as “mechanically complete” is different for the project compared to the maintenance team. This situation should be avoided. The contractor should use the same sign-off sheets, the same pre-startup safety review (PSSR) and other documentation, whether the work is maintenance or project.

I have seen examples where a turnaround was mechanically complete, but the plant could not start up because the project had failed to prepare the correct handover documentation to align with local authority requirements. What would have been a reasonably successful turnaround eventually had long delays, while paperwork was finalised.

Cost estimates – shared costs

The project and the maintenance teams will very probably want to share use of certain construction items. The most obvious examples are scaffolding put up to provide access for a maintenance activity, that also gives access for a project activity; and use of cranes. Some sites like to keep these resources completely separate, with the turnaround team and the project team each supplying their own. But this is wasteful duplication, it increases site congestion, and it causes schedule delay as turnaround and project teams access a workface using their own resources.

If the project and the maintenance team are sharing these items, there needs to be an agreement (typically some form of pro-rata agreement) on how the cost for these items will be shared. In addition, it’s also a good idea to agree how the costs will be shared if the schedule overruns. Otherwise there is a danger of arguments over whether the project or the turnaround is to blame for a delay and hence liable for the other party’s additional, time-related costs.

Alignment on key dates

Of vital importance is a need to align on key milestone dates for the project work, that will align with the maintenance preparation and planning. Many sites focus on a need for a project to have secured funding, to be allowed to be included in the event. However, this date gives no indication of whether the project drawings and material will be ready in time to align with the needs of the event. In my opinion, sites would do well to focus on the following key dates as well as the requirement for secured funding:

Deadline for issue of all IFC construction packages. (Ideally, somewhere around T-10 to 12 months).
Deadline for completion of all pre-turnaround project field work. (Commonly, around T-1 month).
ROS date for all materials to be in the warehouse. (Commonly, around T-3 months, to allow time for checks and for bag-n-tag work.)

Progress reporting

Some project managers balk at the idea of having to report their progress prior to the turnaround to the turnaround manager. However, the turnaround manager needs confidence that the project work is on target to meet the dates discussed above. As part of that reporting, it’s now (hopefully) clear why the project manager needs to be able to report on preparations for the turnaround event window work separately from the pre-turnaround or post turnaround work. But equally, the project manager would no doubt like to be kept informed of turnaround preparations. All of this reporting, including what information will be reported, needs to be agreed ahead of time, so that the project manager can make allowance for the cost of preparing those reports.

Scope changes

Lastly, there needs to be agreement between the project and the maintenance team on how scope changes will be handled. For the projects that are in scope this includes:

How unexpected changes to IFC packages after the IFC issue are cascaded to the planner, scheduler and contractor.
How site queries during the event execution window are passed up from the contractor to the project team for resolution.

But perhaps one of the biggest issues is how decisions will be made on whether to accept new projects into the turnaround event scope. In my experience, it is frequently far too easy for a process engineer to devise a new project (no doubt with a suitably impressive theoretical return on investment) and submit it for inclusion in the event at a very late stage in turnaround preparation. The project team is then left with an impossible task of developing the engineering drawings and procuring the material in time for delivery to the turnaround team. There needs to be a very clear set of rules that either rejects late project suggestions, or (if the return on investment justifies the project’s inclusion) requires the event steering team to accept the accompanying increase in risk to the event predictability.

Ensuring that integration occurs

All of the above points are hopefully self-evidently valuable to ensure integration of a project into a turnaround. However, the key is not only discussing integration, but ensuring that it occurs. There are a number of steps that a steering committee, project manager and turnaround manager can take to help ensure that integration is effective.

Integration plan

The first, and most obvious action is to develop, discuss and most importantly, agree a written integration plan that covers all of the points discussed above. Furthermore, it is important to ensure that all project teams sign up to the integration plan. I have seen several turnaround events where the turnaround event team did a good job of aligning on expectations with every project team except one; inevitably the biggest and most complex project. The one project that was ignored was generally left out because the project team was hard to communicate with. Inevitably, when the event arrived, there were numerous problems between the event and this one project. Difficulties in communication are to be overcome, not ignored.

The turnaround and project premise documents

To further bind the integration plan into the overall effort, it is a good idea to specifically refer to the need to comply with the integration plan in the text of the turnaround premise document and each of the project premise documents. (The premise document is the document that spells out the objectives, the boundary lines and the success criteria for the turnaround or the project.)

Success criteria and key performance indicators

The turnaround manager will almost certainly have specific key performance indicators (KPIs), against which his or her success in managing the turnaround will be measured. This most commonly includes targets for cost and schedule predictability, as well as safety and environmental events.

One way to ensure that project teams also buy-in to the need to work as one team with the turnaround team is to add turnaround related measures to the KPIs of the project managers. An example is ensuring that the event schedule does not overrun. Using such KPIs is difficult, because the project managers can, not unreasonably, argue that the event schedule is not wholly within their control. However, with a little thought, this can be a way to help ensure that project and turnaround team members work together as a team.

Work preparation process

It’s a good idea to embed integration activities into the front-end work process of both the project and the turnaround. This helps ensure that activities such as “Develop, agree and issue an integration plan” are tracked to completion.

Risk management

It’s important that the turnaround team and the project team think of the turnaround as one complete event involving both turnaround and project work scope to be installed. One way of helping this mindset is to ensure that the risk brainstorming workshop (that any self-respecting project or turnaround team will carry out during early front-end work) includes both turnaround and project representatives; and to ensure that participants are encouraged to think about integration risks by making this a specific topic for discussion.

Communication – progress meetings

Another area for ensuring good integration is by promoting clear lines of communication between the projects and the turnaround team. This can be accomplished by appointing a single point of contact for project coordination with the turnaround and by inviting representatives from project and turnaround to each other’s weekly progress meetings.

Steering committee role

A vital aspect of ensuring that integration is not merely a phrase, but that it actually happens, is to ensure that the turnaround and project steering teams view promoting and monitoring integration as one of their key roles.

External support

Even the best project and turnaround teams sometimes have trouble “seeing the wood for the trees”. To get around this, it can be useful to get an external third party to assist with facilitating the development of documents such as the integration plan, the contracting strategy and the premise document; and to have that third party review the turnaround preparations at key stages, ensuring that the review includes a focus on the progress being made by the project teams and their likelihood of meeting the agreed target dates³.

Why the project manager needs this information in a timely manner

Having discussed all the areas where integration needs to be carefully thought through, it may now be becoming clear why it’s not always fair to blame the project manager if integration does not occur.

Firstly, all of the decisions documented in the integration plan will have an effect on the cost, the contract strategy, the design and the volume of work for the project team. It’s therefore vital that the integration plan is agreed with each project manager before the project reaches the point of final funding approval, so that the project manager can make allowance for the integration plan’s requirements in the budget and schedule. Far too many sites only begin to think about integration when they appoint the turnaround manager. But this may be too late for many projects.

Secondly, it may also be clear that a common issue for capital projects is that the project team sometimes given an impossible task, by approving the project too late to give the project team sufficient time to prepare the engineering, procurement and field work before the turnaround. For example, if a project is approved only 12 months before a turnaround, it is rather unfair to expect the project manager to have all of their drawings and material ready in time for the event.

Conclusions

If project work needs to occur during a turnaround event, this will inevitably add additional risk of schedule overrun to the event. But that risk can be very effectively mitigated by timely agreement on a comprehensive integration plan, coupled with effort to ensure good communication and firm adherence to that plan.

Project managers need to know the details of an integration plan during early front-end development of the project, prior to any final investment decision, so that that they can include the integration costs in the project budget. They also need to be given sufficient time to develop the project engineering and procurement prior to the turnaround event. If project managers are not told of integration needs until after the project budget is approved, and if project managers are given impossible timescales in which to engineer and procure equipment, it’s unfair to blame them for any subsequent turnaround schedule overrun.