Productivity
Let's Get Serious About Productivity
Recently I conducted a study on projects sized in function points that covers projects put into production from 1990 to the present, with a focus on ones completed since 2000. For an analyst like myself, one of the fun things about a study like this is that you can identify trends and then consider possible explanations for why they are occurring. A notable trend from this study of over 2000 projects is that productivity, whether measured in function points per person month (FP/PM) or hours per function point, is about half of what it was in the 1990 to 1994 time frame.
Median Productivity
Achieving Goals Begins with Successful Measurement
“You can’t know where you’re going until you know where you’ve been.”
At this point, we’re about one month into 2013 and many of us have abandoned our New Year’s resolutions. Personally, I prefer to set my yearly goals about a month in because it gives me some time to reflect on what I really want to improve without being distracted by everyone’s bandwagon resolutions like getting in shape or eating less junk food.
Webinar: Maximizing Value Using the Relationship between Software Size, Productivity, and Reliability
On Thursday, Oct. 6 at 1:00 PM EDT, QSM will host a webinar focused on the relationship and apparent paradox between software size, productivity, and 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 describes 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.
Simpson's Paradox
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:
Technology As A Hidden Productivity Killer
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!
Poll: Why Does Productivity Increase With System Size?
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 Housework Theory of Productivity
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.
Has Software Productivity Declined Over Time?
Peter Hill of ISBGS poses an interesting question:
Has software productivity improved over the last 15 years? What do you think? Perhaps it doesn't matter as long as quality (as in defect rate) as improved?
Two widely used productivity measures are Function Points/Person Month and QSM's PI (or productivity index). To answer Peter's question, I took a quick look at 1000 medium and high confidence business systems completed between 1996 and 2011. Here's what I found:
Part IV: Duration, Team Size, and Productivity
For many projects, duration is just as important a constraint as cost. In this installment we will tackle the question: How do changes to team size affect project duration and the resulting productivity? Once again we will use our database of business applications completed since January, 2000.
Part III: How Does Duration Affect Productivity?
This week we turn to another question triggered by the Performance Benchmark Tables: how does duration affect productivity? To many managers, project schedule and cost are equally important. There are significant tradeoffs involved: if the project takes too long, important market opportunities may be lost. But adding people to compress the schedule can drive up cost dramatically. For this reason, QSM uses a productivity metric that explicitly accounts for duration: the Productivity Index (or PI). Unlike ratio based productivity measures, the PI is a three dimensional measure that adds duration to the traditional size/effort equation. It explicitly accounts for the distinctly non-linear relationships between size, effort, and time. To see the benefits of this approach, let’s look at how project duration relates to simple (SLOC/effort) productivity.
