Here is a copy of my keynote talk at the 2011 ISMA measurement conference, Measurement and Management and Business Value.  The real point is the IT and measurement personnel have the information, knowledge and skill set to provide value to the business, far beyond the costs generate.  But the information needs to be communicated in terms leaders can understand rather than the techie language we all think and speak in… AND if IT starts showing how it contributes to the business and becomes a profit center instead of a cost center IT will get more money to apply to more valuable things.

UPDATE: Someone also asked for a reference communicating the language of management.  I believe this publication on business case analysis to be helpful in that regard.

PS In my talk I referred to software and measurement people as geeks.  To many the term geek is a source of pride.  One person in the talk was offended by being called a geek.  My sincere apologies.  However modern vernacular often defines a geek as a lover of technology, a software developer or someone with an intense love of mathematics.  I consider myself a geek.  And my friend Paul Glen makes his living by “leading geeks.”

Related posts:

1. Galorath Keynote ISPA March 2011 Today my conference presentation involved understanding and estimating value in...
2. Issues in Software Measurement & Estimation ISMA 2010 Measurement is a wonderful thing.  However measurement without standards and...
3. Communicating with Management Via Measurement This is the abstract for my keynot talk at the...

This article is definitely worth a look: continuing studies that people underestimate the time and effort to perform all kinds of tasks.

This causes no end to issues in all kinds of systems: software, hardware, IT, manufacturing, student homework, you name it. One study did find that if people optimistically estimated the effort for a task and that task could be done in a single session, that productivity could increase.

Several factors reduce this planning fallacy. Preparing a risk management matrix can improve the underestimation of tasks. But planning fallacy is more prevalent in teams than with individuals.

The tendency to underestimate can be mitigated with estimation models.. so long as ranges and risks are defined.

Of course the reason we continue to study optimism in planning is to help ensure that people get good credible estimates from models – and when models and individual thinking disagree, that they are reconciled.

The paper covering procrastination and the planning fallacy is also a classic and worth a read.

Related posts:

1. SEER Helps Avoid “Fact Free Planning” While at a conference last week someone discussed “fact free...

I get so excited when an organization does a true business case and evaluates cost versus benefits of a software / IT system along with the risks.  . Part of the key is thinking and  analysing and communicating like a C llevel person rather than like a technical person.   Here is a link to the PowerPoint I did a webinar on this topic during July 2011 Establishing the ROI on Software Through Examination of Total Ownership Costs.  The full recorded webinar is available on the ITMPI site as well.

One might say that business case analysis is finance 101 and I would agree… Sometimes uncommon success is achieved by doing common things uncommonly well.

Related posts:

1. Government IT Project Woes and Estimating Total Ownership Costs A recent government report showed 81% of budget or $57...
2. Reducing Software Maintenance and Total Ownership Costs Over 75% of the costs of software are in software...
3. Software Measurement and Total Ownership Costs… Dan’s Presentation at the NYC SPIN I had the opportunity to present at the New York...

Secretary of Defense Gates announced design efficiencies that should reduce overhead costs, improve business practices and trim some defense programs.

“This Department simply cannot risk continuing down the same path – where our investment priorities, bureaucratic habits, and lax attitudes towards costs are increasingly divorced from the real threats of today, the growing perils of tomorrow, and the nation’s grim financial outlook.”

Tough decisions for tough times make cost estimating and analysis a key component. Gates stated his goal to have every defense dollar invested in the smartest manner. The efficiencies continue a process to reshape and re-balance the defense budget that has already saved the nation $300 billion.

Related posts:

1. Ash Carter Memo re: Efficiency & Productivity in Defense Spending — “Should Cost” vs. “Will Cost” The Ash Carter memo dictating 23 principal actions, “Implementation Directive...
2. DoD Affordability: Implementing Directive For Ash Carter Initiative A lot of people are interested in DoD’s initiative for...
3. SEER Quantifies Savings On Military FPGAs (Custom Chips) Altera used SEER for Hardware Electronics and Systems to quantify...

Be Proactive: Identify cost targets, Find ways of meeting conflicting goals, Acquire / Build and know your models

Begin With the End In Mind: Understand what the key cost and requirements issues are as well as the estimate goals

Put First Things First: Planning training, planning, substantiation

Think Win/ Win: Negotiate so costing/pricing/performance yield fair return Fixed price low bid may be a Lose/Lose Optimize alternatives for Cost Vs. Requirements & Performance

Seek First to Understand, Then to be Understood  Don’t just throw model inputs at stakeholders; understand the problem

Synergize: Combine knowledge/Resources with COTS Models; Use integrated product team approach to provide cost model inputs and feedback

