Practical Software Measurement
Blog Signup
Receive Email Blog Updates! *

Newsletter Signup
Email *


Blog Post Categories
Most Popular
Agile Series Part 3: Embrace Change
Why Software Projects Confound Business Leaders
Replay Now Available of "An Introduction to the SLIM Suite of Tools" Webinar
Circa 2021, What Does a “Typical” Software Project Look Like?
Advice from QSM Experts for Successful Software Development in 2018
Home Blogs Donald Beckett's blogWhy Software Projects Confound Business Leaders
Why Software Projects Confound Business Leaders
March 19th, 2015 by Donald Beckett
There is an old adage that if your only tool is a hammer, everything looks like a nail.  We use the lessons learned and experience we have gained to address current issues.  But if the problem (or software project) we face today is fundamentally different from those we’ve dealt with previously, past experience isn’t the proper framework.  In effect, we will be using a hammer when a saw or a chisel might be the tools we need.
The solution, of course, is to first gain an understanding of the problem at hand.  What are its defining features?  How does it behave?  Only then can a proper solution be designed and the appropriate tools selected.
To a large degree, our understanding of how products are developed comes from knowledge gained from manufacturing since the beginning of the Industrial Revolution.  Mentally, our first instinct is to try to apply those lessons learned to software development.  But there is a huge problem with this approach. The creation of software is not a manufacturing process, but rather a knowledge acquisition and learning process that follows different rules.  Here is a simple example.  If I have an assembly line and want to double my output, I have several choices.  I might add a second shift of workers or I could install an additional assembly line.  Because manufacturing is a repetitive process in which design problems are solved before product construction begins, the relationship between labor required and output remains fairly constant.  In a nutshell, we already know exactly what we need to do (and how to do it).  
Software is a different beast.  Because design often “evolves” during product construction, there is always some uncertainty about what is required and how to do it.  Software development is the process of resolving those uncertainties, the result of which is the delivered software product.  If this were not so, the problems with software development would have been solved with Case Tools in the 1980s: analyze the problem, design the solution, feed it into the Case Tool, and bingo, out comes a functional software product!  Case Tools had limited success in large part because it is impossible to completely eliminate uncertainty about what to do and how to do it in advance.  Since software is a learning (rather than a manufacturing) process, it follows a different set of rules.
In the manufacturing example above, you could double the output or halve the development time (within the limits of machine capacity) by doubling the staff.  The relationship between output (products manufactured) and the inputs to production (labor and machinery) is linear.  Doubling the staff on a software projects doesn’t cut the schedule in half; it just costs more and produces an inferior product.
Here are a few rules about how software development behaves.  The business leader who adheres to these will improve his or her project success rate and may experience the benefits of lower blood pressure:
All of the concepts touched upon here (and many others) are addressed in the QSM Software Almanac: 2014 Research Edition which you can download at no cost.
Project Management
Donald Beckett's blog
2019 Almanac
Contact QSM
© Copyright 2022 QSM
We use cookies and similar technologies to provide you with the best possible experience on our website (for personalization, analytics and performance). Agree