Scope creep. Two simple words that project managers in every industry have learned to dread. Every project must guard against scope creep, but the issue may loom even larger when the project is a shutdown, turnaround, or outage (STO). Companies spend a lot of money to plan and run STO events for their sites, while at the same time those sites are not producing any revenue. This makes managing or eliminating scope creep essential to the success of your turnaround planning.
We should note that there is a difference between scope creep and scope change. Scope creep occurs when items or tasks are added without going through the proper management of change process, resulting in increased costs, lengthened times, or both, without resulting increases in the budget or the length of time to complete the STO.
Scope change is somewhat different. It differs from scope creep in that the changes do go through the correct Management of Change (MoC) process. The MoC process can be done through your turnaround planning software or manually, but it must take place. This ensures that the changes are communicated and extra budget, if needed, is secured. Having a clearly defined change management process is one of the most effective tactics for preventing scope creep.
We’ve compiled the top nine tactics to manage scope creep during your STO event. Keep in mind, this isn’t a step-by-step list. Most of the tactics listed below should be applied constantly throughout turnaround planning, execution, and post-STO analysis of results.
Well-defined goals and a meticulously planned scope of work are some of the best safeguards against scope creep. An ill-defined scope of work is essentially an invitation for project stakeholders to make changes whenever it seems like a good idea.
In maintenance, we often talk about having a “single source of truth” for your maintenance and asset data. For STOs, the project scope must serve as your single source of truth. Work on the scope must be completed. Work that isn’t on the scope must go through the MoC process. Only once this is complete should it be added to the scope.
Naturally, it’s also essential to get sign-off on the scope of work from all relevant parties. If your C-suite has big plans that will impact the STO, it’s best to find that out early so their requirements can be included in the original scope. We recommend going over the scope with the approvers in person. Set up a call if that’s not possible.
This ensures that they fully understand the scope of work being proposed and they can suggest changes during this phase rather than after the work has started. Don’t just drop the scope in their email and hope for the best. It can be painful to intrude on a busy executive’s time, but that’s nothing compared to the pain of an STO going over budget because someone didn’t fully understand the scope before signing off.
The project scope for your STO is your roadmap and your baseline. That means it need to cover every single step, from the inception of the STO event to its completion. However, a complete scope needs to cover more than just the work being performed. It must also include timelines, milestones, and budgets.
Once the scope is complete and approved, you’re in a much better position to manage any changes that may occur. An approved scope can help make it clear that adding more work must result in an increase to the budget or timelines.
You can rarely avoid some scope changes during an STO event. The projects tend to be very large and involve hundreds of people and assets. At some point, work will be uncovered that is essential and cannot be pushed off to the next STO or dealt with by day-to-day maintenance. This necessitates scope change.
From the very beginning of planning your STO, you must show that you have a well-defined plan to evaluate and deal with scope changes. This will help ensure that any proposed change goes through that process and will give you leverage when stating your case for budget increases.
Each proposed scope change should be thoroughly documented. The change document must include every factor that impacts on the time, budget, or resources needed to complete the STO. These factors must be carefully considered before deciding to add the change to the scope of work. Remember to refer to your baseline scope and show what the proposed changes will require.
The exact format used to document and manage change will vary from organization to organization, but any format you use must include the following:
Depending on the exact change being proposed, it may be necessary to get approval from more than one person or department. The change document must list this, but just as important, your management of change process must make clear who the approvers are and when their approval must be sought.
All documentation regarding scope changes must be kept. This creates a paper trail that shows the proper channels were used and the correct approvals given. Complete documentation can also help serve as a guide for your next STO.
The STO’s baseline scope must be updated to reflect any approved changes. At that point, the updated baseline becomes your single source of truth and any future changes must be made to that instead of the original scope of work.
Your MoC process must also include a way to communicate the change to all concerned stakeholders. This ensures that everyone working on the STO is working towards the same goal.
It’s a very common mistake to assume that scope creep always comes from an external source. We tend to speak about it as if it were something imposed on the STO team by management, operations, or maintenance. However, scope creep is especially frustrating when it comes from your own team.
Respect for the baseline scope and the management of change process must start with instilling these values into your own team. They won’t be able to communicate it to others if they don’t believe it themselves.
Scope creep in these cases often has a good motivation: Team members want to be helpful. They don’t want anyone to be disappointed by the results of the STO. Unfortunately, a team member saying “Sure, we can do that!” can have far-reaching impacts on your ability to deliver the STO on time and under budget, even if the change is seemingly minor. Minor changes tend to snowball into larger changes. Before you know it, the small change has caused an avalanche.
The other common source of scope creep from within the team is a practice known as “gold plating.” This is where a team member, without using the correct MoC process, will add work to the scope to achieve a better result and add value. This can be very difficult to avoid but avoid it you must. We all want to produce outstanding results, and this is often the motivation behind gold plating. However, going the extra mile like this can be catastrophic when time and budget are of the essence.
You must make it clear to your team and all stakeholders that the correct amount of work is what is spelled out in the scope and that any changes must go through the MoC process. In an STO, going above and beyond will just leave you over budget and out of time.
Your goals are defined, your baseline scope has been designed and approved, your MoC process is spelled out in detail, and your team is fully onboard. The next step is to hold an official kick-off meeting to ensure all the project stakeholders understand the plan. Your kick-off meeting should also cover roles, responsibilities, timelines, and milestones. The kick-off is also a good time to communicate how and when you will report on the status of the project.
Communication is essential when executing an STO, and the kick-off meeting is where you ensure that all stakeholders understand the communication channels being used.
This is also the final chance for stakeholders to review the scope, the “plan of the plan”, and the MoC process. Be prepared to answer any questions they may have.
You should also be prepared to face constructive criticism. Don’t discount this immediately, as good ideas can from anywhere. However, always refer back to your baseline scope of work and remind stakeholders that all changes must be properly vetted and accounted for in the budget.
Poor communications are one of the primary sources of scope creep. As the project leader, you need to set the tone by communicating clearly, directly, and frequently. You must also setup clear lines of communication and use them without fail. If the communication plan calls for an email, then send the email. Don’t be tempted to send a text when the plan calls for an email. Sending that text may be easier in the short run, but before you know it the entire communication plan will go out the window.
Communicate well and communicate constantly. Scope change requests must be communicated to all relevant stakeholders, reviewed in accordance with the MoC process, and then the decision must be communicated as well. It is obviously important to communicate any approved scope changes, but you will have better results if you also communicate when a scope change wasn’t approved. Project stakeholders will develop a sense of when a scope is likely to be shot down and this will encourage them only to put forward scope changes when they know they’re truly vital.
Scope creep usually occurs in STOs because someone in your organization believes the work is important. While you can’t change your scope willy-nilly to accommodate them, the fact is that they’re often right. The work they’re proposing usually is important to the organization. It’s up to you, armed with your MoC process, to decide if the work is important enough to do right now.
When someone proposes a scope change, feel free to ask them if it really needs to be part of this STO event. You can do this before running your MoC process. They may be bringing you this work solely because they know the STO is a huge project, and they see it as an opportunity to get their important work done as fast as possible. Be as specific as possible with your questions, and make sure to probe their answers further. Avoid asking open-ended questions like “Can we delay this work?” Instead, ask questions like, “What will be the result if we hand this over to the day-to-day maintenance staff” and “What will happen if we schedule it for the next STO event, rather than this one?”
Asking questions like this may reveal that the work isn’t quite as time sensitive as originally projected. If they insist that it can only be completed during this STO, that’s when it’s time to use MoC and see if the work can or should be added.
It may be possible to eliminate all scope creep if your project hits all these criteria:
You really need the first two for a successful shutdown, turnaround, or outage. You’d better have those because there’s no way you’re going to get the third.
Executing even a relatively small STO event can still involve hundreds of people and assets and stretch out over a period of weeks. Scope creep is almost an inevitability in this situation. To put it bluntly, sometimes you won’t know exactly what you’re dealing with until you get the covers off the machines.
Inspections are almost certain to uncover work that is not part of the shutdown’s remit. Part of this can be dealt with by referring to the point immediately above this one. If it can be done after the shutdown, then do it after the shutdown!
However, not all the emergent work will be of this nature. You are very likely to turn up work that really should be done immediately. Use any historical data that you have on previous shutdowns as a guide. If you don’t have historical data, then factor in a contingency of about 10 percent “extra” time. Be transparent about this in the scope planning phase. Explain why you’re including it and show your justification for it. It’s probably going to be easier to get approval for it up front.
Your team members aren’t the only ones in danger of gold plating their work. You want to add value and keep all the stakeholders happy. You may end up a with few truly silly change requests. These are very easy to say no to. Unfortunately, most of them won’t be of this nature. Most of the change requests you get would provide better results…if you had infinite time and money. You don’t, and that means you’re going to have to turn a lot of those requests down.
At the risk of repeating ourselves, always refer to the baseline and use your MoC process. Just because the work is a good idea doesn’t mean it has to be part of this planned shutdown event.
There’s a lot you can do with spreadsheets. However, it might be more accurate to say that there’s a lot you can’t do with spreadsheets. Dedicated project management software solutions make planning the STO easier and allow you to keep a closer eye on progress and milestones during the execution.
Even better, consider a project management solution that is literally built for the needs of shutdowns, turnarounds, and outages. Using spreadsheets instead of STO software means you’ll have to “reinvent the wheel” throughout the planning state. A solution designed with STOs in mind will be easier to use and provide better results than solutions designed for general project management. As for spreadsheets, there really is no point of comparison.
STO Planner from Prometheus Group is a web-based system that serves a central point for organizing, planning, and documenting your STO event. It also offers seamless integration with your ERP, EAM, or CMMS, providing a true single source of truth for your scopes and accompanying documentation. For more information on Prometheus STO Planner, please click here.