We are excited to announce a new addition to the services Galorath has to offer.  Dan Galorath (CEO and President of Galorath Incorporated) and Don Reifer (President of Reifer Consultants) have combined their collective seventy years of software development experience to offer:

Independent Risk Assessments

Risk Assessment Teams provide expert-level independent assessment services to determine root-causes of problems and recovery when faced with adversity at the enterprise, program or project level.  Dan Galorath and Don Reifer , along with the rest of the Galorath senior staff bring their extensive experience in a wide range of technical, management and costing specialties to remove subjectivity by using numbers in order to justify the needed change.  This proven methodology uncovers both risks and remedies using a variety of approaches to yield results in even the most troubled organizations and projects.

The Galorath/Reifer Risk Assessment independently determines risk in a structured and systematic manner.  Using purpose built checklists, they interact with the stakeholders to gather the facts to reveal the true issues, not the perceived issues.  Subsequent root cause analysis uses available metrics and performance data to isolate and quantify the issues from which they develop a custom action plan to fix the causes of the problem, not the symptoms.  Using this approach, they have been able steer troubled organizations and projects back on track.  Results from the Independent Risk Assessments have yielded millions in award fees, contract renewals and extensions.

Areas of Expertise

• Enterprise Management
• Systems Engineering and Architecture
• Hardware and Software Engineering
• Independent Cost and Schedule Estimation
• Metrics and Measurement
• Root Cause Discovery and Analysis

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. Galorath / DCG IT Estimation For Business Value and Project Success Clinic Here are the slides from the Galorath / David Consulting...
2. Capers Jones, Gary Gack, Leon Kappleman, Dan Galorath Team Up To Improve IT From the consortium web site: Information Systems Risk Management Consortium...
3. Information Systems Risk Management Consortium: Capers Jones, Gary Gack, Leon Kappelman, Dan Galorath The consortium is the result of four of the industry’s...

I had the pleasure of meeting and working with Bob Lewis of Infoworld and CIO magazines recently.  In looking through his many excellent blogs I noticed this one today. It sumarizes a viable metrics program very well and is compatible with the goal, question, metric approach.  He calls it the 6 C's of effective metrics:

1. "Connected to Organizational Goals: Good metrics are connected to important goals. In fact, they begin as important goals, stated in English.
2. Consistent: Consistent metrics always go in one direction when the situation improves and the other direction when it deteriorates. If good doesn't always point in one direction and bad in the other, your metric will drive organizational dysfunction.
3. Calibrated: Calibration means you get the same value in the same situation no matter who records it. It also means the data are free from sample bias and other quality problems.
4. Complete: Anything you don't measure you don't get, so any useful system of measures must include all factors that are important to achieving the goal.
5. Communicated: The purpose of metrics is to drive behavior. If you don't communicate their purpose, they won't drive behavior.
6. Current: Goals change. Keep the old measures and you'll achieve your old goals, not your new ones."

 

Thank you for reading "Dan on Estimating", if you would like more information about Galorath's estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. 2 Kinds Of Metrics: Status & Trend and Effectiveness First the obvious: : Status / Trend Metrics: e.g. productivity,...
2. Forrester’s Five Essential Metrics for Managing IT A recent report by Craig Symons of Forrester identified 5...
3. Metrics and Estimation ROI I was speaking with Ton Dekker and others from Galorath...

Galorath’s Sam Sanchez works extensively with IC’s and with understanding the cost if IC’s. He provided the following:

Over the past year or so, we have been doing FPGA (Field Programmable Gate Array) material cost research updates in support of our next SEER-IC release and I can’t help being shocked at the recurring costs of some of the higher end FPGAs in the market. Once you pass the simple lower performance items, you start to see a large escalation in the per piece cost.

I remember years ago being surprised to see chips priced at $200 to $800. Now, I regularly see midsized state of the practice chips that go for $10K a piece (and I am not even talking about the leading edge 28nm stuff). At times, I come across several orders of magnitude above this. I guess it’s the sign of the times.

These devices can do more but they do not come cheap. Focusing only on performance, we might say who cares. However, as cost is becoming increasingly more critical, these new technology costs have to be examined closely. If for instance, you are targeting a portable device with a specific recurring cost bogey, you need to carefully consider what these new chip technologies mean not just in development costs but also in recurring costs.  Depending on the size and amount of these FPGAs, their costs that dwarf all other BOM costs.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. FPGA Growth and Costing FPGA Growth and Costing by Sam Sanchez, Technical Director-Electronics Field...
2. SEER-IC Add-on To SEER-H Gets The Newest Technologies Galorath has just released a major update to SEER for...

