Quoting/Estimating Labor Accuracy

mobil1syn said:

hopefully you are going to do something fun since you got a vacation

Click to expand...

an unpaid one haha.

Getting caught up on a lot of stuff I have neglected due to working so much, like doctors appointments and stuff around the house.

Tom Jenkins said:

It sounds like you make variations on a basic theme. My business was similar. After doing it for twenty plus years I felt like I was lucky to get within +/- 10% of my estimate. That was true regardless of whether I or one of my guys did the programming. And I always added contingency allowances besides.

You cannot realistically expect to make your estimated time on every job. If you are good (and I was) you do better on some to make up for those you lose on. It evens out at the end of the year.

Go back to past jobs and get the hours. It may not be necessary to breakdown the time into as many steps as Mr. McQuade did. I would go by easy, complex, and extremely complex or the number of I/O or other simplified categories that makes sense for your systems. Put the numbers in a spreadsheet. Make a chart of the data for each category. High/Low/Close will be the most informative, with the average for Close. That will show the scatter in the data. From that you can develop an estimating strategy.

And your boss is wrong - communications glitches and hardware problems and other kinds of #$%@#^$ are the norm, not the exception.

Click to expand...

This. Every word of it.

I am always wrong on my labor estimates. I have been overestimating my abilities for most of my career.

There are jobs where we know we are going to go long on hours but keep the estimate low due to the circumstances. It will cut into our profit on that job, but will earn us the bid in the first place which almost always leads to more work for that customer. There are jobs where we know that we can be a little fat on labor and materials estimates and still win the work, so those offset the jobs where we come up a little short.

There are certain jobs where specs call for hardware or software that I know will cause problems, so I add a lot of hours to compensate. When I control the choices of hardware and software, I am probably within 10 to 20% on my hours estimates.

"Interfacing an item that customer specified after searching '[function] din rail' on Google Shopping" is one of the hardest things to estimate.

Worst case is going to be "I spent 3 times as long as one would have thought it needed and it still didn't work even when the developer from the manufacturer got involved. We are now going with a more expensive model which we know works from v€ndor X, but we need a few more hours to update all the drawings etc." Obviously if you're going to quote worst case, you should have skipped the first bit and went straight for v€ndor X.

Often you can get the manufacturer to put together a proof of concept based on the functionality you need. Other times you can get them to quote to develop an interface to your spec, which you can then just add a markup and put in your quote.

It sounds like your boss is getting towards retirement and is understandably more risk averse. Try to communicate more in terms of risk with your estimates. Possibly even include the risk of losing the work. Noone likes overruns, and him being able to say at the negotiating table "hey my engineer has highlighted that this cheaper hardware has a large uncertainty on time. Obviously I can eat that risk financially in my quote if that's the way you want to go but their could be scheduling implications. He has proposed this more expensive hardware. You get a better product and my labour time goes down to nearly even it out." Sounds like a firm that knows what they're talking about.

theColonel26 said:

well now I'm curious lol

Click to expand...

First, I was going to say that IO buffering is just another step in cross referencing. The maintenance guys do understand it because every single analog in the PLC is essentially buffered. The trick is to label things correctly... the IO address is labelled as PLCX_RackY_ModuleZ_ChannelA. This even makes it simpler to understand whether the signal they are looking at is correct or not.

Your manager is a hypocrite. Your boss is clueless in salesmanship and understanding of how to make money on software. If he accounted things correctly, he could push a slightly more expensive PLC with code reuse and claim back the cost on the software re-use. If you're using AD stuff, is Micrologix that more expensive?
A lot of the times, the customer is stupid and is assuming cost... on the other hand, going into the code is really only a necessity because the system has poor diagnosis capabilities. The customer never thinks about that, but if you're reusing code, you will be able to build more diagnostic capabilities and make the system better for the maintenance guys.

Lastly, I had a manager that decided to fire me on the spot after I handed in my notice at my previous job. It was hilarious because he did it out of spite and not reason.

A) the morale was fairly low already in that office because of him and his boss... walking me back to collect my things and move out destroyed the morale completely for everyone. There was a team building that night and everyone just decided not going at 16:00 in the afternoon.

B) he was banking on firing me, not paying for my notice and me not doing anything about it. A colleague of mine then proceeded to highlight to him that I worked offshore making a fantastic salary and am very, very frugal and would not hesitate dragging them through the courts to ensure that they would lose whatever they thought they would get out of doing it. Needless to say, they paid up on time.

C) His boss who was an even worse cheapskate than me gave him a proper public bollocking for essentially throwing money out the window (paying me to tender my garden in sunny May, go on interviews and generally enjoy my life).

I agree with most of what everyone said. As a programmer you will be working on the system last. The mechanical engineers and electrical designers are already done with their work and they probably went over their scheduled hours but nobody cared because the project deadline was too far away. By the time the programmer gets to work on the system, the customer wants the machine tomorrow, and you're expected to do a week's worth of work in a day. My advice is, do as much as you can offline and find ways to simulate or test your logic beforehand. Either download to a spare PLC, or use RSEmulate etc. Then once you can start testing it on the actual system, send your manager a daily update email with what you accomplished that day. If asked to estimate your hours, think about a recent project you did and how long that ended up taking and base your estimate on that.

In my career, I was the electrician, panel builder, installer, the electrical designer, purchasing manager, quotations manager, inventory control guy, programmer, sometimes even mechanical designer, welder, and machinist.. I had to do it all at one time or the other.

As a programmer, you must be involved in the machine design meetings from beginning to the end of design and even during the machine build process !

A programmer MUST know what the specifications are, what the machine is supposed to do, what the designers are thinking, and what their plans are.

when you get a po for any machine, the programmer needs to read the specs, write down what he sees the machine doing, and write down what type of valves, sensors, load cells, and other devices he thinks the machine will need.

then you meet with the designers and listen to what they say.
when they go through the operation, you go over what they said and point out what you have and why.

that makes the designers think about the design. Is your point valid? does the air valve need to be double solenoid? did you make a mistake? take notes on everything you disagree about and when the meeting is over, tell them you will see if their design will work and plan another meeting.

this process will save a lot of heartache on the designers, purchasing the wrong parts, and you as the programmer. things will go a lot smoother and faster working together.

Failure to do this means only one thing, pointing fingers at each other and in the meantime, the costs go up and the customer doesn't get the best machine design.

james