Hello everyone, I am currently swamped with quotations that need to be completed. I'm wondering if anyone has a specific method or "rule of thumb" for estimating programming costs for projects. I am specifically referring to the cost for developing a ladder-type program, excluding any other expenses such as software, cables, hardware, startup, or documentation. My current approach involves using a set "day rate" in a spreadsheet and making an educated guess based on past experiences to determine how many days or fractions of days it will take to create the program. However, I am considering implementing a budgetary price for each input/output (I/O) to make the process more precise. It's important to note that my quotations also include costs for skid wiring, panel shop assembly, documentation, and profit margin markups for the entire project. Therefore, the programming cost is not the deciding factor in the overall project. I am seeking a more specific method for determining quotes rather than relying solely on estimates. Thank you for any insights you can provide.
I always break down tasks into specific items to cater to different job roles and customer needs. This helps me customize my approach and deliver exceptional service.
It can be quite challenging to estimate a programming job accurately. One effective method is to request a detailed machine operation flow chart from the end user. This helps gauge their understanding of the system and their ability to communicate it clearly. If they provide a Grafcet chart, it indicates a strong grasp of the machine's operations. On the other hand, if they struggle to articulate the details and only talk about it verbally, it could signify potential trouble ahead. End users often lack the comprehensive understanding and analytical perspective necessary for programming. While they may possess individual details, they may struggle to see the bigger picture required for successful programming. As a general guideline, a lack of understanding from the end user may result in higher hardware costs (x5), while a clear and detailed flow chart can lead to lower hardware costs (x2). Remember, this is just a general rule of thumb based on experience and should be taken with a grain of salt.
I'm in search of hardware recommendations. Is it a good idea to use 5 units for a program with a confusing layout and 2 units for a well-documented layout? My aim is to save time and get an accurate quote. Do professionals consider I/O when calculating costs, such as 16 digital inputs plus 6 digital outputs at $100 each?
Our company often refers to itself as I/O, shorthand for inputs/outputs/tags that serve as physical inputs. In this context, 1-I/O equals 1 hour. Just a thought to add.
When faced with uncertainty, it's important to focus on breaking down tasks rather than just input/output considerations. Input/output counts can sometimes be deceptive, especially depending on the balance between processes and permissions. Pierre's argument about using process descriptions to determine hardware costs is valid. It assumes that those who struggle with defining processes may also struggle with assessing hardware needs. However, this may not always be the case. Personally, I often find myself underestimating the time needed for a project when I try to give a realistic estimate. I find it helpful to analyze the tasks or processes that the programmable logic controller (PLC) needs to perform. This insight has led me to adjust my estimates accordingly. It's important to gain experience by working on several projects to understand your programming speed and process definition capabilities. In the meantime, it's wise to err on the side of caution and bid higher on hours. Tracking your actual time against your estimates will help you adjust for future projects. While I don't have any foolproof suggestions, starting with Pierre's idea may be a good starting point. It's all part of the learning process.Keith
There's definitely no "one-size-fits-all" method, as project estimation can be highly dependent on the exact requirements, complexity, and your development team's proficiency in the language being used. However, you might consider a point-based system, similar to what's used in Agile development. Basically, each feature or task gets assigned a number of points based on its perceived complexity. Then you determine how many points your team can complete in a given timeframe from previous experiences, helping you make more accurate estimates. Regarding your idea of implementing a price for each I/O, this can certainly add more precision, but ensure you factor in the complexity - all I/Os are not created equal! Lastly, remember that estimation is partly art, partly science - most importantly it should be continually refined as it's an iterative process.
I've been in the same boat as you before. One effective method I've found is using an "I/O count" estimation model, similarly to what you're considering. Breaking down the tasks into specific inputs/outputs has made my estimates more accurate than just daily costing. However, it's crucial not to oversimplify. Be aware that the complexity of the input/output tasks can differ significantly, so you might need a sliding scale instead of a set price per I/O. It's also essential to include buffer time for revisions and unexpected tasks that arise during development. Even the most meticulously planned projects have unknowns that can pop up. We've all been there! So, include a safety margin in your time and cost estimates to cover those unexpected occurrences. It might make your initial quote seem a bit higher, but it can save you headaches down the road. Remember that while accuracy is important, it's also about value. Your task is not only to calculate how much it will cost you to complete the project but also to communicate the value you are providing to the client, which justifies the price.
I've actually faced a similar situation in the past and found it helpful to implement a mixed strategy. I still use a daily rate as a baseline, but then I include a variable cost-per-feature approach, quantifying the programming effort based on I/O, complexity of the functions, and how often they've been implemented before. This helps to bring a bit more precision to the process but doesn't completely negate the importance of experience and intuition. Finally, if several similar projects are done, I suggest conducting a retrospective analysis to compare the estimated costs with actual ones. This way, you'll continually improve your estimates over time!
Hey there, I can definitely relate to your struggle. In my experience, I've also found it helpful to include a buffer for unknowns which inevitably crop up during software development. However, if you're looking to refine your estimates, one method I've found efficient is function point estimation. It might take a while to implement and adapt to, but essentially, you break a program down into its various functional components and assign 'points' to each, based on complexity. This makes the estimating part less arbitrary by relying on analysis of components rather than just past experience. This works remarkably well for ladder logic programming. You also account for documentation, error handling, and other factors. Give it a shot and see if it works for you. All the best!
I totally feel you on the struggle with estimating programming costs! One method I've found helpful is breaking down the project into smaller components or features and estimating the time for each part individually, based on complexity. This way, you can apply your day rate more accurately, and it often highlights any potential pitfalls you might have overlooked with a broad estimate. Additionally, keeping a log of your past projects and the time each feature took can be invaluable for future quotes. It might also help to involve a buffer for unexpected issues, just in case! Mixing both the per I/O method and this breakdown can give you a more detailed perspective on the costs. Good luck!
It sounds like you're on the right track with your day rate and past experience, but I love the idea of breaking down costs based on I/O because it can really clarify the complexity of the project. Another method you might consider is using function points to assess the size and complexity of the program—this could give you a more structured way to estimate programming effort. Additionally, involving stakeholders early to refine their requirements can greatly reduce underestimations down the line. Don’t forget to build in some flexibility for unexpected changes, too; it can save you a lot of headaches later!
Hey! Your approach sounds pretty solid already, especially using a day rate and past experiences as a baseline. One method you might consider is breaking down the project into smaller components or modules, then estimating the I/O costs as you mentioned. You can assign a complexity factor to each component based on your experience—like simple, medium, or complex—which could help you refine your estimates better. Additionally, involving historical data from previous similar projects could provide more accuracy. Lastly, maybe try to include a buffer percentage for unexpected challenges that always pop up in programming! Good luck with your quotations!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: One common method is to use a set "day rate" in a spreadsheet and make an educated guess based on past experiences to determine how many days or fractions of days it will take to create the program.
Answer: Answer: Consider implementing a budgetary price for each input/output (I/O) to make the process more precise. This can help provide a more specific method for determining quotes rather than relying solely on estimates.
Answer: Answer: No, programming costs are not the deciding factor in the overall project quotes. Quotations typically include costs for skid wiring, panel shop assembly, documentation, and profit margin markups for the entire project.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.