Sharpen the Saw: Spend some resources to improve processes & tools

Related posts:

1. The 7 Habits Of Highly Effective Affordability Management Be Proactive: Identify Cost Targets, Find Ways Of Meeting Conflicting...
2. CostIQ Case-Based Reasoning Model For SEER Customer Order This week we received our first order for the official...
3. 7 Habits Of Unsuccessful Software Managers Don’t use a specific methodology because coding is all important...

The Alpha Acquisition process may provide a cost savings to both government and contractors.  The following is from the Defense Acquisition University  website:

The alpha contracting process involves many activities performed jointly by the Government and contractor teams.

 This process innovation offers a number of advantages and performance enhancements, such as:

• Improving communications
• Decreasing the number of formal RFP iterations
•  Lessening revisions and rework required to correct misunderstandings
• Reducing errors and mistakes
• Shortening the cycle time (procurement administrative lead time or PALT) required for contracting
• More

 The benefits of Alpha Acquisition are not limited to reducing procurement acquisition lead times.

Contractor Reduced Proposal Preparation Costs

The contractor benefits by significantly reducing proposal preparation costs. Alpha Acquisition is a framework for expediting the acquisition process. The purpose is to eliminate any unnecessary processes and reviews, and to streamline and conduct in parallel the required ones. Nevertheless, the same issues addressed in standard procurements are addressed in Alpha Acquisition, the same questions asked, and the same support provided. However, it is all done much more quickly and started earlier in the process.

DCAA Cost Savings

One benefit includes the early involvement of DCAA personnel in the immediate utilization of rate recommendations, rather than at some later date when significant updates would have occurred. This results in a cost and time savings for DCAA by precluding subsequent reviews.

DCMC Savings

DCMC receives a cost and time savings by performing one review rather than several as a result of proposal updates.

Additional Government Program Office Costs

See the comment attached to this BLOG entry  from one working in a program office.

Related posts:

1. Acquisition Reform (WSARA) Webinar Discusses Lessons Learned and Way Forward If you are interested in government acquisition reform be sure...
2. Defense Acquisition Guidebook From DAU The Defense Acquisition University has released an update to its...
3. Manufacturing Revolution, Product Development, And Cost Analysis Jim Ryan of Computer Aid pointed out, during the SEER...

It was exciting to participate in a seminar with Computer Aid and their ITMPI recently.  Here we discussed concepts of software management and how Galorath’s SEER with project estimation, planning and control supports CAI’s Tracer product witch does root level process and task management.

Jim Ryan first spoke and discussed how the manufacturing revolution worked and how much of the success in manufacturing process and process measurement can be applied to software development.  And excellent presentation that made a lot of points really apparent.

Next Dan Galorath went through software management techniques (click link to view presentation) that most likely yield successful projects, including estimation (cost estimating, schedule estimating, defect insertion/ removal estimation an more), planning, control, measurement, commitment and other items.

Related posts:

1. SEER Users Seminar In EL Segundo, October 8, 2009 I just had the opportunity to review the agenda for...
2. Estimation Plus Process and Measurement Rigor Yields More Successful Projects: SEER and Tracer It has been rewarding working with the Computer Aid  (CAI)...
3. CMMI and SEER Applicability: Estimation, Planning & Control Processes and SEER Integration Galorath’s Ton Dekker presented this paper covering SEI’s CMMI and...

Following is an update to Galorath’s David DeWitt’s article on software sizing:

Have We Lost Our Ability to Estimate Software Size?

by David DeWitt

“I’ve Been Slimed!” – Dr. Peter Venkman, Ghost Buster

I can clearly remember that day I arrived at work – towards the end of the year 2003 – it was easily before 6am.  I was leading a small team tasked with prototyping a test environment for a NASA proposal.  I stood there amazed as I watched my two programmers demonstrate a completely reengineered satellite simulation environment.  Wait – let me be clear – within only a few days – they rewrote close to 30,000 lines of FORTRAN and another 4,000 lines of assembly code.   How did they do it?  They called it “goop.”  “The hand cleaner?” I asked – rather befuddled.   No, they were referring a new development language by LabVIEW (National Instruments) called “GOOP” – short for Graphical Object Oriented Programming.

That was the day I decided to stop being a programmer.  I was, at my ‘age,” no longer really interested in keeping up with the latest programming paradigms (and vernacular – such as “paradigm”).  I decided to abandon the past and embrace my role as a program manager.  But now, looking back I wish I had asked a few more questions.

Measuring Failure

