New SEER Labor Rate Calculator: A Leap Forward in “Should Cost” & “Will Cost”
I saw a demo today of our new labor rate calculator. It takes in various labor rate drivers and computes a viable labor rate.  It even evaluates the cost of equipment, electricity, floor space, insurance, etc.
This is a great step forward in the “should cost” and will cost for product manufacturing. Buying organizations can describe the problem and see what a fair labor rate for the region, country, machine, etc. Mixed currencies are supported as well.
The following is a small example of the kinds of information that can be specified In this case it is configured for manufacturing.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Embedded Designs Integration Cost Challenges
Embedded design integration is the integration of all efforts (hardware, software, etc.) within an system that is typically dedicated to perform one or a few functions. Typically there are real-time computing requirements involved in these types of designs. Integration costs can at times become a considerable portion of the overall cost on a project. The continuous introduction of newer technologies continue to drive up integration efforts.
Use of old factors that estimated Integration Assembly and Test ( IAT) as a function of overall top effort were weak before but now can produce dangerously low estimates. Part of the reason why IAT costs have classically been painful can be attributed to the fact that it is at this stage where the complicate blend of hardware to hardware or hardware to software comes to a point and must all meet specifications at once! What worked in recent simulations or in isolated tests now becomes painfully clear won’t work at a combined level. This invariably leads to the continuous waves of adjustments, partial redesigns, re-architecting, retests in a desperate effort to close in on the minimum requirements.
For estimation purposes, careful consideration has to be given to the work break down structure of the embedded systems being modeled to ensure adequate estimation of integration effort and risk are covered at all levels. For instance, just applying a 10-35% IAT factor at an enclosure level in order to capture integration of all board and SW underneath it might be okay for some simple systems but not newer technologies which bring along extra complexities. An example is where the design involves custom components (ASICs, FPGAs, etc) which in turn have embedded processors within their fabrics. In these System on a Chip (SOC) designs, it make sense to break out the cost of integrating the SW onto the chip itself. At the next level one could add another rollup to cover the integration of SW to the main board running a general purpose processor, etc.
Another example could be designs that involve multiple separate custom chips running on the board since there might be a significant effort to get these chips to work with each other.
In our SEER H hardware model, we break out these sections with a separate roll up to calculate the IAT. At this point, we take care to set the parameters that describe the complexity of the effort and the experience of the folks doing the work. If this type of design is done often, we would create a knowledgebase (default template) to capture and standardize the estimation approach. As can be seen, many designs can involve layers of IAT which in turn can drive up the final overall IAT numbers considerably beyond 35%.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Lessons Learned On Major Engineering Program: Viable Cost Estimates Needed
Recently one of our analysts attended a “lessons learned” presentation on a very large scale, joint service engineering program. The conclusions listed by the program management team sound like some warnings we reference in the introduction to a SEER training course.
Consider…
“Chronically unrealistic cost estimates tainted the budget process and set up the program for cost overruns.
“Incomplete, inaccurate estimates of heritage [software code] contributed to cost estimation problems and led to significantly optimistic assessment of technical & programmatic risk.
“Failure to create clear, detailed performance expectations & incentives.”
While the last item is foremost a contracting issue, all of these problems can be addressed through the correct use of SEER hardware and software models. And since all estimates are only as good as their inputs, honestly assessing technical and programmatic parameters in comparison to SEER knowledge base defaults and risk-adjusted outputs can place programs on the path to success throughout the acquisition lifecycle.
Solutions to these issues are covered on this blog, in SEER webinars and SEER training classes. We hope to see you there.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Estimating Best Practices
The following are the bullet points from Dan’s paper on estimating best practices. Â Using these best practices can increase project success dramatically.
- Decide Why You Want An Estimate
- Map Estimation Goals To Estimate Process Maturity & Develop Plan To Achieve The Maturity
- Have A Documented, Repeatable Estimation Process
- Evaluate Total Ownership Cost; Not Just Development
- Estimate A Range And Pick A Point For The Plan
- Re-estimate The Program When It Changes
- Avoid Death Marches: Programs With Unachievable Schedules Are Likely To Fail And Drain Morale
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Live From UK Williams Formula 1: DSTL Estimating Future Unmanned Air Systems
DSTL uses SEER and Galorath’s new CostIQ (Case based reasoning estimation) to rapidly generate estimates of Unmanned Air Vehicles. Â They are looking to reduce costs and increase the viability of estimates.
They need to understand the trade space of different system concepts and cost them to see how far they have to relax the capability until it is affordable.
CostIQ is allowing them to generate a complete estimate and detailed Work Breakdown Structure by describing performance based characteristics of a system. Â In UAVs, for example, reusability or not, range, payload, etc. are key drivers.
The paper will be available at www.galorath.com in the next few days.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
SEER-H Electro Optical Sensor Estimation Validation
If you estimate Electro Optical Sensors you will know what a challenge it can be. That is why SEER-H’s ElectroOptical Sensor model was developed. The following is feedback from a user: SEER-H EOS was within 6% of actuals and they thought they could have gotten even closer had they answered all the questions instead of just the first three. The report follows:
A confirmation of the SpyGlass EOS estimating tool and platform influence factors.
I received a recent Government Procurement announcement for one of the systems in the EO Sensor model database that provided the the unit’s cost and procurement history. The sensor is one of the projects in the CostIQ library. I loaded the the procurement info into the CostIQ SEER-H EOS project i.e. prior units, quantity buy and learning curve. SEER-H EOS projected a production cost of $487,722 and the actual Government procurement cost was $458,000, within 6% of the actual. Note: I had only reset the 3 parameters noted above.
I would expect if I were to do a detail analysis of the procurement/procurement history and tweaked SEER-H EOS the results would even more closely matched the actual procurement cost.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Personal Capabilities & Other Non-Technical Parameters Can Make a Big Difference in Estimating
Thanks to Galorath’s Sam Sanchez for these insights on non-technical parameters:
When I first started with Galorath, I used to wonder about the usefulness of having parameter inputs like Developer Experience or Development Tools and Practices” within our electronic models. Like many engineers, I didn’t like these types of qualitative inputs, preferring to use more concrete entries like frequency of board, number of IC’s/IO and others. However, as the years have progressed, I’m amazed at how critical these qualitative parameters continue to be. Like I heard mentioned in one of my SEER H classes, There are A teams, B teams and believe it or not even D teams. More importantly, the impact of these variations can cause dramatic differences in a projects level of effort.
Common reasons for poor team efficiency could be longevity of the individuals in the given technologies, recent mergers, bad chemistry, poor communication practices and others. It’s important to note that we look at this parameter as an overall assessment of the team.
To help reduce confusion with this input, SEER-IC looks at the following criteria: Accomplishment Metric, Configuration Control, Communications, Adv Skills and Tool Experience. Specific measures within these major sections help users to come up with a reasonable range input. Also, this is definitely one parameter that should have a different entry for least likely or most. Â In other words, there is always some level of risk here.
In SEER-H, swings in Development Experience individually can swing costs by as much as 30%. Development Tools and Practices by as much as 50%. We tend to look at common variations. In reality, at times, the variations may be orders of magnitude.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
SEER-H Expanded Technology Support for Electro Optical Sensors
The latest SEER-H update also included major enhancements to the SEER-EOS electro optical sensor model.Â
SEER-EOS adds specific features to extend the capability of SEER-H to estimate the life-cycle costs of electro-optical sensors. SEER-EOS estimates are derived from key technical and performance parameters.
The original EOS model release handled space based systems. While the space community was thrilled, organizations with other requirements grumbled.  Well, the wait is over. The Electro-Optical Sensor (EOS) update offers estimation of sensors on space based, air vehicles, missile, and other complex platforms.
In addition to an overall database update, several new technologies have been added, including a new technology category for Laser sensors which includes Laser Diode and Diode Pumpted NdYAG Lasers. New and revised optical devices include Refractive Telescopes (both Visible and IR), Reflective Telescopes and Reflective Telescopes with Scanning Mirror. New detector technologies include Linear InGaAs, Area InGaAs, Area Bicolor HgCtTe and Area Microbolotomers. There is a new One-Axis Piezoelectric Actuator mechanism and a new Joule-Thompson with Pressure Vessel cooler.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
SEER-IC Add-on To SEER-H Gets The Newest Technologies
Galorath has just released a major update to SEER for Hardware, Electronics & Systems. Major enhancements encompass several areas. I am always fascinated by the SEER-IC plug-in that models custom chips (which can be major cost drivers of systems,) as especially the positive feedback we get from organizations building complicated electronic systems.
SEER-IC adds specific features to extend the capability of SEER-H to estimate the development and recurring costs for custom ICs, ASICs and FPGAs. This add-in is tightly integrated with SEER H to facilitate a more effective cost analysis of the circuit card and its critical components.
The Integrated Circuits (IC) option for SEER-H now offers estimation of Mixed Signal and MMIC technologies. This new capability extends SEER IC to cover components designed for RF applications in addition recurring and non-recurring costs of developing a Standard Cell ASIC and FPGA.
Congratulations to the development team and user organizations who assisted with this update.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Brooks Law Is Applicable To Many Collaborative People Activities
Brooks Law is that there is an incremental person, when added to a software project, that makes it require more, not less time. And adding people to a late software project makes it later.
 I have been spouting Brooks Law for over 20 years for software projects. You know the drill. An important project is late. So the first inclination is to add more people, or put in a red team, or something to speed it up. Unfortunately when Brooks Law comes into play, those additional people make the project fall further behind. What happens is that for each additional person, there is some energy lost as they need to communicate with others. At some point the project has all the people it can handle. And adding people makes the project later. Even if the project could absorb more people, the reduction in productivity as the in-place team has to communicate with the additional staff on the late project causes the late project to get later.
