Why Process Control Migration Projects Fail

Apr 18, 2012 6:37:00 AM | Posted by BrianBatts

Is fear of failure haunting your upcoming migration project? Engineers are pretty good with band-aids and bailing wire, so absolute failure is rare. But in process control, pitfalls like exceeding budget, operations rejection, and maintenance headaches could constitute failure. In migration projects, most of these pitfalls originate not from incompetence but from missed opportunities.

Let’s take budgeting as an example. You didn’t want an unfundable, fat “budgetary” estimate, so you warned the vendor, “I need a realistic, FUNDABLE budget!” Unfortunately, your vendor’s interpretation was, “Give me the bare minimum.” After the project, you’ll have a functioning solution, but your operations team will be missing features they use every day in your current system. Was it avoidable? Could you realistically have noticed something was missing from the proposal as you went about your day-to-day “keep the facility running” activities?

The reality of competitive industry is that you have to “do more with less.” Most obsolete systems were installed under larger staffs with more time to review proposals. Today, proposal review gets kicked down the road until your funding deadline. Consider using a consultant that follows the FEL (front-end loading) process to develop a budget for you. (The FEL process broadly solicits CTQs, while giving funding approval staff assurance of a realistic budget.)

Your consultant should also be worried about encouraging operations participation in planning. Why? People are inherently afraid of change and tend to resist it from day one. Avoid operations’ FUD (fear, uncertainty, and doubt)! Make them feel like they’re part of the planning process. Pick peer-respected operators, who suggest solutions when problems arise, as contributors to the migration planning team. Encourage them to talk to and solicit input from their fellow operators. Proactively querying wants, needs, and fears will head off perceived implementation “failures.” Some FUD is reasonable, but FUD is minimized when operations feels like it’s “our system.” Also, don’t forget to let operations know if parts availability is forcingmigration!

What about maintenance personnel transitioning to a new platform? If the new system differs significantly from the old system, chances are a week or two of classroom training isn’t adequate. There are new rules of thumb to learn, and the value of newly available diagnostic information to understand. One of the best solutions I’ve seen for facilitating broader technician acceptance is for a client’s “trainer” technician to actively participate in new system factory testing and checkout. (Just don’t forget to put trainer technician T&L and hours in your budget!)

Finally, if you do hire a consultant, don’t be afraid to be honest with them about your level of understanding and confidence, as well as your own personal FUD. Your consultant will likely be trying to solicit that information to better understand your needs, and will have a vested interest in your personal success. So help them to help you!