Client organizations who are considering investing in SLIM^® (a top-down, scope-based, parametric software estimation tool) often ask us for return on investment (ROI) case study examples which we gladly provide to help them with their business case. However, one question that has never been asked but I have always wondered is: does ROI accelerate with increased investment or does it follow the law of diminishing returns?

To answer this question, we looked at seven software estimation ROI case studies that included a variety of small, medium and large clients, from a single seat of SLIM all the way up to an enterprise Estimation Center of Excellence (ECoE).

On the above chart we plotted the investment in SLIM tools and consulting on the X axis vs. the return (actual cost savings) on the Y axis for each case study using a logarithmic scale. We then drew a trend line through the data points.

Following the trend line, small engagements (~$30K) had an average ROI of more than 13:1.  Medium engagements (~$300K) had an average ROI of 33:1.  Large ECoE engagements ($3M) had an average ROI of 67:1.  So not only is the ROI compelling, but it also accelerates with increased investment.

The actual cost savings (return) as reported by, or observed while working with, our clients include:

This case study for Agile Connection by QSM's Taylor Putnam serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.

Read the full article!

Function points are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing function points counted in agile/iterative development with those counted in waterfall or combination development . These inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods. This paper, recently published on IFPUG's Beyond MetricViews by QSM Consultant Carol Dekkers, seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes in order to create a basis for consistent comparison. 

Read the full article!

Software process improvement efforts often fail because we try to accomplish too much too soon.  Aside from the cultural and organizational obstacles to change, people need time to learn and assimilate new ideas and skills.  “Human memory and comprehension are limited, and it is easy to design processes that are beyond peoples’ capacities,” says Watts Humphrey  (Humphrey, 1989).  This is true in any situation, but I think it is compounded in the software world because time is always a scarce resource.  The pressure is high in every organization to justify process improvement dollars and increase capabilities.

Establishing and maintaining software best practices requires that you design clear processes and plan a pace of implementation that promotes lasting change.  A key component is accommodating human learning and skill development challenges.  Borrowing from a training class I developed 14 years ago (yes, implementing best practices is still a challenge), let’s follow a team of water bugs as they progress through Watts’ four stages of Human Methods Adoption to understand what good pacing requires.

Installation – Initial installation of the methods and training in their use.  Process documentation and training should answer questions like:

In the software project management field, projects go badly about 43% of the time and fail completely 18% of the time. While there are several reasons for this, and plenty of blame to go around, one of the easiest ways to reduce the risk is to start at the beginning – with the proposal. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Larry Putnam, Jr. talks about the importance of the proposal when executing a successful project. He identifies five key questions that should be answered before any project starts and how software estimation ties into the proposal process.

Read the full interview transcript here!

I am a professional software project estimator.  While not blessed with genius, I have put in sufficient time that by Malcolm Gladwell’s 10,000 hour rule, I have paid my dues to be competent.  In the past 19 years I have estimated over 2,000 different software projects.  For many of these, the critical inputs were provided and all I had to do was the modeling.  Other times, I did all of the leg work, too: estimating software size, determining critical constraints, and gathering organizational history to benchmark against.  One observation I have taken from years of experience is that there is overwhelming pressure to be more precise with our estimates than can be supported by the data.  

In 2010 I attended a software conference in Brasil.  As an exercise, the participants were asked to estimate the numerical ranges into which 10 items would fall.  The items were such disparate things as the length of coastline in the United States, the gross domestic product of Germany, and the square kilometers in the country of Mali: not things a trivia expert would be likely to know off hand.  Of 150 participants, one person made all of the ranges wide enough.  One other person (me) got 9 out of 10 correct.

A recent article in the New York Times about farm robotics, of all things, made me think about software process improvement.  In the article, dairy farms in New York are beginning to use robotic milkers to feed and milk cows without the use of farm hands.  The solution was born out of several issues for dairy farmers, first, manual labor was hard to come by, and second, dairy prices were soaring.  What farmers needed was cheap, reliable labor; the solution was farm robotics.

Enough already with Healthcare.gov and the many (many) other high-profile IT project failures; let’s talk about government software projects that actually worked. Successful software projects are no accident. Best-in-class government IT projects share common traits that agencies can use to ensure success. In a recent article for Government Computer News, QSM's Larry Putnam, Jr. leverages data from from the QSM Database to identify best practices for successful government projects.

Read the full article!

Television has done a fine job of glamorizing the job of an investigator.  Whether you fancy the classic Sherlock Holmes, the affable Colombo, or even perhaps enjoy the suspense associated with cracking the case on television shows like “The First 48,” Hollywood has tried to make us believe the search for clues is always exciting.  However, those who have searched thousand row spreadsheets for software data collection efforts, may beg to differ with that sentiment.  The needle in a haystack analogy may seem more fitting, if only the haystack was bigger!

Although most folks will never get the chance to track down a villain like Sherlock’s nemesis, Professor Moriarty, there still is a need in many professions to find “clues.”  In software estimation, those clues can be thought of as software project data. What information do I need to solve this software project estimation case and how do I obtain it? In that search for information, perhaps we can utilize some basic investigation steps to find the software data needed to produce good software project estimates. Honestly, why would one embark on the often daunting quest of collecting project data for future estimation without at least a basic approach?  Well, there are many reasons.  However, let’s focus on a way to proactively look at an approach using the analogy of an investigation.