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.

The laws of flight have many commonalities with the “physics” of software development. Whereas the principles of aerodynamics are essentially about thrust, drag, lift and weight, developing software has always been about the relationship between size (scope), effort (cost), duration (schedule) and the often overlooked measurement of quality (reliability).  

In aviation parlance the expression “flying by the seat of your pants” literally meant that you felt the plane through your “seat”. Early aircraft had limited navigational aids, mainly a rudimentary compass (which worked only when flying level) and a simple string to assess airflow relative to the plane’s fuselage. Pilots could determine the degree of an ascent or descent by G-force sensation, or assess airspeed by the severity of the aircraft’s vibrations. Until the invention of the gyroscope it was quite dangerous to fly without a virtual horizon – the centerpiece of a modern dashboard.

Early aeronauts plotted their routes using individual skill, celestial or fixed landmarks and their own real time perceptions rather than depending on mechanical tools. However, fog or low visibility would render the limited instruments they had useless, with the flight itself remaining as a risky endeavor. A successful trip meant you landed at your destination in one piece, but it was largely dependent upon the talent and judgment of the aviator, visibility and weather, and perhaps no small amount of luck.    

Dear Carol: 

Given all your international experience, I’m hoping you can tell me where I can find a large, freely available industry database that project managers could use for software estimation and/or benchmarking.  After 5 decades of software development wouldn’t you think that we could put together a software estimation or benchmarking database that the world could use for free? 

- Hopeful in Hartford

Dear Hopeful:  

Great question – and the dream of many IT project managers.  It might seem like an easy concept (just collect actual effort and project size and use it for future estimates); in practice it’s not that simple.

What I know is that in software estimation and benchmarking, there is no free lunch -- you get what you pay for.  And I’ll explain why…

Management decisions made before a software project is underway are a significant factor in determining whether it succeeds or fails. In a recent article for Projects at Work, QSM's Don Beckett identifies seven principles, based on comprehensive studies, that leaders must support and uphold to help create an environment in which projects can succeed. Ignoring them practically guarantees failure.

Don Beckett has 18 years of experience in software project estimation, measurement, and analysis. His responsibilities at QSM include research, consulting, and customer support. Don was an analyst/co-author of the 2006 QSM Software Almanac and has contributed articles to Crosstalk and Software Tech News.

Read the full article!

In a recent interview on WUSA9's Government Contracting Weekly, a show devoted to winning government contracts, QSM Co-CEO Doug Putnam discussed data management with the show's host, Jim McCarthy. QSM was founded by Larry Putnam, Sr. in 1978 because he saw the need to supply quantitative evidence when justifying budgets for large government software projects. Doug explains the importance of leveraging quantitative measurement in today's dynamic goverment IT environment, from managing team size to improving quality. He also identifies the core metrics to track when starting your own metrics program. Watch the full episode above!

QSM's recent webinar, How a Collaborative Estimation Process Produces Realistic Estimates Fast, presented by Laura Zuber, sparked a lively Q&A session from our audience. Here are the highlights:

Q: How do I know which template to use when creating a new estimate in SLIM-WebServices?

A: That’s a good question. Your back office administrator configures templates to map to your software development lifecycle, your standard processes and different project types. The back office person can provide detailed descriptions and key information that are viewable from the Feasibility Wizard so you know which one to select.

Q: What makes a project assessed as conservative or risky?