Program Design Estimate

[shawnhimself]

For those of you on your own - how are you estimating hours on program design?

I've heard of people basing it on the I/O count but that doesn't seem practical to me. When you start adding packML, motion applications, etc... the I/O count could be low but the design time certainly does not get any smaller.

I've recently started on my own but its been just 'hey do this and give me the bill' but now I need to provide an estimate to bid on a job... and frankly I have no rule of thumb on the hours it would take.

I do know that it will physically take more hours to do than I will ever estimate, but that's just me, overly meticulous at times. I chose not to bill people for my lunacy.

 

[Peter Nachtwey]

You are right about not putting too much emphasis on I/O count. Analog I/O will take much longer to work with because there are calculations involved instead of simple boolean logic. Estimating motion control can be tricky because often you are at the mercy of a designer that doesn't know what he is doing. I break the project down into parts and try to estimate how long each part takes. The motion control can vary wildly depending on the application and the design.

 

[devo.xx]

At my office, we will try and see how many parts can be rolled in to identical Add-On Instructions/Function Blocks. Estimate the time to do 1 AOI/FB, then multiply by how many instances. ie. 8 pump system, to program a pump from scratch takes maybe 2 hours. So 16 hours for pumps...
After we isolate each potential AOI/FB and have an estimated time, we take the total number of hours, take 0.5 of the total for the HMI.
Then commissioning is just a staple number for us. If it takes any more than a week to commission, we probably were not ready to install it.

Of course, you will end up saving money once you start writing your own Libraries. AOIs & UDTS, or FBs & SDTs. Then you still get to bill for the "potential time" it would have taken you to write those, but they are already written, and you have just saved 16 hours of work

Good luck

 

[osmanmom]

There non standard cost for programmer up to you.

 

[mort81]

If your customers are willing and understanding, break out your development (fixed price) from your commissioning (T&E). That can save you more than anything as you can usually get a good gut feel for development time needed on a given scope of work, but we all know about and experience unforeseen's that come in commissioning. The T&E makes it nice that you don't have to keep going back for change orders for out of scope items either. Plus as a selling point to your customer, it will save them money as well without the need to bloat contingency.

If they insist on fix price for everything, make sure you have a good scope of work clearly defined and keep extras to the side for change orders and put a good contingency in.

 

[Saffa]

It's a tough one. You'll probably end up underestimating the first few jobs you do. I just keep a timesheet for each job and then refer back to them later on when quoting similar jobs. But I did get a little burnt on the first couple jobs!

I remember quoting for a replacement SCADA server and upgrading their software. I think it took me 3 times add long as I'd estimated, just because I'd never done it before and had completely underestimated the hassles I'd encounter. Luckily I did another two machines later on so was better prepared!

 

[RheinhardtP]

I think IO count is the most accurate. However i would go further and define the IO as simple/complex and super-complex devices. And give them a time per unit

It will also depend on if you use function blocks / Symbol sets / importing tools ect. Hardware even plays a factor so i would add a factor if it is a PLC that im not so familiar with.

And then the f-factor at the end for unknowns.

Normally works out pretty well that way. If you build a good spreadsheet where you can fill in these factors it makes it easy to do the calcs.