In 1995 the Boston, Mass. – based IT project management research and consulting firm The Standish Group released their first CHAOS Summary report.  The report quickly became an industry score card for measuring the success or failure of IT projects; due mostly in part to the astounding percentage of failed projects disclosed in the report.  The report served as a wake-up call that appears to have been heard – the 10^th anniversary CHAOS report announced that the percentage of failed projects had been reduced by more than half.  But alas, within a mere five years, the number of failed projects is back on the rise; the 2009 Standish Group CHAOS report indicates that nearly 1 in 4 projects are doomed. But why?

According to the original 1995 CHAOS report, to improve the probability of success projects should be reduced in complexity and the software “grown.”  The recommendation was to reduce software into smaller, more manageable segments, and develop it outward.  If this reported reduction in failed projects is to be believed then it appears the software industry was diligent in “growing” projects using smaller elements^[1]. However, what should also be understood is that those projects were comprised of many smaller pieces that were easier to “size.”

In 1995 the most common approach to sizing software was to count the source lines of code (SLOC) or count Function Points (though less prevalent).  Software sizing was an established and mature methodology spanning over twenty years – with a myriad of tools available to automate the process and additional metrics available to measure software complexity and probability of defects (bugs). If the size of a project was understood, then the ability to estimate schedule and effort could easily be modeled by applying previous performance measures (and many other parameters).   By forecasting a realistic estimate early in the development cycle there was a significantly higher probability of the project’s success (on time, within budget, at promised functionality) – and hence – less failure.

Back to the Future

It’s 2003 again, and I’ve just been told about a new methodology that allows anyone to build software using graphical components.  This was not really all that new; in the mid-1990s through early 2000s “visual” and “portable” languages gained industry acceptance and began to dominate the development landscape.  Within just a few years, languages that could be “produced” by an environment became the lingua du jour.  After all, who could argue with the massive scale of economy that software manufacturing tools could generate using “Visual” programming?  And for me in particular – after three days of watching my team crank out “GOOP” – I was a hero to my management.

But wait – notice the timeline in the CHAOS study mentioned above and the resurgence of software failures.  While I am not a big proponent of causality – let’s at least take a few moments and explore this potential contributor to the trend in software failure.   First, a picture from the TIOBE Programming Community[2] – the unofficial keepers of what is popular in programming languages.

The languages with the most growth in popularity for five years have been: Java, followed by C#, JavaScript, and then Ruby.   Take a moment to look at the other languages coming in vogue over the past five years.  Why do you think Perl, C, and Visual Basic have actually grown in favor – after all, they’re old school languages (and I don’t find them sexy – but that’s me).  Most all of these top-ten languages have become increasingly more sophisticated, are wrapped in integrated development environments, and are positioned with the sole purpose of increasing productivity.  In a word – they’ve become more “visual.”  While it may be easier to build the code, there is little consideration for how to measure the amount of code being generated.  In fact, the environment builders boast that one barely needs to fiddle under the hood; Draw, click, and Poof – instant code that runs.

Size Matters

The most significant driver to how much time, cost and effort it takes to build software is the scope (or size) of what is to be built and therefore one of the biggest factors in accurate estimation.  As the Godfather of software estimation has warned us (Barry W. Boehm) – “The biggest difficulty in using today’s algorithmic software cost models is the problem of providing sound sizing estimates”[3] How does an estimator measure “GOOP” and how many lines of code that a code generator inserts are really needed?  What percentage of a C++ template can we remove (if we dare) and keep the Class fundamentally stable – yet concise.  As Mark Twain once said – “the hardest part about writing is removing all the extra words.”

Is it possible to count software lines of code anymore?  Even using the best code counting tools available – aren’t they really just counting lots of lines of code that may be unnecessary?  Or in inverse – how much time did it take the programmer to remove all that code that should not have been counted – and was not?  My suspicion is that all the code stays in (unless a standard with high rigor like FAA DO-178B verified the system).

Since I’m on the topic of counting code – what happened to Ada and FORTRAN; those stalwart languages of the 80′s and 90′s that were easy to count?   Alas, they are now number 24 and 25; again, no assumption of causality.  (But yes my tongue is planted firmly in cheek).  Estimates seemed so much easier then.  Cue the music.

Hmm, there is something becoming clear in the Standish report – assuming I am not making what statisticians would call an “error of confirmation”; I would propose that perhaps the industry has made capturing the size of software too complicated – and as a consequence – our ability to accurately create a good cost estimate.  Ultimately, if the industry is moving away from “countable” languages and migrating towards “visual” representations then some mechanism needs to be established that can accurately correlate effort to size or vice-versa.

