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.

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?

-Ryan

In the design what happens if a sensor fails. While normally caught for the initial design it is less likely caught for design changes.

Craig, see point 2 above -- if you've used a particular sensor model before, this will reduce the likelihood of it not working for you. It's always lower risk to go with proven technology where you can.

And, as you've pointed out, the above also apply to changes later in the project, not just at initial requirements. Thanks for that!

Ryan,

You have done an excellent job putting all the risks together. Thanks a lot for sharing.

Dev

Devices are one of the top things that are over looked in an automation project. On most bad projects I have been on, the biggest time waster was the hardware integration. Things that do not work according to their specs, or the system designer's vision. You can spend all the time in the world writing perfect code and a device will ruin it every time.

In the past, as long as have someone that knows how the system works tell me what they want, I rarely have to know the process that well. Although it does help.

Great list.

One thing I might comment is that your last question; the "Have I missed anything?" perhaps should be number 14 there. One should always check and re-check before finalizing something. Preferrably, have someone else check it as well.