Estimating United Conference Papers Available On the Web
Follow this link to see some of the estimating united papers. it was a great conference, full of useful information. Talks encompassing cost estimating (cost estimation), value engineering, product design, software, and more.
And thanks again to all the speakers and attendees as well as the hospitality of the Manchester United Football (soccer) club. And the Galorath staff whose diligent efforts made this a great success. Presentations will be available for all to download for the next few months, then will be available as part of the Galorath corporate library.
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.
Why Do Estimation Webinar With Geoff Hewson and Dan Galorath
I have had a good time developing a webinar with Geoff Hewson of the Software Productivity Center. It should be very informative and hopefully entertaining as well.
Register by clicking
Date and time: Tuesday, March 10, 2009 8:30 am
Pacific Daylight Time (GMT -07:00, San Francisco)
Description: Software estimation, planning and control can be keystones to successful projects. Companies that estimate strategically are able to zero in their projects so they deliver to business targets. Despite this many treat estimation as a black art or worse – a guess.
Dan Galorath and Geoff Hewson will explain the key concepts that drive successful software estimation in support of planning and managing successful software development and maintenance projects:
1. Decisions and deliverables needed to design estimation procedures tuned to your organization.
2. Guidance in setting up the infrastructure you need to realize the most benefit from your new estimation capabilities.
3. Establishing a “negotiating culture” to allow you to deal effectively with the results of your estimates and focus projects on business success.
SEER for Software concepts will support the discussion.
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.
Peaceful Coexistence of Agile Development and CMMI
In the SEI paper “CMMI or Agile: Why Not Embrace Both“ a truce between Agile and CMMI is called for. The abstract of the document follows: “Agile development methods and CMMI (Capability Maturity Model® Integration) best practices are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using both and exploit synergies that have the potential to dramatically improve business performance.”
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.
Estimating the 10 Hidden Costs of Packaged Software Implementation
Galorath is sponsoring a webinar covering estimation of packaged software implementation. This is a topic that I am excited about. I see organizations constantly assuming they can buy software and install it for free. And that they can tailor packaged software in an instant. The truth is implementing, deploying, tailoring packaged software is expensive.  Most often worthwhile, but not the no-brainer people think.  For example I recently spoke with an organization that took a YEAR to implement a CRM system. Their CEO tells horror stories and how they did not have the concept for the difficulty both in deployment and in dealing with change.
Date and Time
January 27, 2009
8:30 am, Pacific Standard Time (GMT -08:00, San Francisco)
11:30 am, Eastern Standardt Time (GMT -05:00, New York)
10:00 pm, New Delhi, India (Standard time zone: UTC/GMT +5:30 hours)
12:30 am, Tokyo, Japan (Standard time zone: UTC/GMT +9 hours)
4:30 pm, London, England (UTC/GMT)
——————————————————-
To register for the online event
——————————————————-
This event requires registration with a corporate email address.
1. Go to https://galorath.webex.com/galorath/onstage/g.php?t=a&d=925898160
2. Click “Register”.
3. On the registration form, enter your information and then click “Submit”.
Once the host approves your enrollment, you will receive a confirmation email message with instructions on how to join the event.
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 for Software Quick Start: Sizing an Entire Corporate Software Portfolio in Less Than One Week
Save Time and Money on Your Next Software Project with SEER-SEM’s Function Based Sizing
tWe hear, so often…. “We need to estimate our entire portfolio… and we have no time, and we have no function point counts” SEER users generate rough estimates of size, then cost, schedule, risk, and value with the SEER suite and a simple process, making this task not only possible but quick and easy.
Read more
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.
Automated Versus Manual Estimating
Having been in the industry for decades I have seen a lot of projects get into trouble with inadequate estimating. Watching the estimation methodologies (or lack therein) I have seen a variety of techniques. Over the years, analyzing these I have made several observations:
Developers are not too bad at estimating what it will take to make the software do what it should (the go path)… They are not so good at estimating what it will take to make the software not do what it shouldn’t.
- Manual estimates can very greatly even from the same person, depending on their current frame of mind.
- People have poor memories as to what it really takes to build and deliver acceptable software.
- Estimating effort directly (e.g. that take should take 3 months) rarely produces an optimized plan.. And without repeatability no one can figure what went wrong.
- Manual estimates at the lowest (1-2 week) level can actually make projects take longer since tendencies are to estimate those tasks at a higher probability and use all the time, even when things go well.
- Parametric estimating provides a language, methodology, and repeatability to the process.
- When people don’t want to take the time to estimate their project is already in trouble.
- Agile projects don’t eliminate the need to estimate. Stakeholders are not comfortable with “we will be done when we are done” answers.
The folllowing table summarizes some of the estimating methods:
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.
Step Ten: Track Project throughout Development
Refining Estimates throughout Project
Estimating software size, cost, and schedule should be an ongoing process. Preliminary estimates may be required to bid a job or to initiate the development process, or you may need to conduct a cost-benefit or return-on-investment (ROI) analysis to evaluate a project’s feasibility.
Preliminary estimates are the hardest to develop and are the least accurate because of the incomplete nature of the information available and the other factors discussed.
You can improve the accuracy of a preliminary estimate by using the sizing methodology identified in Step 4 or by using two different estimation techniques and having your analysts normalize the differences. There will still be a significant risk in using the preliminary estimate to structure a project or to evaluate risk in the early stages of a project life cycle.
Once a project has started, you will need to complete more detailed estimates to accurately plan the project and throughout the conduct of the project you will need to monitor the actual effort and duration of tasks and/or phases against planned values to ensure you have the project under control.
Summary
Software cost estimation is a difficult process but a necessary part of a successful software development. You can help ensure useful results by adopting a process that is standardized and repeatable. Several of the steps we have discussed, particularly those that do not result directly in the production of the estimate (Steps 1, 6, and 7) are often deferred or, worse still, not performed at all, often for what appear to be good reasons such as a lack of adequate time or resources or a reluctance to face the need to devise a plan if a problem is detected. Sometimes you simply have more work than you can handle and such steps don’t seem absolutely necessary. Sometimes management is reluctant to take these steps, not because the resources are not available, but because managers do not want to really know what they may learn as a result of scoping their estimates, quantifying and analyzing risks, or validating their estimates. This can be a costly attitude, because in reality every shortcut results in dramatic increases in project risks.
Previous:
Step Nine: Document Estimate and Lessons Learned
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
