I often say, “What do I do with this information–it is now ancient history.”

The paper “The Canary in the Mineshaft: Key Indicators for success in aerospace and defense programs” discusses trending based on leading indicators:

• Trend in estimated schedule  to complete (ETC)… ranges in estimates of time to complete, then Monte Carlo analysis based on the uncertainty
• Trend in net present value (NPV)… Value provided by this program, again based on a range… This factors in the cost to complete, maintenance and ownership costs as well as revenues derived

Their point is if the trend in variance of range estimates of the above items is getting smaller, risk is being reduced and if the trend is getting larger risk is increasing.

They wisely use a definition of risk that equates it to uncertainty rather than discrete risks in this context.

Related posts:

1. Risk Analysis & Conference In the Netherlands I spent this week with our international group… at two...
2. Estimating Project Risk Using Scenarios (Without Monte Carlo) I was at a costing syposium today where Paul Garvey...
3. Douglas Hubbard on Pushing The Boundary In Risk Management If you follow my ramblings you know I am a...

I am often surprised when speaking to people who say, “We don’t need estimation or planning any longer because we are agile.”  I suppose that may be true for very small projects.  But for projects of any significance, it is not enough to tell stakeholders who need to budget and plan for delivered software that we will tell you we are done when we get there.  Estimation at the macro level is required so the overall project scope is understood as well as at the lowest levels for developers to commit to their work in a sprint.

Related posts:

1. Estimation & Agile Development… Plan and Control Agile Projects While at the IBM Rational user conference in Orlando I...
2. Agile Development Mature Scrum Thanks to Tom Gilb for the article on a CMMI...
3. Peaceful Coexistence of Agile Development and CMMI In the SEI paper “CMMI or Agile: Why Not Embrace...

1. Critical IT Systems present significant risks to organizations
2. IT estimating processes are core to reducing risk
3. IT estimation & metrics can help mitigate risk & empower program managers to be successful

PS:  I also got a little R&R in, scuba diving about 100 kilometers outside Manila.  Beautiful diving and very unusual dive boats… This is the exact style, but not the actual boat we dove from.

Related posts:

1. Estimation Plus Process and Measurement Rigor Yields More Successful Projects: SEER and Tracer It has been rewarding working with the Computer Aid  (CAI)...
2. Software Sizing, Estimation, Risk Management Book Available in Japanese I received copies of the book Software Sizing, Estimation, and...
3. Viable Software Estimation Modeling: A Key Component Of Software Risk Management I spoke with someone recently who explained the reason they...

“Since 2005, Forrester has argued that the best IT spending benchmark is not overall IT spending as a percentage of revenue, but rather IT spending on ongoing operations and maintenance relative to revenues — what we have called IT MOOSE. We believe that IT MOOSE as a percentage of revenues is a more accurate and useful benchmark than other commonly used ones, such as IT spending as a percentage of company revenues, IT spending per employee, or IT staff as a percentage of total employees.”

In the financial sector, for example MOOSE in 2007 was around 8.2% with a median of about 5% with MOOSE being abut 66% of IT spend.

In government and public services MOOSE was about 6.8% average and 5% median with MOOSE being about 72% of IT spend.

The MOOSE metric allows organizations to clearly assess “Are we getting more or less efficient over time” (MOOSE going up or down)

The original article covering IT spending may be found at this link.

Thanks also to Frank Vogelezang for pointing out this excellent report.

Related posts:

1. DoD CIO Approves Open Source Software.. But Beware of Low Cost Assumptions The DoD CIO’s office clarified its position on open source...

I have spoken to some customers that are offended by the term Price-To-Win.  They hear it as “trick the customer to win.”  Of course that is not what price-to-win is all about.  Price-to-Win is about choosing the most affordable alternative that fulfills the customer need and that also will be successful against competition.

Price-To-Win Goals

Price-to-Win identifies the correct balance of capability that can be delivered to the customer at the value the customer wants. Price-to-Win provides management insight for:

• Competitive positioning
• Strategic partnering
• Risk tolerance
• Customer relations
• Optimal bid strategy

This information is derived by:

• Market inputs
• Engineering identification of viable alternatives
• Engineering architectural design of each alternative
• Cost and risk analysis of alternatives and risk alternatives
• Price analysis (cost and price are two different issues)

Price-To-Win 8 Step Process

Step 1: Gather market intelligence: Marketing personnel identify competitors possible strategies and

Step 2: Determine requirements & features

Step 3: Sketch out Architecture Design

Step 5. Determine viable alternatives

Step 6: Cost Analysis & Estimation of Alternatives

Step 7: Select best alternative

Step 8: Establish price

Galorath Role in Price-To-Win

Galorath and SEER primarily support the estimation and analysis of alternatives, taking inputs from engineering, marketing and others.  The result of this includes cost and cost risk.  Once that cost is determined, price analysis will determine the actual price to bid. This price may vary significantly from the cost based on business decisions.

Related posts:

1. Price-To-Win Costing Roles and Responsibilities Step 1: Gather market intelligence: Generally the Senior Price-To-Win cost...
2. Better Products At better Margins 20 to 40% Cost Price Reduction I was so impressed with the presentation by one of...
3. New “Bid To Win” Book Available For Download Galorath’s Evin Stump and SEER customer �Bill Vitaliano wrote an...

Step 2: Determine requirements and features – while this is primarily the job of the engineer/systems analyst, the cost analyst cannot simply take these parameters and run with them.

Step 3: Sketch out Architecture Design – in all systems, but particularly in IT/software projects, a systems design document is critical. If the customer cannot provide one, the cost analyst should attempt to offer one for consideration/critique. This maps into the technical baseline task from the estimation process. This step will often reveal the real inclusion/exclusion rules and the critical operating instructions.

Step 5: Determine viable alternatives - this step is sometimes optional, as the project may want to evaluate only one option (their plan) at the beginning

Step 6: Cost Analysis & Estimation of Alternatives – once the “real” criteria are understood (steps 1 through 5), a more traditional cost analysis can be accomplished.

Step 7: Select best alternative – this is normally done by the customer

Step 8: Establish price – not normally the job of the PTW analyst as this is a business decision

Related posts:

1. Price To Win: What It Is And When Estimation Gets Involved I am continually amazed at the wide variety of opinions...
2. Frank Vogelezang Pricing Vs Costing & Proof That IT Systems Can Be Estimated Frank Vogelezang of Ordina‘s presentation at the Galorath conference in...
3. Better Products At better Margins 20 to 40% Cost Price Reduction I was so impressed with the presentation by one of...

A viable, repeatable estimation process is a cornerstone of a successful project.

Related posts:

1. The Estimate Maturity Model Can Improve Project Success Dan Galorath briefed the Galorath estimate maturity model, a method...
2. Many Observed Incorrect Implementations of CMMI High Maturity At the CMMI conference a number of difficulties with high...
3. Book “Software Sizing, Estimation & Risk Management” Is Now Available Electronically Dan’s book, Software Sizing, Estimation & Risk Management, is now...

The most striking conclusions from my viewpoint were:

• Most forms of testing only find about 35% of the bugs that are present

• Static analysis prior to testing is very quick and about 85% efficient

• Static analysis tools find many defects and code violations and have an ROI on any serious project

• Use of static analysis tools BEFORE manual peer reviews (which shouldn’t be completely eliminated based on static analysis) reduces cost and increases reliability

• Use static analysis tools before security analysis tools.  This reduces the effort in security analysis by a huge amount.

• QUALITY is the biggest driver of sustainment cost
• The FOUNDATION of SECURE software is QUALITY software.
• Software Assurance is 5 parts Code Quality with 2 parts Software Security.
• Code Quality scans should ALWAYS precede Security scans
• Improves effectiveness and efficiency of the security scans (e.g., remove ‘false positives,’ focus on highest risks, etc.)
• Recommended Best Practice
• Validated by MULTIPLE reports and analyses based on hands-on experience
• Discovers risks in addition to security (e.g., performance)

John points out that Static code analysis, Static security analysis, Dynamic code analysis, Dynamic security analysis, and Architectural analysis are all helpful in building secure software.

Related posts:

1. Quality Assurance As The Scapegoat.. And Putting Quality In The Hands of Developers I was at a best practices seminar in Toronto today....
2. Real Quality Assurance By Tom Gilb Tom is a real software visionary.. .Actually, Tom is the person...
3. Common Criteria For Security SEER estimates the costs of the various levels of the...

This briefing also touches on the Carter DoD “Better Buying Initiative” and affordability analysis to provide “will cost” analysis.

Related posts:

1. DoD Affordability: Implementing Directive For Ash Carter Initiative A lot of people are interested in DoD’s initiative for...
2. Bottoms Up Parametrics And Ever Increasing Details Our SEER for Manufacturing (formally SEER-DFM) and now abbreviated SEER-MFG,...
3. Data Driven Estimating Part 1: How Data Feeds The Estimation Modeling Paradigm at Galorath / SEER Lee Fischman’s article on data driven estimating follows: Summary Galorath...

Technical Debt:

the future cost of known defects in production that need to be fixed; a component of the cost of ownership:

• Principal: cost of remediating problems in production code that need to be fixed
• Interest: continuing IT costs attributable to the problems in production that need to be fixed, such as higher maintenance costs, greater resource usage, etc.
• Liability: mission costs related to outages, breaches, etc. related to production problems that need to be fixed
• Opportunity cost: benefits that could have been achieved had resources been put on new capability rather than retiring technical debt

Related posts:

1. $500 Billion IT Debt For Deferred Maintenance Gartner Group has reported that the IT Debt is about...
2. ScrumMaster and Techical Debt Technical debt can be reduced by ensuring “done” is a...
3. The Future of Software Analysis Measurement Webinar Featuring Bill Curtis, David Herron and Dan Galorath We have some exciting events coming up this month with...