Introduction
Recently I was contacted to perform a conversion project from Schneider Electric’s Unity Pro over to the latest Beckhoff TwinCAT 3 platform. Furthermore, instead of converting ladder logic straight over, they need to have everything re-written in structured text. Kudos to them by the way, this is the direction every program should be going, but that will be an article for later.
Instead of offering them them just an hourly amount, I decided to offer a fixed-price quote for getting the project done. A fixed-price quote for software conversion!? Wouldn’t it be simpler to just charge by the hour to get this done? Yes it would be simpler, but to help them control the costs they wanted a fixed price. Software is notoriously difficult to estimate in the best of circumstances. Luckily in this case, doing a conversion project is on of the easiest types of software projects to estimate (as opposed to estimating something that hasn’t been done before).
Breaking Down The Estimation
I hear you now, “but how did you do it?” Easy, the customer provided me a pdf print-out of the Unity Pro program. From that, I took a section and rewrote it while timing myself. As an aside, you should be timing yourself while coding all projects so that you can have a record of how long it takes you to do something for future estimates. After timing myself I extrapolated from that how long it would take me to convert the project on a per page, per rung, and per logic basis.
Per Page
This one is simple, taking the total time it took me, divided by the number of pages of the module that I converted, I got the per page amount. Multiplying this time by the total number of pages involved in the conversion of the program got me the overall time per page. This created an unrealistically large number, approximately 4.5 months. The inclusion of all pages, even blank ones, caused this large number. However, this large number is actually good because it forms a likely worse-case scenario.
Per Rung
After doing the per page analysis came the per rung analysis. To do this, divide the time it took by the total number of all rungs in that module. Then count all rungs in the total program and multiply by the per rung time to get the overall per rung conversion rate. This number was less than half of the per page amount, coming in at 1.77 months. It is important to note that I included all rungs, whether they had logic on them or not. Per Rung analysis forms a good basis for the most-likely scenario.
Per Logic
After achieving a per rung estimation, I then painstakingly went through the document again. This time the blank rungs are eliminated, leaving only rungs with logic. Counting these remaining rungs and multiplying them again by the per rung time results in the per logic time. In this instance the total time was 1.10 months. Per logic analysis is good for a best-case scenario. If I’m in the best-case scenario, then I’m in the zone and don’t get stuck on any of the logic, so I seamlessly get all of the logic converted. Have any of you ever known a software development cycle to go so smoothly? Me neither.
Putting it together
After getting these three estimations, I used the PERT equation, which weighs the time it takes to get it done, based upon how far the range is from the most-likely scenario. For this particular case, the range between worst-case and most-likely case is significantly larger than best-case and most-likely case. Therefore the number that is calculated can be expected to fall somewhere between worst-case and most-likely case. My PERT analysis resulted in a total conversion time of 2.09 months.
For more information about using the PERT equation, or PERT analysis in general, check out this article.
Adding Extras
The PERT analysis only accounts for the estimated time that it will take to do the logic. I also had to add in time for weekly meetings and for writing up a conversion log. For these, I estimated at least 1 hour per week for meetings, and at least 0.5 hour per day for maintaining the conversion log. It is important when estimating to account for these often missed, but common, elements of projects. For fixed-priced projects, you want to make sure every time you break from doing your primary job (converting the logic), to do secondary jobs, is accounted for. Plus for fixed-price projects, I automatically add 10% of the total hours for project management. If you don’t add time for project management within your fixed price projects, you only have yourself to blame for failed projects that are way off schedule.
Negotiating With The Customer
After presenting the customer with the price of the project, it was determined that my initial offer was over their budget. No problems, thanks to keeping detailed records of the per module cost (timewise) of what it would take to convert the project we were able to re-negotiate the scope. It would have been easy for me to change the time, by using the Per Rung or Per Logic estimates, but this is bad practice. Never reduce your time estimates, unless scope is removed. I’ve seen too many times a desperate salesman cutting hours without removing scope, or reducing the amount charged without scope, and then having a surprised look when they lose money on the project at close out. It’s incumbent on you as an Engineer (an alleged professional) to temper the expectations of your customers, by forcing them to either increase their budget, or remove from the scope things they don’t need.
In Conclusion
Now you understand how I estimated a conversion project. This is of course different than estimating software production for things that don’t exist yet. I’ll get to that in a different article. The important thing to remember is that you need to take the time to go through the existing logic and actually time yourself on a small portion of it. When communicating with your customer, go over how you arrived to your conclusions. Show them a detailed breakdown on what it will take to do the conversion. Any reasonable customer will appreciate the time and effort you take to give an accurate estimate, as opposed to an off the cuff estimate. Prove to the customer you are a professional, and they will treat you like one.
Do you need help with a Beckhoff or Mitsubishi project? Do you need help estimating your own projects? Would you like assistance evaluating a systems integrator bid, from a professional who used to work for systems integrators? Then don’t be afraid to reach out today!
Contact
Leave a Reply