The following is a summary by Galorath’s Chris Hutchings of the briefing  on January 6, 2012 by Mr. Frank Kendall (Undersecretary of Defense for Acquisition, Technology, and Logistics) regarding the Strategic Guidance given by the President, the Chairman of the Joint Chiefs of Staff (Gen. Dempsey) and the Defense Secretary (Mr. Panetta).

• While the specifics on how the defense strategic guidance will affect the Pentagon’s budget are not yet known, it is intended that there will be a reduction in the region of $487 billion over the next ten years
• The US will continue to meet its global responsibilities, albeit in manner more aligned to the current and emergent requirements and constrained budgets. Specifically, non-priority capabilities including ‘protracted, large scale operations’ will be reduced while investments will be made in technologies that provide ‘an agile and decisive edge against all threats,’ including Cyber Warfare and Intelligence, Surveillance and Reconnaissance.
• Technology supremacy is seen as an integral part of a progressive strategy and, as such, those within the industrial base that develop and support such technology are central to the success of the strategy
• A significant emphasis was placed on a requirement for continued operational readiness of a smaller, leaner force that is easily regenerated and mobilized to meet the following primary aims –
  • Strategic deterrence
  • Defeat threats from terrorist organizations, including al Qaeda. He highlighted the use of Special Forces in this area.
  • To react and defeat an immediate aggressor, while being able to ‘effectively inhibit the activities’ of a second aggressor
  • In line with the ‘better buying’ initiatives of Deputy Secretary of Defense (Carter), the strategy will include mechanisms to incentivize industry to become more efficient
  • Attention was drawn to two areas of specific risk to the success of the strategy, namely –
    • Industry must be, and act as, a part of the solution to the challenges that the Pentagon faces
    • Sequestration, a real threat to the aims of the strategy

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. Defense Acquisition Guidebook From DAU The Defense Acquisition University has released an update to its...
2. A Business Imperative for Change From the Taskforce on Defense Acquisition Law and Oversight This document analyses Government Acquisition Reform and was developed by...
3. Ash Carter Memo re: Efficiency & Productivity in Defense Spending — “Should Cost” vs. “Will Cost” The Ash Carter memo dictating 23 principal actions, “Implementation Directive...

I am working on a paper for NASA’s project manager conference.  In the course of this work I again reviewed the interesting work performed by Dr. Joe Hamaker while he was head of cost for NASA in establishing cost uncertainty before parametric models like SEER were used, and again after the system had been more finely modeled.

Like TRLs, CRLs are designed to communicate the quality of the product—its fitness for use. CRLs have been constructed to run the same 1 to 9 ordinal scale as TRLs, except we pay little attention to cost estimates at CRL 1-3.  In the case of CRLs, it is the quality of the cost product itself—the estimate’s fitness for use –that we are measuring

Joe equated cost readiness levels to technology readiness levels (TRL) to cost readiness levels and came up with the following:

Cost Readiness levels (CRL)

CRL 1, 2, 3: Not ready

CRL 4: Cost fit for very preliminary engineering decisions and very preliminary budget use (+/- 45%)

CRL 5: Cost fit for preliminary engineering decisions and preliminary budget use (+/-35%)

CRL 6: Cost fit for PDR engineering decisions and PDR budget use (+/- 25%)

CLR 7: Cost fit for firm engineering decisions and firm budget constraints (+/-15%)

CLR 8: Cost fit for very firm engineerin decisions and very firm budget commitments (+/-5%)

CLR 9:  Actual cost of completed project

Technology Readiness Level Definition

The goal of technology readiness level is to categorize hardware, software, or system concepts as to their maturity.  The following are definitions for TRL.  TRL 1 is barely a gleam in the engineering eye while TRL 9 is proven, operational technology.  The folllowing are definitions from NASA.

TRL 1 Basic principles observed and reported: Transition from scientific research to applied
research. Essential characteristics and behaviors of systems and architectures. Descriptive tools
are mathematical formulations or algorithms.
TRL 2 Technology concept and/or application formulated: Applied research. Theory and
scientific principles are focused on specific application area to define the concept. Characteristics
of the application are described. Analytical tools are developed for simulation or analysis of the
application.
TRL 3 Analytical and experimental critical function and/or characteristic proof-of-concept:
Proof of concept validation. Active Research and Development (R&D) is initiated with
analytical and laboratory studies. Demonstration of technical feasibility using breadboard or
brassboard implementations that are exercised with representative data.

TRL 4 Component/subsystem validation in laboratory environment: Standalone prototyping
implementation and test. Integration of technology elements. Experiments with full-scale
problems or data sets.

TRL 5 System/subsystem/component validation in relevant environment: Thorough testing
of prototyping in representative environment. Basic technology elements integrated with
reasonably realistic supporting elements. Prototyping implementations conform to target
environment and interfaces.

