How to identify and reduce risk in your next automation project

  • January 12, 2015
  • Feature

By Ryan Hildebrandt

DISCLAIMER: This is not intended to be another article you’ll read on the internet today and move on. I am a firm believer in taking action and discovering new ways to work that improve upon the old. If you’re continually on a journey of improvement for yourself and the way you run projects, read on.

Still with me? Great. Let’s get started.

Several years back I was alone onsite shortly after finishing university, tasked with making what I thought was a relatively simple modification to a conveying system. I had never used the technology beforeand there was nobody else with these skills available at the office. So, it was up to me to learn the technology,  in this instance it was a Modicon Concept PLC. Thankfully one of my colleagues had prepared an analysis of what had to be done, so I set out to complete what I assumed would be a relatively straight-forward task.

As it turned out, this couldn’t have been farther from the truth. The system was very old, and many people over the years had modified the program. The resulting system was much more complicated than anticipated. The change that I had originally thought would take a few hours ended up taking several days.

Ultimately, it was a disaster. I remember the plant manager asking me “politely” when I thought things were going to get running again. Add to this – it was Easter weekend and everyone was cranky and just wanted to get home. The real problem though -- the product produced on the line was one of the flagship products of a multi-billion dollar confectionary company…and they’ve stopped producing because of me. In the end everything started up, but it certainly wasn’t pretty.

We have all experienced situations such as these. Maybe a simple modification takes days longer than planned, maybe two components you assume can communicate with each other simply don’t, or maybe your coworkers are a bit disconnected from each other and there are miscommunications about each other’s responsibilities for the project. Either way this results in additional time spent, missed production targets, and costs lots of money.

How do you identify and reduce risk in an automation project so this doesn’t happen to you? At each stage of the project lifecycle, and for every party involved, risk can be introduced (and subsequently identified, assessed, and mitigated). Let's look at how these uncertainties come into play and how to reduce the effects on your overall schedule and budget. Read on, or if you’d like to download a checklist of risk identification/reduction questions and action steps, get it here:

Identifying Risk due to The Factory

This is your experience with the factory, the extent to which you have worked with your coworkers and the other stakeholders, and how often you have all done work in this particular factory.

An inexperienced project team (or a team inexperienced with each other) is a much different project to run than an experienced team. This shows itself in different ways.

  • When the integration team arrives onsite to start commissioning, some tasks are still to be done that slow down progress (electrical installation, deciding on IP addresses, equipment delivery, coordination of operators for training sessions etc.)
  • Nobody really gets a chance to thoroughly review the projects’ requirements so when the system is demonstrated many of the stakeholders request additional functionality that they assumed would already be in place.
  • Commissioning takes longer than planned because parts arrive late, electrical/mechanical/IT teams are not synchronized, and everyone has a different understanding of what “complete” means
  • While the project team is onsite for commissioning and support, the operations staff don’t get adequate time to trial the system, so nagging issues continue to affect production rates for years to come

Last minute changes, imperfections, and unintended bureaucracy cannot be eliminated entirely, but at least by understanding the degree to which these risks are present you can budget effectively and add contingency as needed considering these factors. The downloadable checklist available at the end of this article addresses how to identify these risks in your project.

Identifying Risk due to Suppliers

The suppliers you work with all bring some degree of risk to the project, since there is always a chance that they won’t perform their duties to your expectations. Electrical installation, mechanical installation, panel build, new computers, network experts, software vendors, OEMs and integrators all play an integral part in the success of your project.

How does this risk come into play?

  • You assume that they will build things in a certain way because that's how other similar systems work. Without being documented in the design or requirements stage, your vendor cannot know this requirement but a supplier familiar with your business would have assumed this.
  • Some parts of the software (e.g.: alarms) were not tested to the degree that you expected, so there are software/hardware issues during startup
  • Electrical/mechanical vendors are brought in for the installation to finish before the software checkout starts, but the installation is late so the software checkout cannot be completed on time.
  • The definition of "done" is ambiguous, so when each of your vendors is told to be "done" by a certain date, this means something different to all of them.

How do you reduce these risks? Remove as much ambiguity from your requests to your suppliers as possible. Solidify requirements and any confusion about what you need is drastically reduced. Ensure you clarify what you mean in your schedule (e.g.: what does it mean when electrical install is complete?), and you'll be able to coordinate teams much easier. The downloadable checklist available at the end of this article addresses how to bring your suppliers together at a lower risk time in the project to ensure as many of these risks are mitigated as possible.

Identifying Potentially Risky Business Needs

Of course, you can spend all the time you like on design and requirements, but if the business needs are particularly complex this will introduce some risk. Although you can't change business requirements, you can identify where these risks are so that they are easily quantified and included in your budge. For example:

  • Modifying the functionality of an old system, or a system that many people have modified over the years (e.g.: a control system upgrade on a 30+ year old PLC system) means that all of the existing issues will come to light as part of the project
  • Integrating components that typically don't communicate with each other, or that you have little experience with, or using different communication protocols may cause technology-related issues
  • Anything with a large number of components could cause problems during commissioning, as the load on the large system is increased (e.g.: many network devices, I/O points on a single PLC, screens in an application etc.)

Risk Impact and Probability

Of course, not all risks are created equally. Each has a different impact on your project and likelihood of occurring, which drives how they should be budgeted for, planned for, and mitigated if possible. Here are some questions to ask:

  • How critical is the production schedule for this system at the time of commissioning?
  • How critical is this feature (e.g.: if component X cannot talk to Y, is this feature necessary at all, or is it just “nice to have”)?
  • Is there a contingency plan in place if the worst happens? (e.g.: if the chosen flow meter doesn’t work, can you implement a different device until a suitable replacement is delivered?)

All projects have some risk and by bringing them to light and minimizing them as much as possible, you can budget accurately and avoid surprises.

What can you do now?

We agreed at the beginning of the article to take action.  Don’t let another project be compromised by risking identification and leaving assessment up to chance (or “gut feel”). You can download a worksheet to use with clients and modify to your suiting that details some risk identification and reduction action steps you can take on your next project here:

Ryan Hildebrandt is a licensed professional engineer (P.Eng) and self-employed controls engineer based in the United Kingdom; he creates useful tools and guides for other control engineers be they based in factories or integration firms.

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..