Here’s a thought – remember those thousands of dollars used to purchase graphical requirements and design tools – such as the IBM Rational Rose, RSA Integration, and Rhapsody?  Why not use the output of these use case models to calculate Use Case Points (unadjusted) which can then be fed into the parametric models.  Are you building “Design Patterns?”   Why not spend a bit more time and calculate the COSMIC Function Points and publish them along with the pattern – that way the cost of implementing the pattern can be calculated.  At a minimum, before charging forward from requirements to code – attempt to calculate some “functional” size that the parametric model accepts and proceed – then go back later to see if your effort per function assumptions were correct.

The software community has made great progress in creating tools to improve productivity – but our estimates are wrong because we stopped half way!  We need to regroup and identify software size as it relates to software cost and involve parametric tools to calculate accurate estimates.   Until then – it’s purely guess work to estimate new product development and blind trust in tribal knowledge when modifying existing applications.  After all – just how long does it take to make GOOP?

[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[3] Software Engineering – Barry W. Boehm’s Lifetime Contributions to Software Development, Management and Research., Edited by Richard W. Selby , Wiley-IEEE Computer Society Pr; Reprint edition (June 4, 2007)

Related posts:

1. Have We Lost Our Ability to Estimate Software Size I really enjoyed Galorath’s David DeWitt’s article “Have We Lost...
2. Software Staff Size Still Impacts Productivity: Brooks Law Lives! When drawing conclusions from data it is important to analyse...
3. Software Code Counter Review and Recommendations Galorath’s Mike Churchman did a comprehensive evaluation of numerous code...

I received an email from the Josephson Institute of Ethics today that included this quote from a well known comedian: “The Sooner You Fall Behind, The More Time You Have To Catch Up.”

As I pondered the absurdity of the statement my mind focused on the many projects I have seen where this might have been taken seriously.  I recall, many years ago, preparing an estimate for a new project, an in-house typesetting system.  While this was not the most complicated software in the world, it took a lot at that time to do a decent job of typesetting with hyphenation, justification, kerning, leading, etc. all having to be implemented by hand generated code (how big is Knuth’s TEX  application?).  The customer had received a proposal from a trusted supplier (who did business reporting software) to build an entire system in just months.  When confronted with the implausibility, the vendor’s only response was, “I just know I can do this.”   Thank goodness the customer didn’t go for it.  If they had, what would have happened… After the original target day came and went there would have been a flurry… a descoping… more promises that “we are almost done, I just know it”… and after a year or two the project would probably have been canceled.

I recall another time, very early in my career… before parametric estimating, when we had a 4 terminal cluster system to develop.  We had a functional spec and a (probably poor) estimate.  We saw an ad in a computer magazine that said this particular programming language would cut costs to 10%.  The supplier came out and guaranteed it: even bidding fixed price and just a few weeks for the entire job.  I must admit I wondered how the vendor would do it… an assembly line type of setup where a team would pass information and where a chief programmer would allocate tasks or what.  When the big day came one guy showed up.  He worked about 24/7. The deadline came and went.  Still no worries… it was the world’s answer to software and it was fixed price.  Six months came and went. Now the vendor came in and said they couldn’t do it.  Four employees plus the vendor and 5 months later it was complete.

I have heard it said that if a cost performance index was below .95 or so, the project cannot catch up.  While no one wants their projects to be in trouble, isn’t it valuable to understand what you can’t catch up?

Viable plans help make successful projects.

Related posts:

1. Cloud Computing Can Save Time and Money: MIT CIO Panel Conclusion MIT Sloan’s CIO Panel identified cloud computing as a near...

15% of corporate customers planning to use cloud in the next year.

A network world article shared results of a survey:

About 15% of corporate customers are considering cloud computing over the next year

The survey of 300 corporations worldwide found that 38% are undecided or unsure about whether they will adopt cloud services, and another 47% said they are not considering implementing cloud in the next year. Security is the biggest roadblock.

85% of corporate customers will not implement a private or public cloud in 2009 due to security concerns.

The findings may be surprising given the industry’s current obsession with cloud computing, but the numbers aren’t too far off the findings of other surveys. Forrester recently found that 25% of enterprises with at least 1,000 employees are using or plan to use hosted virtual server offerings such as Amazon EC2, and that fewer than 20% of smaller companies plan to do so.
Earlier this year, Gartner said that cloud application infrastructure technologies are not yet mature and that adoption right now is limited mostly to “pioneers and trailblazers.”

Related posts:

1. Cloud Computing Can Save Time and Money: MIT CIO Panel Conclusion MIT Sloan’s CIO Panel identified cloud computing as a near...
2. The Cost of Cloud in the Sky Computing Part 1 Looking at ways to increase IT infrastructure without worrying about...
3. The Three Cloud Definitions Refined It is so interesting how people call anything that is...