“Far Out” Estimating the Costs Of Satellites Far Into The Future
I had the opportunity to brief part of the space community on the latest release of the SEER Far Out model for cost estimating. Far Out estimates the costs of satellite systems far out into the future. Why would anyone want such an estimate, you may ask. Estimates of systems in the future made today can change planning and approaches for future generations of technology.
This capability is of interest to:
- Military space asset planners
- Government agencies
- Commercial satellite producers
- Advanced concept designers
I have been excited about this project ever since its research began several years ago. It needed to deal with technology readiness levels (TRL), that is how available is the technology being used for systems developed in the future.
Technology readiness levels are interesting since, when they are low, estimates are extremely difficult and will, by nature, have a large range. For example, if you asked Thomas Edison in 1876 how much and how long it would take to develop the light bulb, he likely would have had no clue before the basic carbon filament was invented. This was a TRL 1 problem. He had no good way to know how long it would take him to get the most basic technology to a level that would be adequate for a product.
In 1979, once the carbon filament was developed to TRL 4, Mr. Edison would have had a much easier time providing development and production estimates. NASA’s technology readiness level scale follows:
———-30————
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.
Better Products At better Margins 20 to 40% Cost Price Reduction
I was so impressed with the presentation by one of our speakers at the recent user conference that I bought a copy of his book. In his presentation(and also included on our site, galorath.com) he showed how he saved millions of euros in product costs using target costing, value analysis, and viable cost estimating and SEER.
It is wonderful to see forward thinkers applying SEER to save big costs as well as to estimate costs. In his presentation he substantiated savings of 20 to 40% cost price reduction (value improvement) And he does this not be grinding contractors but by working with them to provide substantial cost savings without impinging on their margins.
His book is well worth a read. The abstract follows:
“Many companies experience price pressure as a result of the global marketplace. The advance of technology creates many opportunities adding more innovative new features. Yet these opportunities also seem to drive up costs. How to end the resulting profit squeeze? Many aim for low labor cost countries as a solution.
Our approach is: Use Target Costing and Value Analysis.
Target costing sets allowable costs, derived from the value as perceived by customers, instead of price as a result of cost. Value analysis shows the way where the value of a product is, or where to reduce the cost. One of the key success factors in this approach is Cost Engineering and Cost Estimation. Another is multi disciplinary teamwork between marketers, developers, operations and suppliers.
The structured approach and open communication help achieve astonishing results, typically in the range of 20 to 40% cost price reduction or value improvement.
This book, or better Manual, describes how to apply and implement these methods in an organization, and how to involve suppliers efficiently and effectively via so called Design-in Workshops.”
It can be purchased for 69 Euros at www.orenda.nl
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.
Risk / Uncertainty In SEER and Project Management
The question was asked “what probability should I estimate at” The answer follows: Risk is really uncertainty. So the question becomes how much uncertainty can or should I allow in my project plans. There are many approaches to this, depending on circumstances including:
What are the consequences of an overrun: Many large military type programs in the US budget at a 70% or 80% probability. These kinds of programs are generally large and not well defined at the early planning stages. They use the higher probability so they don’t have to go back for more budget or schedule as the program progresses. These programs will generally manage to a 50% probability, using the overage as a buffer for program growth.
Is The Project Fixed Price: Many programs that must bid on programs at fixed price will initially estimate at a probability like 80% so that they are covered if the project becomes more complicated than their initial looks. Of course competitive issues may cause them to bid lower.
Is this an in house Project: Many projects will plan at a 50% (most likely) probability. This allows them to have a tough but achievable plan and if the project runs into difficulty they can adjust.
I recommend managing to the 50% probability… Tough but achievable schedule and effort.
Some projects Estimate at the 20% Probability: This is a lower cost / schedule plan that can win a contract. Unfortunately these projects usually overrun. But they have taken calculated risks.
I once heard of a program that was thrilled that the 1% probability met with their hopes for the program. So they had a plan with a 99% probability of failure.
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.
GAO Cost Estimating and Assessment Guide Released
Congratulations to the GAO team for releasing the “Cost Estimating and Assessment guide: Best Practices for developing and Managing Capital Program Costs”. This has been a work in progress for several years and represents a nearly superhuman effort on the part of the GAO team. Galorath is proud that is was able to assist in the guidebook development as well.
The guidebook may be downloaded here. And the press release from GAO follows:
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.
Life Cycle Cost Percentages of Weapons Systems
While at a conference this week I heard the presentation of a paper by Quentin Redman, Andrew Crepea, and George Stratton, all of Raytheon, that summarized the life cycle costs of various weapons systems. This table is reproduced below:
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.
Standard WBS For Space System Cost Estimating
The NRO cost group provided a Work Breakdown Structure (WBS) for costing their projects. As quoted from the introduction:
“The standard WBS was developed to capture the costs of any NRO program, whether it is an operational space program, technology demonstration program, ground station upgrade, or a system of systems. It is structured to accommodate varying levels of detail in available data. This allows data to be reported at either lower levels or at higher levels, if lower level data are not available. The wide range of system engineering, integration and test, and program management levels within the WBS is a prime example of how data are reported at many different levels within a program. The standard WBS is designed to allow data reporting at whatever level they are recorded. Because of this versatility, some WBS elements may be repeated, such as the case of a satellite system that operates with two ground stations. For this situation, the costs for each ground station are reported separately via WBS elements 1.3a and 1.3b, and all lower level elements for each ground station will sum up to their respective ground station. The same scheme applies to multiple and dissimilar spacecraft within a program, which will be reported separately as “spacecraft a” and “spacecraft b”. Thus, there may be a number of elements in the standard WBS that are irrelevant to any individual program, but are necessary for the database structure to account for a varying level of cost data on disparate legacy programs. If cost data are sparse, they still may be mapped into appropriate higher levels of the WBS”
And as Bryn pointed out: another one from OSD The OSD CAIG also has a mandatory cost and software reporting for specified programs – basically the big ones (DoD 5000-04-M-1, April 18 2007) – with a reference to mandatory WBS structure (Data Item Description DI-MGMT-81334, “Contract Work Breakdown Structure,”
current version). More info available at http://dcarc.pae.osd.mil
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.
Software as a Service vs. Service Oriented Architecture vs. Cloud Computing
I have seen a lot of confusion as to the definitions and interrelations between these three technologies. So…
Definitions:
Software as a Service: Software provides an application on-demand. There is no implied language, development methodology, or tool specifically attributed to SaaS. Some development methods may be more appropriate (such as Java and C#) since SaaS applications often provide the user interface a browser .
Service Oriented Architecture: (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. A SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Some organizations offer software as a service running on the organization’s private infrastructure as well.
Cloud Computing: Cloud computing is Internet (cloud) based use of computer technology where dynamically scalable resources are provided as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure (the Infrastructure as a Service cloud) that supports them...virtualized. Some call this “IT Infrastructure as a Service.” Some vendors refer to the “private cloud,” which is essentially virtualized local servers. Gotta love the buzzwords.
SaaS applications may use the cloud but they are not the cloud.
SOA architectures may or may not be delivered via SaaS but they are not generically SaaS.
Cloud applications may or may not be delivered as SaaS
SEER Estimates All These Technologies
SEER, by virtue of its parameters and knowledge bases, estimates all these categories of computing. But they are not synonyms.
SEER for Software captures the effort, schedule and risk of using a Service Oriented Architecture for development and maintenance.
SEER for Software captures the effort saved by using SaaS rather than software development,while SEER for IT captures the cost or savings of using SaaS rather than organic hardware.
SEER for IT captures the effort, schedule and risk of using / supporting / operating cloud computing versus SaaS computing.
PS This blog is published with a locally installed version of WordPress software. It is not SaaS, not the cloud (running on specific server resources we pay for) and not SOA. A blog could be delivered as SaaS or via the cloud.
PS2: I curse WordPress constantly... full of problems. But if it was SOA it would just share the problems more widely. SOA does not solve software development issues. SOA does potentially provide reuse which can get applications developed faster… By the way,with all the excitement over automatic updates with SaaS, that says you can’t depend on your computer doing today what it did yesterday.
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.
Some Gottchas of Estimating Service Oriented Architecture Systems (SOA)
As Fredrick Brooks said “there are no silver bullets.” Unfortunately the software industry continues to tout every incremental step as that silver bullet which will solve the problems of software development. Don’t get me wrong. SOA when applied in the appropriate environment can improve productivity. Galorath analysts have been using SEER to estimate SOA systems for some years now. The basic conclusions are 1) SOA can be the best approach to achieving interoperability and reusability and 2) SEER accurately models the effort, schedule, risk, cost of software development of an SOA system as well as the cost of the IT services and infrastructure to support them. But the reality must be modeled, not just vendor claims.
Grace Lewis, Et Al. of the Software Engineering Institute did a good job of identifying some of the misconceptions of SOA as follow:
SOA Does Not Provide a Complete Architecture: SOA provides a pattern for an architecture, not the whole system architecture itself. Hence you can’t really buy SOA off the shelf. You can buy SOA products to help.
Dan Woods of Forbes points out: “The problem is that most IT departments are used to running applications. We can think of them as automakers assembling a car from many different parts. The auto manufacturer makes sure that all the parts fit together and work as they should so the car runs well. The world of SOA lifts the hood of the car and breaks the rest of the car into parts, that is, individual services that can be reassembled. “
Migrating Legacy Systems Is Nether Automatic Nor Easy… There Are Significant Costs
The Use of Standards Does Not Guarantee Interoperability In An SOA Environment
Testing SOA Systems Is Harder: “Because an SOA environment is distributed, loosely coupled, and asynchronous, testing can be significantly more complex than simply testing a set of known paths in a single system.”
Gartner also raised up the caution flag stating that SOA deployments were slowing down as people begin to understand the real costs.
Also, Forbes Dan Woods post provides a sobering observation: with SOA, IT departments end up bringing much of the work formerly handled by software vendors in house. So for estimation purposes plan on doing more IT development and services in house… And plan on training, retaining, and equipping those personnel.
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.
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 story Titled “Better Estimates Urged for Weapons Programs” about John Young, Pentagon Acquisition Executive and his movement for “establishing life cycle metrics early in the acquisition process”
Galorath has been preaching evaluating total ownership costs, not just development, for years. And we understand the pressures to “get it out in the field to support the warfighter” Using all the SEER products such as SEER for Hardware, Electronics and Systemssupport total ownership costs and tradeoff analysis to determine the most effective system design and architecture from a set of alternatives.
We all realize that there are other issues beyond just total ownership cost to keeping our country and those in harms’ way safe. And I know that combining estimating of total ownership costs early and often can support that goal.
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.
SEER Estimate By Comparison Professional Released To All Users
The SEER Estimate By Comparison (formerly SEER-AccuScope) comes in two flavors, the core and the professional. The professional version allows estimation of anything, such as
- total system cost
- software size
- hardware weight
- system value
- server capacity
- best choice from a set of alternatives
This new feature incorporates sophisticated mathematics for uncertainty and estimation.
For the first year Galorath is providing the professional version to all SEER users. Beginning the second year the professional functionality will be available as an upgrade.
Galorath recommends using an industrial strength database for an enterprise but will allow Microsoft Access for simple desktop installations.
This feature began shipping with the release of SEER for Software 7.3, in October, 2008.
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.
Project Prediction Infographic
