White Paper: Long Term Trends from 40 Years of Completed Software Project Data

Software Project Size over Time

Although the software industry is known for growth and change, one thing has remained constant: the struggle to reduce cost, improve time to market, increase quality and maintainability, and allocate resources most efficiently. So how can we combat future challenges in a world where everything is software, from the systems in your car to the thermostat in your home to the small computer in your pocket? By using practical measurement and metrics, we can get a bird's-eye view of where we've been and where we could go, while keeping us grounded in data. Leveraging QSM's industry database of over 13,000+ completed projects, Katie Costantini takes a high-level look at changes to software schedules, effort/cost, productivity, size, and reliability metrics from 1980 to 2019. The current study compares insights to similar studies QSM has completed at regular intervals over the past four decades and answers questions like, 'what is the "typical" project over time?' and 'why are projects "shrinking?"' The results may surprise you!

Read the full white paper!

The Balancing Point between Project Cost and Schedule

In all production environments, there exists a tension between competing outcomes.  Four variables come to mind:

  • Cost/Effort
  • Schedule
  • Quality
  • Productivity

These do not exist independently of one another.  Emphasizing any one impacts the others.  For example, to compress a project’s schedule, additional staff is typically added which increases the cost.  Larger team size also increases communication complexity within a project which leads to more defects (lower quality).  The development of software  presents a unique issue that may not be present or is at least more muted in manufacturing:  non-linearity.  Key examples of this are the relationships between cost/effort and schedule and the one between schedule and quality. 

Let’s look at some examples.  In the charts below, regression trend lines for schedule and effort vs. size were developed from the QSM software project database.  The darker center lines represent average schedule and effort outcomes as delivered product size grows.  The lighter lines are plus and minus 1 standard deviation.  Roughly 2/3 of the projects in the database fall between the standard deviation lines.  Note the scale on the axes, which is log-log.  This is because the relationship between the amount of software developed and schedule duration or effort is non-linear. 

Software Project Solution
6.5 Month Solution

Software Project Solution
5.85 Month Solution

Blog Post Categories 
Estimation Schedule Effort

Eliminating the 18-Hour Work Day in Software Development

Software Development "Death March"

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

It may seem absurd to think about working an 18-hour day, but it happens all the time in the software development community. If managers don’t accurately estimate project schedules based on a clearly defined scope of work, managers and their development teams may find themselves working long days to deliver on promised deadlines and deliverables.

Being overworked in an environment where a project is running over schedule can also lead to the delivery of a defective or flawed product, which is bad for both the development organization and the business unit for which the product is being developed. One article that I read recently states that time pressures cause employees to cut corners and that the 18-hour workday does not allow for forward or creative thinking. This can be disastrous to an organization that values both the quality of work and the out-of-the-box thinking of its development team.

Blog Post Categories 
Schedule Estimation

When Bad News Isn't So Bad

I think it’s safe to say that nobody really enjoys hearing bad news.  It’s especially hard if you’re the person who has to deliver the bad news, particularly to a superior.  How will your boss react?  Will you be the one held responsible (unfairly) for the project failure?  These are all reasons for keeping the ‘bad news’ to yourself and letting those in charge find out on their own.  

I’ll share a story about one of the first jobs I ever held, as an assistant manager at a summer swimming pool.  My supervisor had a very hands-off approach to management and would often rely on me and the other assistant managers to handle the day-to-day operations of the pool.  Whenever I would deliver less-than-favorable news to him, such as our pool vacuum breaking, or a health inspector dropping by to schedule a visit, my supervisor would literally stick his fingers in his ears and say “La la la la la, I can’t hear you.  Taylor, you know how I feel about bad news.  Fix the problem.”  This put me in a very awkward situation, because as a high school student, I didn’t necessarily have the training or the authority to fix every problem myself, in order to shield him from the ‘bad news.’  

Unfortunately, this type of management exists beyond the pool house and can frequently be found in the corporate world as well.  In an environment where your reputation can mean everything, stakeholders can be very reluctant to receive bad news about the status of their project.  The silver lining in this is that receiving ‘bad news’ isn’t necessarily always a bad thing.  Allow me to explain.

Blog Post Categories 
Estimation Schedule Project Management

Schedule, the Eternal Enemy

“More projects have gone awry for lack of calendar time than for all other reasons combined” - Frederick Brooks, The Mythical Man-Month

These words were penned by Frederick Brooks in “The Mythical Man-Month” over 35 years ago.  Think back to that time for a moment.  The first personal computers were being born as kits assembled by electronic hobbyists.  Serious programmers considered them to be toys.  A good knowledge of COBOL could get you a job just about anywhere.  Computers and IBM were virtually synonymous.  Structured programming was the process improvement silver bullet of the day.  Something called ARPANet, the parent of the Internet, had come into existence.  And software projects experienced serious problems because they weren’t given enough time to complete and test their work.  Everything has changed except for the last item.


Over this span of time a host of solutions have been attempted with very modest results.  Only the elephant in the living room has been ignored:  since project schedules are chronically and habitually underestimated, why not allocate more time to them at the outset?  The reasons for doing so are compelling:

Blog Post Categories 

Haste Is Expensive

Large companies often seem to have a few people in key positions with extra time on their hands. Occasionally, this time is used to invent acronyms that are supposed to embody corporate ideals. Mercifully, these usually fade away in time. A former employer of mine had two beauties: LOCOPRO (Low Cost Provider) and BEGOR (Best Guaranteer of Results). Unfortunately, besides being grating on the ear, LOCOPRO and BEGOR don’t always march in tandem. LOCOPRO deals with cost and the effort required to deliver something. BEGOR is a bit more amorphous dealing with quality and an organization’s efficiency and consistency in meeting requirements.

What are the normal requirements for a software project? Here’s my short list.

  • Cost. What is being created and delivered has to be worth the expense in the mind of the person or organization that is funding it. (LOCOPRO is good)
  • Schedule. The timeframe in which a project creates and delivers its software is frequently a key constraint. Meeting this is important. Consistency and predictability (BEGOR are good)
  • Quality. In Business IT systems this is often an implicit requirement that is most noticed when it is absent. Real time, telecommunications, military, and life support systems are more frequently developed and tested to explicit quality standards.

The mantra of Faster/Better/Cheaper captures most organizations’ desires for Cost, Schedule, and Quality – all at the same time. If only the laws of software would cooperate! But they don’t. Software is like a balloon. You constrict it in one place (schedule, for instance) and it expands in another (cost). The problem isn’t going to disappear; but by prioritizing requirements, conscious and realistic tradeoffs can be made.

Blog Post Categories 

Relax the Project Schedule

I have been enjoying Alan Cohen's A Deep Breath of Life. I read it every morning with pen in hand, never failing to find at least one or two profound sentences to be my watch-words for the day. One of the July writings contains this quote: "Only infinite patience begets immediate results."  David writes about the perils of rushing through life, and how a lack of patience can causes us to create unnecessary chaos in our daily rounds. He writes, "Rushing never improves the quality of our life or the results we seek; to the contrary, it muddles our vision and causes us to make errors that cost us twice as much time and energy to repair."

One of my first thoughts was about my work at QSM, and how SLIM-Estimate demonstrates the power of patience in software development. Is it possible to exercise patience when there are important business objectives and profit margins to achieve? The Putnam software production equation, backed by 30 years of industry data, shows that relaxing the project schedule gives the best “bang for your buck” to produce value for your customers.

Blog Post Categories 
Program Management Schedule