If you were unable to attend "An Introduction to the SLIM Suite of Tools," originally presented on April 28 by Keith Ciocco, a replay is now available for viewing.

Want to learn more about our tools? This webinar will give you an introduction to the SLIM Suite, as well as highlight some of the new features for users that are already familiar with SLIM. QSM Vice President Keith Ciocco shows you how to sanity-check your estimates with industry data, provide what-if analysis, and negotiate estimates with clients or management. Get a full overview of the SLIM-Suite, including SLIM-Estimate, SLIM-Control, SLIM-Metrics, SLIM-MasterPlan, and SLIM-DataManager.

As Vice President of QSM, Keith has more than 23 years of experience working in sales and customer service, with 15 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response.

View the replay here.

QSM  invites developers of financial services and Business/IT applications to participate in their 2011 IT Maintenance and Offshoring Survey. Software development organizations are always curious about how they stack up against the industry. With your help, we hope to provide insight into how major software developers budget, staff, and measure their maintenance and offshore development. Key analysis areas include:

• How much do IT shops typically spend on application maintenance vs. new development/enhancements?
• What project types and skills are most likely to be offshored?
• How does offshore development stack up in terms of productivity and quality?
• What are the challenges and constraints of the offshore development environment?

At the conclusion of the survey, participants will receive an electronic copy of the QSM IT Almanac and a free industry summary report that analyzes typical development vs. maintenance budgets and offshore spending and resource mixes by software function, platform, and skill.

Who should complete the survey?
This survey is primarily focused on major financial services software firms, but IT systems developers are also welcome to participate.

Survey Timeline
The survey will begin Monday, April 18th and close on Friday, April 29th, 2011.

On Thursday, April 28 at 1:00 PM EDT, QSM will host a webinar showcasing features of the SLIM Suite of Tools.

Want to learn more about our tools? This webinar will give you an introduction to the SLIM Suite, as well as highlight some of the new features for users that are already familiar with SLIM. QSM Vice President Keith Ciocco shows you how to sanity-check your estimates with industry data, provide what-if analysis, and negotiate estimates with clients or management. Get a full overview of the SLIM-Suite, including SLIM-Estimate, SLIM-Control, SLIM-Metrics, SLIM-MasterPlan, and SLIM-DataManager.

As Vice President of QSM, Keith has more than 23 years of experience working in sales and customer service, with 15 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response.

To register, click here.

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.

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.

Last week we looked at IT software productivity trends for 1000 completed IT systems and noted that average productivity has declined over the last 15 years.

The post sparked some interesting responses. Two readers wanted to know whether productivity actually increases over time for projects in the same size range? If so, this would be an illustration of Simpson's Paradox: a counterintuitive phenomenon we've seen from time to time in our own research. Simply put, sometimes the direction of a trend is reversed when the sample is broken into categories.

To answer their question, I used our SLIM-Metrics tool to stratify the sample into four size bins:

Under 5000 Effective (new + modified) SLOC
5000- <10000 Effective (new + modified) SLOC
10000-<20000 Effective (new + modified) SLOC
20000-<30000 Effective (new + modified) SLOC

These 4 size bins span a little over two thirds of the data. As a sanity check, I applied the same queries to both the original sample of 1000 IT projects and a larger sample of nearly 2200 IT projects. As the following chart shows, stratifying the data into size bins doesn't affect the overall direction of the trend:

For conventional productivity (FP/Person Month) the decline in productivity was even more pronounced:

Here are the results as of 3 pm today for our productivity poll. I was surprised to see that "Time slicing and multi-tasking" was far and away the most popular response!

When I framed the poll question, I was thinking of time slicing by policy (i.e., where management asks a single person to divide his time/attention between multiple projects). Viewed from a cost perspective, such assignments make perfect cents [pun fully intended] - especially for small or poorly capitalized projects. But from a productivity perspective, the constant distractions inherent in this kind of multi-tasking can result in less than optimal performance. 

Carol Dekkers made me think of another possible explanation for the declining productivity we've seen over the last 15 years: the distraction of 24/7 online communication. 

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

 I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

If you're planning on attending this year's SEPG conference, don't miss QSM Consultant, researcher, and all around blogger extraordinaire Paul Below! On Wednesday, March 23rd, Paul will demonstrate how organizations can Maximize Value by Understanding the Productivity Paradox and Predicting Reliability:

Now more than ever, software projects need to efficiently deliver reliable software. However, many development plans unintentionally guarantee a less-than-optimal result. This presentation uses historical result metrics to describe how to maximize value by establishing minimum acceptable reliability and how to take advantage of the apparent paradox between software size and productivity through appropriate selection of team size and schedule duration.

If you've enjoyed Paul's posts here, make sure you stop by and say hello!

On our Software Productivity Declines Over Time post, ISBSG's Peter Hill left an interesting comment:

... your findings that 'average productivity increases with project size' might raise a few eyebrows, but the ISBSG data produces the same finding. Of course we only have data on projects that were completed. I wonder about the incidence of abandonment of large projects.

The QSM database shows a positive correlation between system size and productivity. The following chart shows PI vs. System Size regression fits for 9 different application domains (Business, System Software, Process Control, Telecom, Scientific, Command & Control, Avionics, Microcode, and Real Time). Regardless of domain, average productivity increases with system size:

View larger image

In the SLIM-Estimate user's guide, we speculate about possible explanations for the relationship between productivity and system size:

Small systems tend to have lower average PIs than large systems. We can only speculate as to the reasons, but two important influences may be management influence (the way large and small systems are planned, managed, and funded) and economies of scale.

Since we're speculating about why (in the aggregate at least) software productivity appears to have declined over time, here's another possible cause. I call it The Housework Theory of Productivity.

Back in great-Grandma's time, cleaning was a labor intensive endeavor. Rugs were swept once or twice a week and taken outside and beaten by hand once a year. Those cheery little scrubbing bubbles weren't around to whisk the pesky soap scum from our bathtubs - they hadn't been invented yet. When it came to cleaning, our aspirations were limited by the time and effort required to complete even the simplest tasks.

Over time various "labor saving" devices ushered in heretofore unheard of levels of springtime fresh cleanliness. But there was a downside to these advances: as our ability to get things clean increased, so did our expectations. The work expanded to fill the time (and energy) available to us.

If we were to compare two software projects that are same size and perform the same function (but were completed 20 years apart), we'd likely find the modern billing system smaller in size but far richer in features. It would also be more complex, both from an algorithmic and an architectural standpoint. Because today's programming tools and languages make it possible to deliver more value per line of code or function point, our standards have risen. We expect more for our time and money.