Who is Accountable for Scope?

I think most of us in the Turnaround/Shutdown/Brownfield Project business would agree that “Execution with Excellence” is the goal.?One can break that statement down into a myriad of components, but in the end, it is the drive for excellence that powers a high performance Shut-down team.?

Success requires a variety of things, not the least of which would be a solid Process/Program.?My premise for this brief piece is that you already have a fully developed Process, and your client has already signed off.?Easy breezy right??You’re off to the races, it’s only a matter of time before your Brownfield Project Management genius will be widely recognized.?Not so fast, now is when we realize that people agree to things without really paying attention all the time, I’m thinking to do a couple of commentaries on the things people “ASSUME” once they have a TA Process, this is the first.

For today, let’s talk about Scope.

Who owns the Scope??

There will be exceptions out there, facilities run with enlightened Operations management teams, but my own experience is that if you succeed in getting a Shutdown/Turnaround Process in place, a bunch of “assumptions” will follow, and one common assumption by the Operations Team is a belief they are free of the scope development bugaboo.

Sorry, not happening!

Operations owns scope.?Operations develops scope.?

No other possibility exists, your new shiny Shutdown Team cannot develop the project scope.?We receive that from operations.?These days there would typically be a joint Scope development phase, and often enough the Shutdown Team will be accountable for making sure that happens, but we don’t tell the client what work we will be attacking.?When one thinks about it for a minute that’s obvious…?I am the fox, these are your hens, how many of them are “In Scope”, because the foxes had a vote and we think all the hens are in scope.

The Process should have, and own, and administer, a Scope Control process to be sure, some method of accurately tracking the never-ending changes from the client for the client; but the scope itself … not ours.?Our Process almost certainly drives us to ask challenging questions during Scope development, such as… “Is this really Outage dependent”, but in the end, if the client wants to use Turnaround as some form of maintenance catch up basket, that is their authority, we need to be clearly advising how a decision like that will relate to cost.

Why is it that virtually every Operations Team I’ve ever worked with is so eager to hand off Scope development to a Shutdown Team??Well let’s just say it like it is, shall we??Scope development is a lot of work, with a lot of stress because work not needed eats budget for no reason, and missing work needed can mean an unscheduled Facility outage, and whereas we fully understand the work load and the stress, it simply cannot be done by us.

Operations owns Scope.

That being said, with today’s work management platforms like SAP and competitors, scope development should not be as grueling as I’m seeing people make it.

Shutdown Scope development should fall out of the day to day Work Management process.?Notifications should be fully processed upon receipt. Work Management databases such as SAP are built to do this right, the breakage is not with the tool but with the Work Management team and process.?

Work Management should not address the immediate concerns every day and push the?“oh that needs a shutdown”?work into the background. Fully complete the Notification process, if it requires an outage, process it that way.?Whether you use Revision codes or some other method, when you arrive at the beginning of scope development 28 or so months out from your big event… 80% of the orders should produce themselves.

If the way you develop scope is by painfully crawling through the maintenance backlog for weeks or months, you're doing it wrong, and getting very poor value from your expensive Work Management tools.?I’ll retract the work “wrong”, not wanting to insult anyone… let’s say you are not currently optimizing you expensive Work Management platform.?

Basically, still doing things the way we did in back in the 80s, even though our tools are light-years more capable. There never was any point in investing in Work Management tech if there is a tolerance to allow people to continue to work in yesterday.

The secret to solving the challenge of Turnaround Scope development does not lie with your Turnaround Team, it lies with your regular maintenance and planning departments.?

We’ll plan it, schedule it and execute it, that is the purpose of both the Process and the Team, but we don’t produce the scope, that would just be silly.

One last example for those who don’t want to accept the above…?expecting us to develop Scope for Operations is the exact same thing as calling a Contractor, giving them the keys to your house, telling them… “Reno this place for me, I’ll be back in six weeks.”?Six weeks later you have an invoice for $20MM to reno a 1400-foot bungalow.

Contractors fault??No, not even a little bit, you left the scope development to the contractor.?Your Shutdown Team is a contractor by any other name.

(More than happy to rebuild your facility from the ground up with all new pipe and vessels, but hmmm... I think you missed a few zeros in the budget number you just sent me.)

#justsayin