I am an automaton consultant as well as an automation doer. I write software, design control systems and architect solutions or anything else that someone will pay me for.
I work for various clients here in Canada, and recently I was asked to justify my costs.
Make no mistake; the value proposition I bring to my clients is solid. Just ask me. Seriously, it really is. But I never had to think about it in the way I was being asked.
While my customer and I had worked from a handshake, the business world has changed. All things being equal, a contractual agreement is a must for many reasons.
I did some comparative research into some of the areas of concern.
How much do you mark up material that you might have to purchase for the project? How do you quote software projects? Who owns the source code? What special contractual subsections are present to protect both parties?
Markups are varied. As a colleague put it, placing a fixed percentage on the purchase of any product might put you on the losing side of love if you have to spend three days researching the product choices and then sell the product for $1.99. It works well when the catalog number is given to you and its worth $30,000.
My customer recently bought almost $200,000 worth of hardware from an automation distributor. He got the same markup as if hed spent $1.99. Im not sure thats fair.
Software projects are a bit of magic. If the specification is solid, there is a better chance of accurately quoting the project. But, when has that ever happened? What about scope creep, and a customers knack for changing its mind?
But its not all about the time. Its about the innovation you use to solve the problem. I have an analogy.
When you take your car to a repair shop, the mechanic uses the Chilton book for estimating the repair. For example, to change the spark plugs on a Ford Aerostar is 4.4 hours. This is because the back plugs are hard to get at. A good mechanic can change those plugs in three hours, an average mechanic in 4.4 and a not-so-good one needs maybe five hours. A smart one would drill holes in the firewall to get at the plugs and do the job in 1.5 hours. I know this because I owned one.
So a smart mechanic can bill more hours than he actually worked because he was smart and innovative. The same goes for good software guys. In the end the job gets done, but there is a quality component too.
How many PLC programs have you seen that dont have complete documentation and full fault trapping. The obvious ones are there, but not all.
PLC programs are interpreted; HMI-type software can be compiled. The customer should own the code unless otherwise specified. If there is proprietary code in the application, then it should be in a linked file such as a DLL. That way, everyone is happy.
Project work is not exact. Determining how long it would take to write an interface to a piece of the customers process or machine is something of an art. Unless youve done 10 similar jobs beforehand, it would be a best guess.
Hours per screen, rungs of logic per I/O point and dollars per database point have been ways to estimate costs. In most cases, the quotes are inflated by a healthy contingency because of the aforementioned variables.
I looked at the things I do for my customersIT work, project documentation, online help systems and training documents, PLC code, troubleshooting, engineering and control design and a few other things.
I look at that list and the 30-plus years I have been in the industry, I conclude that Im fairly well versed in the approximation game.
When the dust settles, well have a contract, and both sides will be happy. Costs will be better understood, and the legal ducks will be in a row.
But I will still have a problem convincing some that it really does take eight hours to produce a single HMI screen.