Using this information we can determine where Brooks Law might kick in at any point in the project and can compute the minimum time – the point at which people have been added at the maximum rate that is still productive, and hence a minimum staffing time and numbers of staff. We can also determine the inefficiencies of overstaffing and the schedule penalty / cost improvement from using an optimal effort schedule as well. This is one of the core models within SEER for Software (SEER-SEM).
Although I have generally discussed this phenomenon in software projects, the same applies to hardware, IT or other engineering projects. And even on assembly projects.
I recall working at a cannery one evening. This was a facility that canned food for the needy. We had a great turnout, probably over a hundred people anxious to help. As the peaches came down the conveyor belt, the main job was to cut off any bad parts. Each person, wanting to help, picked up all the peaches they could and cut something off. I am sure the net pounds of peaches canned was well below what it would have been with the right number of people on the line.
And hardware development projects have nearly the same issues as software projects. Add too many people too early and there will be wasted energy. The project can take longer.
The opposite is also true, to a point. Assuming a project is planned with a longer schedule and fewer people from the start: Fewer people on a project can extend the schedule but fewer communication paths cause the total effort to be less.
The basic issue of Brooks Law can be expressed in the equation:
n(n − 1) / 2
This equation computes how many different communication paths exist between team members. Thus the larger the team, the more time people spend communicating rather than making progress. So adding people to a project that is already late increases those communication paths and takes more of the time of those who should be making progress.
 
Figure 2 illustrates that there is a minimum time for any software project to be completed (it can be shipped sooner but to be really ready to ship this minimum time comes into play.)Â Additionally, some cost maybe saved by a planned longer schedule (but not many projects in the US are willing to wait longer… In general, Europe is much more appreciative of the lower cost opportunities.) up to the optimal effort point where the cost begins to rise again.
PS: Use caution when some claim Brooks law is no longer valid. Proper application of Brooks law should look at individual teams working on individual programs, not an entire large system all at once.
References:
Excellent Knol on Brooks law.
“The Mythical Man Month” is a classic in software engineering, written by Frederick Brooks and describes Brooks Law in detail.
Wikipedia, The Mythical Man Month
Software Sizing, Estimation and Risk Management: when Performance Is Measured Performance Improves“Â by D. Galorath and M. Evans.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.
Project Prediction Infographic
