Software Project Monitoring & Control
Galorath’s Dr. Denton Tarbet offers thoughts on Project Monitoring & Control:
Galorath’s SEER SEM with Project Monitoring & Control (PMC) option provides a simple tool to overcome the schedule prediction shortcomings of traditional Earned Value Management (EVM) methods. In particular since EVM expresses project performance in terms of cost, the method loses the predictability of evaluating schedule at complete (Schedule EAC). As Walt Lipke Points out[i], “Eventually all budget will be earned as the work is completed, no matter how late you finish. The Schedule Variance improves as the project progresses and ends up with $0 variance at the end of the project.” Recall that SV = BCWP – BCWS which by definition will be 0 at the end of the project and the SPI will be 1.0.
To overcome that issue it is necessary to develop an earned schedule concept, with some additional effort. In lieu of adding effort to the EVM process, simply incorporating the EVM metrics as snapshots of project performance into the SEER PMC tool using the project model developed for the initial project estimates provides output that parallels the EVM output for cost and schedule, but the value of the schedule projections is retained throughout the project. PMC forecasts a realistic schedule variance from plan in terms of schedule metrics which is calibrated to reflect the actual accomplishments. In addition, it can be demonstrated that PMC provides the project control feedback to project management to provide a method to evaluate alternative options designed to improve project performance in an attempt to improve project schedule performance.
Robert Hunt, et al provides a relevant discussion of EVM on software intensive projects[ii]. Additional white papers and referenced articles on the Galorath website provide more detailed discussion related to using SEER SEM and PMC to develop and manage a successful software intensive project[iii].
[i] www.earnedschedule.com/Docs/ES%20-%20an%20extension%20to%20EVM%20EVA-10%202005%20Lipke
[ii] Data & Analysis Center for Software (DACS) Software Tech News –EVM issue (Volume 12, No. 1) DACS Software Tech News
[iii] http://www.galorath.com/search_results.html?q=EVM&cx=016648429445878925337%3Ajnoaofuymoe&cof=FORID%3A11&sa=Search#1304
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.
Lessons Learned On Major Engineering Program: Viable Cost Estimates Needed
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.
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.
$500 Billion IT Debt For Deferred Maintenance
Gartner Group has reported that the IT Debt is about $ 500 Billion, the cost of deferred maintenance with that number heading toward $1 Trillion over the next 5 years.
Gartner’s Andy Kyte defines IT Debt as “the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state.”
In its most simple form IT Debt could mean upgrading software from Windows XP to Win 7. In enterprise IT Debt could involve upgrades in ERP, business intelligence software or middleware.
The maintenance backlog has built up as a result of tight tech budgets over the last decade, cost-cutting measures or simply because the enterprise did not feel compelled to upgrade its application portfolio.
“Over the last decade, CIOs have frequently seen IT budgets held tight or even reduced. The bulk of the budget cut has fallen disproportionately on maintenance activities — the upgrades that keep the application portfolio up-to-date and fully supported. There is little problem if this is done in one year or even in two years, but year after year of deferred maintenance means that the application portfolio risks would be getting dangerously out of date,” said Andy Kyte.
The Gartner analysts said IT leaders should produce an annual report on the status of the application portfolio detailing the portfolio status, including:
- Number of applications in use
- Number of applications acquired
- Number of applications decommissioned
- Current and projected costs of operating, sustaining or improving
Technical Debt From An Application Viewpoint
Cast Software, makers of a very interesting static analysis tool, define technical debt a bit differently.
Technical Debt in an application is the cost of fixing the problems in that application that put the business at serious risk. Technical Debt includes only those problems that are highly likely to cause severe business disruption; it does not include all problems, just the most serious ones.
Based on this definition, they estimate that the Technical Debt of an average-sized application of 374,000 lines of code is $1,055,000.
Note: Technical debt chart from Ronald E. Jeffries
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.
Barry Boehm’s 1972 Predictions of Higher Software Costs Changed The Course of Computing
In working on a paper honoring Dr. Barry Boehm, I ran across this document which describes some of the trials and tribulations of the initial common high order programming initiative. One thing the article identified is Dr. Boehm’s report that software costs were going to outrun hardware costs and described high costs and unreliability. The report also described one of the major goals of the initiative was reducing software costs.
“The language should facilitate the reduction of software costs. The costs must be reckoned on the total burden of the life cycle including maintenance, not just the cost of production or program writing.”
Barry has done more to legitimize the science of parametric estimation than almost anyone, tracing its roots to 1972 or earlier.
Even SEER-SEM, which has roots seperate from Boehm’s COCOMO, can trace back to the time when it aligned some input parameters with Boehm’s definitions to promote consistency in the industry. And Barry has been very supportive of SEER over the years, including writing the forward of my book which is included below:
Boehm Forward to Galorath / Evans Book
Many people who acquire a software estimation model assume that its use involves furnishing it with a few project parameters, taking the resulting outputs, and plugging them into proposals, project plans, work breakdown structures, budgets, and schedules.
However, people experienced in software estimation have learned that running the model is just the small tip of a very large iceberg of activities essential to successful estimates, projects, and enterprises. Those activities include:
- Identifying what is being estimated and why. One early cost model’s answer to questions asking whether the model estimates included costs of management or quality assurance was, “What would you like the estimates to include?” This is not a strong confidence builder.
- Defining the project’s requirements and design as well as possible. If you don’t know whether a product function will be fulfilled by new, modified, or commercial software, your estimates can be way off.
- Using several perspectives to estimate software size, cost, and schedule. Otherwise, there is no way to tell whether your estimates are reasonably accurate or not.
- Identifying ranges of uncertainty in the project parameters. This enables techniques such as Monte Carlo analysis to determine the likelihood of finishing within a given budget or schedule. Just using a “most likely” point estimate will overrun roughly half of the time.
- Performing a business case relating estimated costs to estimated benefits and return on investment. Otherwise, scarce resources are likely to be spent on low-payoff capabilities.
- Negotiation of tradeoffs among cost, schedule, quality, performance, and functionality. Optimizing on one of these parameters at the expense of the others has been the source of many failed projects.
- Matching desired capabilities to available budgets, schedules, and skilled personnel. Neglecting this activity has been the source of many project overruns.
- Tracking not only cost and progress with respect to original cost and schedule estimates, but also changes in cost driver parameters. Tracking to obsolete estimates has been the source of many painful surprises.
The authors of this book, Daniel Galorath and Michael Evans, are both highly experienced estimators and project managers. Much of this book is devoted to their helping you understand and apply these “under the tip of the iceberg” activities. Their 10-step approach to software estimation provides a logical progression of estimation activities that help you avoid these sources of project overruns and failures.
The book naturally focuses on the use of Galorath Incorporated’s SEER-SEM software cost model to address software estimation activities. But it does so in the context of advice to use multiple perspectives in size, cost, and schedule estimation. And it provides a lot of valuable information about the SEER-SEM cost and size drivers that are often not available for proprietary cost models. It also shows how to use your estimation and project tracking data to improve your estimation accuracy and to identify best investments for improving your software productivity and cycle time. Investing in acquiring this book and following its advice is highly likely to provide you with a robust return on your investment.
Barry Boehm
Another veteran of the consequences of neglecting the bottom of the iceberg
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.
Ash Carter Memo re: Efficiency & Productivity in Defense Spending — “Should Cost” vs. “Will Cost”
The Ash Carter memo dictating 23 principal actions, “Implementation Directive for Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending,” uses the terms “should cost” and “will cost” in a somewhat unique way. When I first saw it, myself and others were a bit unclear as to what those terms meant in this context. It seems the definitions are:
Will Cost: What a system will cost based on business as usual. The efficiencies complexity, etc. will be as things have been done in the past. This is the ICE or independent cost estimate.
Should Cost: What a system will cost based on cost efficiencies that could (should) be applied. What if I engineered the system from scratch and made the cost efficiencies part of the affordability plan…
This is a big deal and takes the meaning to affordability to a new level.
Memo Outline
23 principal actions organized in 5 major areas
- Target Affordability and Control Cost Growth – Mandate Affordability – Drive Productivity Growth through Will Cost/Should Cost Management
- Incentivize Productivity and Innovation in Industry
- Promote Real Competition
- Improve Tradecraft in Services Acquisition
- Reduce Non-Productive Processes and Bureaucracy
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 failures Cost Billions Part 2
Note part 1 Software failures cost billions contains numerous studies, etc. I broke it into parts due to limitations of the blogging software.
From a British Computer Society study of 214 projects in the European Union between 1998 and 2005 by Dr John McManus and Dr Trevor Wood-Harper: Only one in 8 projects was successful, meeting time, cost and quality requirements.
Additionally schedule overruns ranged from 11 weeks to 103 weeks with cost overruns of 20 to 90%
Phase at Cancellation or Overruns
| Waterfall method lifecycle stage |
Number of projects canceled |
Number of projects completed | Number of projects overrun (schedule and/or cost) |
| Feasibility | None | 214 | None |
| Requirements analysis | 3 | 211 | None |
| Design | 28 | 183 | 32 |
| Code | 15 | 168 | 57 |
| Testing | 4 | 164 | 57 |
| Implementation | 1 | 163 | 69 |
| Handover | None | 163 | 69 |
| Percentages | 23.8% | 76.2% |
ISBSG Analysis from the book “Practical Software Project Estimation
449 suitable projects, the analysis in our Practical Software Project Estimation book made the following observations:
25% of projects met both estimates Schedule & Effort (within 10%)
23% underestimated effort and were delivered late
22% underestimated effort but estimated the delivery date accurately
13% overestimated effort (so it does happen!)
8% estimated the effort accurately but the project was delivered late
1% came in more than 10% below the estimate for both effort and delivery date
If a 20% leeway is allowed – 44% of projects came within that allowance for both estimates.
===============
Here is a blog covering IT failures by ZDNet
See Software Project Failures Cost Billions Part 1
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
