Estimation

Estimation

Deploying Estimation the Right Way - a SLIM Customer Success Story

Two common questions we receive are “how quickly can we get SLIM deployed within our organization?” and “how accurate will our estimates be?” On the accuracy question, our answer is usually that “it depends”. Like most things, accuracy and success in estimating are directly correlated to the effort put into the task. If you buy a commercial estimating tool and try to use it “out of the box” with no tailoring and calibration, accuracy usually suffers. One of the most efficient ways to achieve both of these goals is to use your own historical data. This was an excellent example of how one of our global systems integration clients was able to get almost immediate value by calibrating SLIM-Estimate to their historical data.

This major integrator wanted to improve estimation at one of their accounts, a large multinational company.  In addition they wanted to use function points as their sizing metric. After evaluating a number of estimation options, including custom built and other internally developed solutions, they decided to use QSM’s SLIM-Estimate, which was being deployed globally across the rest of the organization. They decided to start with a pilot implementation. The estimation pilot lasted a total of 5 months with a staff of 2 people. After the fact they looked at the effort expended on their pilot activities and found that 60% of the total effort went into their calibration activities. The calibration  process included assembling a historical data sample of over 50 projects. As part of their function point deployment, they empirically determined FP/ESLOC gearing factors.

Blog Post Categories 
Estimation SLIM-Estimate User Stories

SLIM 8.0f1: Estimating Beyond Software

In recent years, we have seen our client base become increasingly diverse, expressing the need for our estimation, tracking, and benchmarking tools for design processes outside of just software. While clients have customized SLIM to other design disciplines in the past, our goal with SLIM 8.0 was to increase configurability within our tools so our users can model any type of system quickly and easily. Now users can forecast and benchmark Agile, infrastructure, offshore/multi-shore, ERP/package implementation projects, and more.  In addition to updated trendlines from 10,000 completed software and systems projects, SLIM comes pre-packaged with trend groups, such as Agile, ERP, Financial, Web, and Government.

Read the full press release with detailed product upgrades here.

Blog Post Categories 
MasterPlan QSM News Estimation SLIM-Estimate

Technology Can Only Do So Much

It’s hard to believe it’s been 36 years since an IBM manager named Fred Brooks came out with his seminal insights about software development, the most famous of which ("adding more people to a late software project makes it later") came to be known as Brooks’ Law. These days, most software professionals accept and appreciate Brooks’ analysis, yet we continue to make the very mistakes that prompted him to write The Mythical Man Month!

Which leads to an interesting question: armed with such a clear and compelling argument against piling on staff at the last minute, why do we repeatedly employ a strategy that not only fails to achieve the hoped-for schedule reductions but often results in buggy, unreliable software?

The most likely answer combines schedule pressure with the human tendency to over-optimism. Basing plans on hope rather than experience is encouraged by a constant parade of new tools and methods. Faced with the pressure to win business, please customers and maintain market share, is it really surprising that new  technologies tempt us to discount the past and hope that – if we use this tool, this team, this methodology - this project will be different?

How can software developers counter the human tendency to fall for overly optimistic estimates and unachievable schedules?

What's needed is perspective: the kind of perspective that comes from honestly examining - and reminding ourselves - how things have worked in the past. In a paper called, “Technology Can Only Do So Much”, I look at the human and technological factors that trip up so many software projects.  Good historical data provides a sound empirical baseline, against which both conventional wisdom and future plans can be assessed.

 

Blog Post Categories 
Metrics Team Size Estimation

Estimating Agile Projects Webinar

On Thursday, September 30th at 1 pm EDT, QSM will host a Webinar on Agile Estimation Methods.

You can view the replay of this webinar here.

   
Description:
Agile has become a popular development methodology in software and systems development in recent years, but how do we tailor our estimation processes to this new methodology? Traditional methods do not apply in terms of project sizing and planning. How can we find an accurate point of comparison with industry trends? Presented by industry veteran Larry Putnam, Jr., QSM takes you through the basic steps on how to customize the estimation process to Agile.

Lawrence H. Putnam, Jr., Co-Chief Executive Officer of QSM, has 21 years of experience using the Putnam-SLIM Methodology. He has participated in more than 80 estimation and oversight service engagements, and is responsible for product management of the SLIM-Suite of measurement tools and customer care programs. Larry is a member of and active participant in numerous organizations, including the Quality Assurance Institute, Software Program Managers Network, International Function Point Users Group, and International Society of Parametric Analysts. Larry has delivered more than 27 speeches at conferences on software estimation and measurement, and has trained – over a five-year period – more than 1,000 software professionals in the use of the SLIM-Suite.
Blog Post Categories 
Webinars Estimation Agile

Code Counters and Size Measurement

Regardless of which size measures (Effective SLOC, function points, objects, modules, etc.) your organization uses to measure software size, code counters provide a fast and easy way to measure developed functionality. If your organization uses Effective (new and modified) SLOC, the output from an automated code counter can generally be used "as is". If you use more abstract size measures (function points or requirements, for example), code counts can be used to calculated gearing factors such as average SLOC/FP or SLOC/requirement.

The QSM Code Counters page has been updated and extended to include both updated version information and additional code counters. Though QSM neither endorses nor recommends the use of any particular code counting tool, we hope the code counter page will be a useful resource that supports both size estimation and the collection of historical data.

Blog Post Categories 
Benchmarking Software Sizing Estimation