QSM is pleased to announce the release of a new book, Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer. Historically, only 20% of software projects are completed successfully and with software becoming critical to nearly every company and industry, having such a high rate of failure is simply unacceptable anymore. It is for this reason that QSM has compiled this collection of articles that will aid anyone from project managers to CIOs in implementing software estimation, negotiation and demand management methods efficiently to reduce costs.

Larry Putnam, Sr., founder of QSM and a pioneer and top problem solver in the software estimation and measurement field, provides the foreword to the book, which is co-authored by his son and granddaughter, Doug Putnam and Taylor Putnam-Majarian. Combined, the authors bring more than 40 years of experience in software measurement to a range of topics, including:

While creating estimates is a fundamental step toward improving productivity on software development projects, it is not enough. In "Full-Circle Estimating," recently published on Projects at Work, Doug Putnam and Taylor Putnam-Majarian present a full-circle model that organizations can apply to track actual performance against estimates, reforecast when significant changes occur, and then continually refine the process through post-mortem assessment.

Doug Putnam is co-CEO for Quantitative Software Management (QSM). He has 35 years of experience in the software measurement field and has been instrumental in the development of the SLIM Suite of software estimation and measurement tools. C. Taylor Putnam-Majarian is a consulting analyst at QSM with over seven years of specialized data analysis, testing and research experience. In addition to providing consulting support in software estimation and benchmarking engagements to clients from both the commercial and government sectors, Taylor has authored numerous publications about Agile development, software estimation and process improvement.

Read the full article!

I have been a software project estimator for 20 years.  Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life.  So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour.  Usually, I am closer to the mark than they are.

Focused on planning for software projects, this IEEE presentation by Keith Ciocco explains some of the key components of a successful estimation process. This is a summary level view focusing on the importance of leveraging historical data, sizing, and measuring productivity when estimating at the organizational and project level. This presentation includes a demonstration of the SLIM Suite of tools to show how we can automate and streamline the estimation process.

Watch the replay of this presentation!

Beginning with the release of SLIM-Suite v8.1, two new SLIM-Estimate solution methods were added to let you see what a “typical” project would look like: that is, the resources it would require, based upon historical projects from either the QSM database or your own.  The two methods are:

• Solve from Trends Wizard
• Trend Based Solution

SLIM-Estimate provides several different ways to solve the software production equation and produce an estimate.  The solution method you select depends upon the information you have available.  The traditional methods, known as Quick Estimate Wizard and Detailed Method, take inputs of Size and Productivity (PI), and calculate Effort and Time.  The Solve for Size Wizard, perfect for time-boxed estimates, takes inputs of Time, Effort, and PI, and determines the amount of functionality that combination of resources can produce.

The trend solutions require only one input – Size.  Using the specified Primary Trend Group, Time and Effort are read from the average trend line and productivity (PI) is calculated.  These methods extend the capabilities of producing a defensible project estimates very early in the life cycle.  You can determine the feasibility of project goals, assess risk, and manage stakeholder expectations even if all you can estimate is a relative application size, expressed as a “T-shirt” or bin size, as shown in the figure below.

When an organization wants to proactively manage their software activities from inception through development and sustainment, an enterprise software estimation or acquisition Center of Excellence (COE) is a great solution.  A significant portion of our professional services business at QSM is helping companies design and stand up enterprise COE operations. 

There are three main components to a successful COE implementation.  They are:

1. People – Finding people with the right characteristics and developing their skills;
2. Business Processes – developing the right business processes to support decision making; and
3. Tools – Acquiring and configuring analytical tools to support the business processes.

Our clients often ask us to identify the best characteristics and skills for a person that they plan to staff into a COE.  We went back and looked at our most successful implementations, and here is what we found.

Ideal Enterprise COE Skill Set:

Software size, the amount of functionality in a given software release, is arguably the most important of the five core metrics of software estimation.  There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building.

Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process.  Sometimes a picture is better than 1,000 words.  With that ideal of visual simplicity in mind, we developed a software sizing infographic that helps explain:

• Why we care about size
• Challenges in sizing
• When size should be measured during the software development life cycle (SDLC) to narrow the cone of uncertainty
• The difference between functional and technical size 
• The most popular sizing methods and when to use them

The infographic begins by introducing the five core metrics of software estimation (size (scope), schedule (duration), effort (cost), quality (defects) and productivity) and the nonlinear relationship between them.

At QSM, we have one of the largest industry databases in the world of completed software projects. The data comes from our clients with their permission and this data has been the backbone of our software estimation business for over 35 years. We can see what is reasonable on software development projects as it relates to cost, team size, effort, duration, size, and reliability. Because of our experience we are often asked about risk factors and estimation accuracy early in the project lifecycle. We explain that increased accuracy comes with having historical data and good sizing information.

But what happens on the early estimates when clients don’t have history and detailed sizing information? Can they still generate scope level estimates so they can make good business decisions? The answer is yes. Risk management techniques can be applied and project uncertainty can be calculated so organizations can plan effectively. This is very important because big business decisions are often made early. Decision-makers need to know if they should move forward with a project and they need to know how much time and effort to allocate.

We use SLIM-Estimate, which is a leading estimation tool that leverages the Putnam Model. It generates reliable estimates based on QSM’s time-tested forecasting models and historical data and it also provides scope level estimates when project information is hard to find. It will allow you to see the chance you have of hitting your project goals and it will allow you to factor in your uncertainty.

How in the world does landing on an aircraft carrier relate to software estimation? Anyone who has ever experienced the terror joy of landing a jet on an aircraft carrier, especially on that dark, stormy night with no moon and a pitching deck, appreciates the importance of a good start. Your line-up is critical, as is your airspeed, angle-of-attack and attention to the "ball" – that tiny little yellow dot between the rows of green lights. As a former Bombardier/Navigator in the Grumman A6E Intruder, I have teamed with pilots on over 300 landings, all of which I have lived through. My job was to monitor and call the line-up and radar altimeter, handle the radios, manage the fuel and generally avoid sounding terrified for the entire evolution.

The process was made significantly easier if we arrived at the 3/4 mile point behind the ship at the right airspeed, gross weight, angle of attack, altitude and line up. Sort of like juggling a bunch of skittish cats.

But when all those parameters came together, we had a good start. When embarking on a software development project, or any engineering project, it’s equally important to have a strong foundation. That means having a solid idea of the characteristics of the project, what resources are (or should be) available, what duration is most likely and how good does it have to be. A software estimation tool can provide the project manager with this essential information.