Do you have all the project team members you need?
In any new automation project, the technical issues underpinning it can be daunting. However, the people issues can be seen as insurmountable.
Many people have a high resistance to change. They may have the same response as they would have toward the loss of a loved one.
Four stages of mourning change are:
Denial — For some, the first reaction to a new automation project is denial. When told about a new control scheme or a new instrument technology (installing Foundation Fieldbus, for example) some people in the control room or instrument shop may say, "They’ll never do that. They’ll see it isn’t practical." Others may say, "I’m not going to get all worked up about that. We’ve had projects like that before and they never worked, and we’ll have them again." At the extreme, there are those who will say, "I’m not learning anything new at this stage in life; I’m retiring." (It happens more than you may think.)
Anger — As denial begins to dissipate, it may be replaced with anger. People may say, "They never asked me about that!" or "Why should I help them sort this mess out?" This anger may be coming from fear of the unknown. People may not have been given the particulars of the project and don’t realize what the organization is trying to accomplish.
There is a saying, "What you don’t tell us in fact, we’ll fill in with rumor." Sometimes the rumor is "They’re going to replace me." Other times, it’s "Yeah, we put something on the computer, and all it will do is make it harder." (Sometimes, unfortunately, it does.)
Workers may blame the project team for causing them extra work and aggravation.
These workers may have a point. They may not have been asked. How many times has an automation project been put in place without actually asking those who it will affect? It could be that there really wasn’t a problem to begin with. Control engineers can become so enamored with a technology that they just have to install it, whether it’s needed or not.
Bargaining — Those affected by the new project may try to bargain with the project team. Bargaining is a tool people use to try to regain control. They may ask that only part of the project be done now and the other part "later." This is called "Death by a thousand (project) cuts." Rather than the feared "scope creep," resorting to "scope shrink" may actually be worse. Cutting back the project scope due to resistance or cost may cause to the entire project to turn out badly or even die.
Remember the adage, "We’ll do things the cheapest way possible … no matter how much it costs." Sometimes agreeing to a cheaper alternative may not be better.
Acceptance — Not everyone ends up accepting the new way of doing things. They will continue to grouse about the way things used to be and keep asking (loudly), "Why can’t we just go back to the way things were?"
Others will finally accept the change. They may see that it was a good thing and end up embracing the change that was made.
At one plant, an advanced process control scheme was implemented on a distillation tower. The process engineers decided this control was needed and decided to incorporate it during the next turnaround. Unfortunately, the operators were told of the change only in passing and later assured that they would receive training on the new control system, "at the appropriate time."
At first, when they were showed the control narrative, they swore it would not work. After a while, the console operators found that that it did work and it gained acceptance.
A solution in search of a problem
In any project, it is important to work quickly through these "stages of grief" and move the group to accepting the change.
What follows is a method that may not work for everyone, but it has found acceptance in many plants.
The first thing to do is to make sure that the project team is not "pushing on a rope." Many times a project turns out to be a "solution in search of a problem." It is applying a fix to something that didn’t need fixing.
For example, doing hydrogen balancing in a refinery hydrogen plant can contribute significantly to a plant’s bottom line by shifting hydrogen production from less efficient hydrogen generation units to more efficient ones. One control engineer wanted to put that plant’s hydrogen plants on load balancing until informed by the operations manager the plant was not going to do it.
The manager explained that while it is a great idea in concept, all three hydrogen plants were running at maximum capacity, and when the load on each unit is 100%, load balancing is not necessary.
In this case, the "fix" wasn’t needed.
In another case, the IT staff decided to install a document control system in the plant. However, there was no pent-up demand for it within the refinery. The document control system was put in place. Then the departments were told the system was online and were asked what they wanted on the system. The answer was, "I don’t know, let me think about it."
The IT department struggled for a long time with the system before there was enough demand to actually use it.
One good rule of automation projects is to generate a demand for the project and let another group, such as operations, ask for it. At that point, it is no longer a controls project; it is an operations project with a lot more momentum behind it to get it done.
That is called "planting seeds." As one salesman who had been in the business for years said, "My job is not to sell you something; my job is to make you want to buy it."
If you are promoting a project, don’t try to sell someone on the "gee whiz" technology of a project. Show that person a need (preferably one he or she has expressed before) and show how this project can fulfill that need. For example, don’t try to sell a person the terminal on a terminal management system; instead, show a way he or she can prevent tank overflows and product contamination due to misaligned valve setups.
See next page for more about project team, champion, manager, prophet, and cheerleader
The project team
Once a project is approved in a plant, the project team is assembled. While the team’s size and composition will vary, there are four people who need to be on the team to assure both its success and its acceptance.
Every project needs a champion. The project champion’s job is to serve as an advocate for the project. The champion is the one who runs interference between the project team and upper management. While maybe not a part of upper management, he or she needs to be viewed as a power figure (either by position or by expertise) who can make sure that everyone involved is on board with the project and is committed to its success.
The champion is charged with making clear how the project fits into a plant’s strategic objectives, assuring that the vision for the project is translated into reality, and assuring that the project is using best practices.
The champion can also overcome user resistance and assure users that the project is real. They need to move on from the denial stage of change grief. The champion is the one who also runs interference for the project team and keeps senior management from "helping" with the project too much.
Many times the project manager is not from the controls group. That actually can be a benefit. Sometimes the subject matter experts working on a project can get so mired in the details that they can use someone to say, "Is this critical path? Should we really working on this now?" Other times automation projects can suffer from massive scope creep as the project develops and new opportunities develop to expand the project capabilities.
The project manager should have his or her fingers on the pulse of the projects to see how the project is running on the basis of cost, time, and quality. A good project manager can help a project have all three elements and not just two of them.
The project prophet will not show up on a project organization chart, but is important nonetheless. While the project manager makes sure that the project fits into the strategic direction of the plant, the prophet takes the lead in setting that direction.
In short, the prophet’s job is to "guess right." He or she looks down the road and has a vision of where the plant needs to be in five years. The prophet also needs to continue to improve on that vision and see how new technologies may affect not only this project but also future projects. If minor changes can be made to make the current project fit into upcoming activities, the prophet should make the project team aware of them.
A prophet may not be right all the time, and most times, that’s okay. One plant manager said to a member of the executive committee, "We have never had a project fail." The committee member replied, "It is better to be right 8 out of 10 times than 3 out of 3." A visionary company will allow for mistakes to keep innovation alive.
In many automation projects, particularly projects that are breaking new ground, a cheerleader is a great help in gaining project acceptance. Cheerleaders are also great morale boosters.
A cheerleader usually comes from the ranks of those who are the ultimate end users of the product being deployed and who can generate enthusiasm for the project. The cheerleader will keep up the morale of people even when things start to go wrong.
In one case, during the installation of an ERP system, clerks were literally in tears when they saw two hours of their wok disappear off the screen during a system glitch. None of the data was saved and it all had to be reentered. What made the situation all the more maddening was the fact that no one using the system knew why it was being installed in the first place.
This was a project that needed a cheerleader. Rather than users just being told they had to "live with it," a cheerleader could have helped in encouraging the end users, explaining why the new ERP system was important and helping them see the possibilities when the conversion was complete.
The project cheerleader is someone who can encourage those who will be working with the new automation project, as well as those implementing it, that the work they are doing is worthwhile and valuable.
While these four members of the team may not fit every plant culture, they can prove to be valuable members of any implementation project.
– Steve Elwart is the director of systems engineering for Ergon Refining Inc. He has spent 40 years in the oil industry, covering the areas of exploration and production, refining, and marketing. He also works with the U.S. Dept. of Homeland Security and Dept. of Energy as a subject matter expert on cyber security and industrial control systems. Elwart is the author of more than 100 presentations and technical papers dealing with industrial control systems, international relations, and cyber security.