TRL 6 System/subsystem model or prototyping demonstration in a relevant end-to-end
environment (ground or space): Prototyping implementations on full-scale realistic problems.
Partially integrated with existing systems. Limited documentation available. Engineering
feasibility fully demonstrated in actual system application.

TRL 7 System prototyping demonstration in an operational environment
(ground or space): System prototyping demonstration in operational environment. System is at
or near scale of the operational system, with most functions available for demonstration and test.
Well integrated with collateral and ancillary systems. Limited documentation available.

TRL 8 Actual system completed and “mission qualified” through test and demonstration in
an operational environment (ground or space): End of system development. Fully integrated
with operational hardware and software systems. Most user documentation, training
documentation, and maintenance documentation completed. All functionality tested in simulated
and operational scenarios. Verification and Validation (V&V) completed.

TRL 9 Actual system “mission proven” through successful mission operations (ground or
space): Fully integrated with operational hardware/software systems. Actual system has been
thoroughly demonstrated and tested in its operational environment. All documentation
completed. Successful operational experience. Sustaining engineering support in place.

Part 2 of the CRL blog will be published soon.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. CECIM: A Capability Improvement Model For Cost Engineering Being a major fan of repeatable process for cost and...
2. Oh Glorious Day.. Weapons System Decisions To Be Made Based On Total Life Cycle Costs The October 13 2008 issue of Federal Times has a...
3. NPD 1000.5 NASA Cost-Risk Directive Just about hot off the presses (January 2009) is NASA’s...

Here is the summary of the questions and responses from 2010 that were obtained regarding the APMP task force charter to make government and industry work better together in cost analysis.  This is posted in advance of the task force telephone conversation on December 21, 2011.

If you would like an invite to that call or would like to join the task force please email Dan Galorath.

Probe further into causes for differences between Industry proposed costs and Government evaluated most probable costs

Understand differences in the approaches behind developing Industry cost proposals and performing Government cost evaluations

Identify contradictory assumptions

Industry

How do you determine the price you will propose?

What type of estimate do you prepare?

How far down in the WBS do you prepare it?

Government

 

When preparing your internal estimate, what is your technical baseline?

How detailed are your estimates, e.g., level of WBS? What are your estimating methodologies? What is your historical data?

Would you consider providing this information to industry as part of the solicitation request, especially if there is an incumbent?

Why discrepancies might exist

What might industry do to provide a realistic cost proposal?

What might government do to receive a realistic cost proposal

Industry

 

What types of assumptions do you make to support your estimate?

Do you clearly define these as assumptions?

Do you desire more information from the Government?

How much detail do you provide to substantiate your price? Do you prepare detailed justifications?

Government

 

How much detail is needed to substantiate bidders’ cost?

Is there a format that you might like to see this information in so that you can compare apples-to-apples?

Cost Proposal Substantiation

What might industry do to provide more consistent substantiation?

What might the Government ask for to ensure that it gets the level of detail it is seeking?

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related posts:

1. APMP Cost Task Force: Improving Cost as Part of Proposals to Government I have recently accepted the chair position with  Association of...
2. APMP Cost Taskforce November 2011: Helping Calm the Storm of Budget Cuts Via Cost Analysis During the November 2011 meeting the APMP cost task force...
3. US Government IT Spending Dashboard The new government CIO has started a site showing the...

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 or call us at +1 310 414-3222.

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

Frank Vogelezang of Ordina‘s presentation at the Galorath conference in the Netherlands yielded numerous interesting and well prepared presentations by customers and partners.  The presentation included here:  Estimating & Pricing of Application Management covered the processes for estimating what the problem will cost and the separate processes for pricing what will be charged to the customer.

Estimation Vs Pricing

Estimation was described as an engineering discipline while pricing was described as a commercial discipline that leads to a structure optimized to win the deal with an offering that meets customer acceptance criteria.

SEER Validation of the COMPLETE SYSTEM

The part I found even more interesting was the SEER validation included within the paper.  This validation compared the IT total system cost, including software development estimated by SEER-SEM, IT infrastructure (hardware, bandwidth, etc.) and IT services estimated by SEER-IT, and other (pass through) items estimated via manual processes.  The results were good even before any calibration, and even better after they calibrated with some of their history.

One Size Fits All Models Versus SEER

Frank pointed out the risks of using simple cost estimating relationships for estimating and defined the reasons why they choose SEER including:

• The estimating model needs to have a breakdown structure that can accommodate different cost-drivers
• Requirements for a supporting tool: Ability to facilitate a breakdown with different cost-drivers Based on experience data
• Possibility of calibrating the data with own experience