New Video: How to Use Project History for Early Software Decisions

Early project decisions, when not much is known, are easily the hardest. They're also often the most critical. Maybe you've found yourself in a position where you need to communicate to stakeholders what your work is going to cost and how long it will take to deliver. Feeling the pressure to deliver, you might have to make decisions based on gut feel instead of past performance. This can lead to setting unrealistic targets and often results in projects going late or over budget. 

At QSM, this is when we recommend turning to historical data. Whether it's your own data or trendlines from the 13,000 validated projects in the QSM industry database, leveraging actual completed projects can make your estimates more reliable. 

Believe it or not, collecting your own project history isn't as difficult as it sounds. We recommend capturing just a few basic metrics: Functionality Delivered, Total Effort, and Total Duration. Once you have this information, you can calculate a Productivity Index, which is the measure of productivity for the overall project or release. Then all of these metrics can be leveraged by any of the other project lifecycle tools in the SLIM-Suite for estimating, tracking, and benchmarking.

In the video above, you can see how easy it is to gather your own completed projects to use early in the planning process and determine if your estimates are reasonable or not. This helps you understand the big picture before you make any important project or portfolio decisions. 

Practical Software Estimation Tips for Communicating with Business Leaders

How large is your project?
It’s projected to cost $2,000,000.
That’s cost. not size!

How large is your project?
We believe it will take 14 months to complete.
That’s schedule, not size!

How large is your project?
It’s going to be a 25-person project.
That’s staff, not size!

Software estimators often think of project size as what a project produces (features, stories, requirements, function points, or code). These are what a project has to create or account for in order to fulfill its mission. Business leaders, understandably, are more likely to visualize project size in terms of resources expended (cost, time to market, or FTE staff).  These competing definitions of “size” can produce confusion and ambiguity. Which leads us to Tip #1.

Tip 1

Be prepared to explain to business leaders how quantifying project size (as seen by an estimator) helps business leaders get more accurate estimates of the things that matter to them: cost, schedule, quality, and staffing. I find a graphic like the one below from SLIM-Estimate can be useful to illustrate the relationship between a project’s size (primarily of interest to development staff and project managers) and the major project management metrics of interest to the C-suite.

Blog Post Categories 
Estimation Cost Effort Sizing Schedule

Circa 2021, What Does a “Typical” Software Project Look Like?


No two software projects are exactly alike. So, one way to find out what a “typical” software project looks like is to take a large sample of completed projects from the QSM historical database of over 13,000 completed software projects and look at measurements of central tendency for staff, effort, size, schedule duration, and productivity.

For this study, QSM looked at validated projects that completed beginning in 2010. We eliminated 1 person projects and those that expended less than 1 person month of effort. The eliminated projects accounted for 13% of the sample. About 80% of the projects fell into the Business IT application domain, many of which were from the financial services sector. This domain includes projects that typically automate common business functions such as payroll, financial transactions, personnel, order entry, inventory management, materials handling, warranty and maintenance products. We determined both a median and an average for each metric. With the exception of schedule (project duration), these differed significantly which indicates that that the sample metric values were not normally distributed. To minimize the effect of unrepresentative projects (those that comprise a small part of the sample, but whose metric values are very large or very small), we decided to use the medians – values with 50% of the projects above and 50% below the “average” as a better measure of central tendency.

The "Typical" Project



Average Staff (Full Time Equivalent)


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