Author: angela598sum15

Risk Identification HAZOP

Posted on by angela598sum15

Of the four steps of the risk management process that we discussed in class, I find the first step, risk identification, to be the most important and intimidating. The scary part about risk is the surprise factor. It seems that most failures stem from the unforeseen problems. Therefore it is vital to determine the best way to identify all risks upfront so that they can be avoided.

The little experience I have with risk analysis is from participation in hazard and operability (HAZOP) sessions for process equipment that my company designs. Although I have only participated in a few sessions, the format of the HAZOP sessions left a lasting impression. During a session, there is one HAZOP expert that leads the meeting and, oddly, might not even be familiar with the system or how it operates. All of the other attendees usually have more knowledge about the system and how it should and could operate. After looking at a flowsheet of the system, the HAZOP expert dissects the system and defines certain “nodes” which allow for isolation within the system. From there, each node is evaluated through a set of standard possible upset conditions. It is a laborious process because each node must be evaluated at the same set of possible upset conditions even though the possibility of an occurrence could be nonexistent.

The approach used for HAZOP is similar to the Risk Breakdown Structure (RBS) that we discussed in class. If you can break a project up into tiny pieces and apply a standard set of thought provoking questions or scenarios, it will help in revealing risk. For me, I always got some enjoyment when a risk was found from what originally seemed like a nonsensical situation. Without the systematic approach of running each node through the same conditions, the risk would have been limited to what we imagine would happen based on previous experience. By having an outsider trained in risk assessment lead the group through the thought exercises, the questions asked were not bound by the bias of the engineers.

Based on my experiences with risk identification, I suggest including a variety of team members and non-team members when brainstorming the potential risks of a project. It is important to have both experts and non-experts on the project. Also, never feel like a question or potential scenario is not worth mentioning. You might find that the likelihood of the risk occurring is greater than you imagined or the question/scenario might spark an idea that reveals another risk.

Do you have any advice or tips to add on how to improve risk identification?

Organization Strategy and Project Selection – Trampled by the White Elephant

Posted on by angela598sum15

About one year ago I was given the opportunity to work on an inquiry that involved a technology for which I had limited exposure. As an engineer I was incredibly excited, but also fearful of what I didn’t know and the time it would take to learn it. I am one of a handful of engineers in my department and there are only two other engineers at the company familiar with the technology – one is semi-retired and the other one works in another department. The inquiry was passed along to me from two heads of engineering that were themselves mostly unfamiliar with the details of the specific technology, but consulted with the “experts” and decided that we should proceed with lab scale testing. However, we didn’t have the equipment to do the testing onsite. My first task was to specify the needed lab equipment and come up with a budget. The charge to the customer for conducting the testing was just enough to cover the cost of the equipment so it seemed like a good opportunity overall – gain hands on experience, get new equipment for the lab and potentially go on to sell commercial equipment.

Once the equipment arrived I ran a series of tests which took, in total, about six full weeks over the course of six months. The tests got progressively better as I learned from mistakes and refined the procedure. I directed questions to the “experts” as they arose, but often found that the questions I needed to ask weren’t apparent until it was too late. On top of that, the responses I received weren’t exactly “expert” level.

After the testing was complete, the customer finally sent the RFQ so that we could design and quote commercial equipment. Upon reviewing I found that request was over my head. I reviewed the RFQ with the “experts” – one said it was “mind-boggling” and outside of our expertise, the other said we would need to run even more tests before we could quote. Just last week I had to go back to the customer and let them know that we are unable to provide a quotation and don’t have enough resources to conduct additional testing.

Since we just discussed project selection in class, I thought this was a great example of how chasing the wrong projects can get you trampled by the “White Elephant”. If anyone had asked any of the following questions at any time during the project we could have prevented wasted effort and embarrassment.

  • What specific strategy does this project align with?
  • What are the project objectives?
  • Who is the project sponsor?
  • Will resources be available for this project?

While I feel like the problem originated from the head engineers/management, I know that I am not blame free. I’m curious if I had MGT 598 one year ago if I would have approached the project more wisely or if I just needed the failure to open my eyes.

I think there are many other questions we could have asked along the way to save face. Do you have any advice for me or my department?