The Risk of Statistical Risk
I was at the SCEA (Society of Cost Estimation and Analysis) conference this week. Some of the buzz was about risk, both talks given at the conference and the ongoing risk arguments. For several years the risk gurus have been lining up to show how to do more robust risk analysis. While I would not say they are getting carried away I would say i get concerned with the differences of opinion and the numerous options provided by smart people.
One of my heroes in risk, Dr. Steve Book or MCR points out that risk analysis should include correlation.
One of my other risk heroes, Evin Stump (of Galorath), points out that defining correlation properly for a work breakdown of any size can involve of thousands of correlation entries. For example a 500 element WBS has 124, 500 correlations and a 1000 element WBS has 499,000 correlations. Dr. Book doesn’t point that out but he does say “use .2″ That solves the hundreds of thousands of correlations issue. But according to Evin that doesn’t provide more accurate risk analysis. Evin points out “if two or more risky items are not statistically independent, a Monte Carlo simulation that fails to account for their correlation will underestimate their combined risk” He then asks “what if you overestimate correlation?” Hmmm could it be that .2 correlations could overestimate some systems. Evin also points out how difficult it is to actually determine correlation…. For example, what is the correlation between a light bulb and a light bulb on/off switch… Probably near zero but most people would be tempted to assign a high correlation. 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.
Bottoms Up Parametrics And Ever Increasing Details
Our SEER for Manufacturing (formally SEER-DFM) and now abbreviated SEER-MFG, uses what we call bottoms up parametrics.. Bottoms up parametrics differ from general parametric estimation modeling in a few respects:
- Bottoms Up Parametrics Don’t Necessarily Minimize the Number of Inputs
- Bottoms Up Parametrics ask for detailed levels that traditional parametric estimating would not.
I was briefed on a new tooling analysis method that actually allows the user to specify specific tools if they want to. Way more detail than a traditional parametric model. But exactly what the bottoms up people desire.
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 Development Metrics At Galorath: Co-located Teams Are Still Most Efficient
Our Development Vice President, Karen McRitchie and myself had an interesting review of development productivity in our own organization. Very interesting, but no surprises.
She found that the most productive projects are those where the team is co-located. There is a productivity hit when the team is geographically disbursed. Of course SEER for Software estimates reflect this with their multiple site parameter. But some people, even within Galorath, attempt to deny this phenomenon. 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.
Total Cost of Ownership: Development is (only) Job One
Planning software development projects is never an easy undertaking. Customer and competitive requirements, time-to-market, architectural and quality considerations, staffing levels and expertise, potential risks, and many other factors must be carefully weighed and considered. What can make software planning even more complicated, however, is that software development costs only comprise a portion – often the smaller portion – of the total cost of software ownership. In fact, the development process, itself, invariably has a significant impact on total cost of ownership as tradeoffs are evaluated and compromises made which impact software sustainability and maintainability of software over time.
Because software doesn’t wear out like car tires do, software planners may underestimate how much a code stream can degrade over time with the accumulation of patches, system and configuration changes, provisioning and re-provisioning, integrations, and ongoing development. Further, the rigorous standards applied during initial software development may end up being compromised as maintenance personnel are diverted to emerging or mission-critical software issues. Over time, accumulation of poorly managed changes almost always generates software instability and a significant increase in the cost of software maintenance – up to four times the cost of initial development, according to some estimates.
This session will provide a systematic approach to addressing total cost of ownership across the software lifecycle, including design for maintainability, development of measurement criteria, collection of metrics, and industry standards, guidelines, and best practice options. Parametric modeling will be discussed using the SEER platform as a specific example of this approach. Estimating block changes and their potential interdependencies and impacts will also be covered.
Click here to see the slides.
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.
10 Step Estimation Process Overview
Viable estimation is critical to successful software projects whether it is agile, waterfall, or anything in-between. In the book “Software Sizing, Estimation, and Risk Management: Where Performance is Measured Performance Improves” we lay out the process. This can be used in a formal way for high maturity organizations AND can be used as a general basis of organizations just getting started in improved planning. There are many documents and presentations available from Galorath on this topic. I find the IBM paper by Dr. Denton Tarbet of Galorath an interesting visual representation. And a short summary of the process is included as this link. 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.
Software Sizing, Estimation, Risk Management Book Available in Japanese
I received copies of the book Software Sizing, Estimation, and Risk Management: When Performance is Measured, Performance Improves, translated into Japanese. I don’t know the link to purchase the Japanese version yet. The English version may be obtained via http://www.amazon.com/Software-Sizing-Estimation-Risk-Management/dp/0849335930/ref=sr_1_1?ie=UTF8&s=books&qid=1213648096&sr=8-1
I am honored that the Japanese publisher found this book valuable enough to translate and look forward to much dialog with Japanese speakers on this. I originally envisioned this book as the elements fo software sizing. The publisher thought it would be better to include estimation as well. Mike Evans, my coauthor, thought we should do this as a series of three books. We had another book planned “7 Characteristics of Dysfunctional Software Projects” when Mike became terminally ill. Mike thought that book should still be written but I haven’t been able to bring myself to write that book without Mike.
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.
Pioneers of Parametrics (MIT) Paper Available
Interesting (at least to people like me) paper on the “Pioneers of Parametrics” By Ricardo Valerdi of MIT. Kind fo a history of parametric estimating. There are a few things that I am not sure are exactly correct (certainly all of our memories are blurred by time) but it is generally a good history.
I think the real takeaway is that the concepts of parametrics (this paper focused on software estimating) have been refined since the 1960′s. My involvement began in 1976 with serious concenration beginning in the early ’80s (just before the COCOMO book was published) when Don Reifer and myself studied the problem for NASA and I am grateful for the work of System Development Corporation, Halstead, Doty, Putnam, and others whose work preceeded my involvement and to the many people who have refined this into a science, not just and art, since that time… People like Barry Boehm, Randy Jensen, Karen McRitchie, and others.
http://web.mit.edu/rvalerdi/www/Pioneers%20of%20parametrics%20(Valerdi)%20ISPA%202007.pdf
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 Helps Avoid “Fact Free Planning”
While at a conference last week someone discussed “fact free planning”. I had not heard the term before but was intrigued. Fact free planning goes back to an article by MIT’s Sloane School, “How Project Leaders Can Overcome the Crisis of Silence”.
Fact free planning happens, in part when someone (business development, executive, etc… not one with project team responsibility) makes commitments to stakeholders. The article discusses how such behavior in part spawns padded estimates.
Many times project schedules and budgets come down from above without regard to project realities.
Project people pad schedule and cost estimates expecting them to be ignored or changed anyhow. Then when several levels of managers pad or cut feeling that the estimates have been padded any semblance of reality becomes lost.
The authors go on to discuss how unhealthy organizations attempt to avoid conflict and how that conflict avoidance hides problems.
One fix for fact free planning is an environment where participants are safe in communicating truth. SEER attempts to eliminate fact free planning by providing estimates: simulations of project realities based on ranges of probable outcomes.
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 Project Failure Costs Billions.. Better Estimation & Planning Can Help
There are so many studies attempting to quantify the cost of software failures. They don’t agree on percentages but they generally agree that the number is at least 50 to 80 billion dollar range annually.
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.
Microsoft Partners
You might want to checkout www.Partnerpoint.com which supports Microsoft partners. 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.
Project Prediction Infographic
