You probably know this scenario all too well -- you scope a project, ask your integrator for a quote and it’s a great price. The project starts and everything is proceeding without a hitch. Perfect.
Often-overlooked Risks in an Automation Project, and how to find them
Then BAM. Change order. It’s a perfectly reasonable request too -- the design changed and so, the software had to change too. Change in software is a change in cost right? Now, does your budget have enough contingency in it, or do you now have to have an uncomfortable conversation with your boss? This approval process could take weeks or months, and makes you look bad as a project manager. If the risk had been quantified up front, this scenario wouldn’t be needed.
Now, you always need SOME contingency. But, how much is appropriate? Here are some things to consider:
1. If you’re modifying an existing system, are there already problems with the existing system/architecture? How stable is it? Any other issues that could crop up unexpectedly?
2. Have I used these particular devices before? (not just “have I used a flow meter before” but “have I used this exact model of flow meter before”). If a device is unproven it may take longer to work with than a known device.
3. Operationally, how comfortable is the plant with how to run this system? Is there a risk that during commissioning the operations team will change their mind about how they would like to run the line or add extra features?
4. Will this system be used for an R&D facility, or to make experimental products? If so, check out question 3 above. R&D means lots of experimentation, and changes to the software functionality from my experience.
5. Are any of the key staff on this project new to the role or inexperienced?
6. What’s my level of familiarity with running a project with this particular technology?
7. Have I run a project at this facility before?
8. If upgrading a system, is the system VERY old, does it have out-of-date documentation, or is the electrical cabinet a mess of wires?
9. If upgrading a system, who has had access to change the way it works? Are these changes well-documented?
10. Working with this particular project team in the past, have they typically asked for many changes?
11. In the past, have the vendors I am working with tended to issue a lot of change requests? (do they typically under-quote, then issue many change requests)
12. Are there any potential performance issues? (e.g.: is this system very large, does it need to respond very quickly to inputs, is it very critical)
13. After the system is commissioned, will it be run right away (or will some features be run straight away, but some others stay dormant for a long time)? If so, you may want to leave some money for later in case there are unexpected changes.
Have I missed anything? What have been your most insightful questions you've asked yourself at the beginning of a project to make sure all of the risk points are identified?