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.

Related posts:

1. Coffee Maker Cost Estimation Using SEER for Manufacturing The department of Industrial Management & Systems Engineering at West...
2. SEER Estimate By Comparison Professional Released To All Users                 The SEER...
3. Estimating Best Practices The following are the bullet points from Dan’s paper on...

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%.

Related posts:

1. How Hard Is A Hardware Model Estimating the effort, schedule, labor & materials, operations & support...
2. Estimating Systems Engineering…. The Upcoming Book.. and SEER I had the opportunity to review Dr. Ricardo Valerdi’s (MIT)...
3. CMMI and SEER Applicability: Estimation, Planning & Control Processes and SEER Integration Galorath’s Ton Dekker presented this paper covering SEI’s CMMI and...

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.

Related posts:

1. The Value of Lessons Learned In Improving Estimates The latest issue of the IEEE transactions on  software engineering has...
2. Step Nine: Document Estimate and Lessons Learned Each time you complete an estimate and again at the...
3. Experience Is What You Get When You Didn’t Get What You Wanted: Lessons Learned Review For Estimating Another reason to measure and record lessons learned…. Even is...

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

• Keep A History: Start An Enterprise Database NOW
• Business Case: Evaluate ROI In Addition To Costs
• Convert Expert Spreadsheets Into A Common Language
• Make The Estimating Process As Simple As Possible; But No Simpler
• Be Proactive: The Process Is Important, The Tools Go Along With The Process
• Get Buy-in From Program Managers
• Hold People Accountable: Center Of Excellence Can Prepare Estimate But Program Managers Must Own Them
• Tie The Estimate To The Plan
• Track Progress Vs. Estimate Throughout The Life Cycle
• Estimate Schedule As Well As Effort (Cost) For Complete Picture
• Tie The Business Case Into The Estimating Process
• Attack Non-productive Rework As Part Of The Process
• Have clear definitions: What does complete mean.  What activities are included and excluded (E.g. development only or total ownership; help desk included or excluded, etc.)   Which labor categories are included and excluded in the estimate (e.g. are managers included?  Help desk? Etc.)
• Don’t ignore IT infrastructure and IT services costs
• Tracking defect sources can go along with the process

Related posts:

1. GAO Cost Estimating and Assessment Guide Released Congratulations to the GAO team for releasing the “Cost Estimating...
2. Estimating United Conference Papers Available On the Web Follow this link to see some of the estimating united...
3. Risk / Uncertainty In SEER and Project Management The question was asked “what probability should I estimate at” ...

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.

Related posts:

1. Live From UK Williams Formula 1: How SEER Made IRS Projects Successful The US Internal Revenue Service used SEER for Software and...
2. Live From UK Williams Formula 1: Ford Motor Company Europe Uses SEER for Software and IT This morning Ford Motor Company’s European operation presented their development...
3. Live from UK Williams Formula 1: Euroclear Bank IT Support With SEER SEER has become the keystone of Euroclear Bank’s project review...

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.

Related posts:

1. SEER-H Expanded Technology Support for Electro Optical Sensors The latest SEER-H update also included major enhancements to the...
2. CostIQ Case-Based Reasoning Model For SEER Customer Order This week we received our first order for the official...
3. Live From UK Williams Formula 1: DSTL Estimating Future Unmanned Air Systems DSTL uses SEER and Galorath’s new CostIQ (Case based reasoning...

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.

Related posts:

1. People Make a Difference In Projects Ed Yourdon, one of my lifetime heroes, posted a presentation...
2. Estimating Best Practices The following are the bullet points from Dan’s paper on...
3. Impacts on Software Productivity The following summarize the impacts on effective technology (propensity for...

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.

Related posts:

1. SEER-H Electro Optical Sensor Estimation Validation If you estimate Electro Optical Sensors you will know what...
2. New Update To SEER for Hardware, Electronics & Systems Hits Beta I had the opportunity to see the SEER-H beta presentation...
3. SEER for Hardware, Electronics and Systems: Major Enhancements I just sat in a review of the release candidate...

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.

Related posts:

1. SEER for Hardware, Electronics & Systems Can Control Cost Risk of ASICs I have been pleased with the performance of the detailed...
2. Embedded Designs Integration Cost Challenges Embedded design integration is the integration of all efforts (hardware,...
3. SEER Does Systems of Systems (SOS) Estimating SEER-SEM works hand in hand with SEER for Hardware, Electronics...

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.

Related posts:

1. MIT Interns Bust Brooks Law? Interesting article on slash dot discussing how a startup hired...
2. Software Staff Size Still Impacts Productivity: Brooks Law Lives! When drawing conclusions from data it is important to analyse...
3. Eating the IT Elephant: Moving From Greenfield to Brownfield Development The book “Eating the IT Elephant“ discusses the issues of moving...