Last week, Carl Erickson of Atomic Spin referenced a study performed by Doug Putnam several years ago:

A study done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Since then, QSM has performed several studies investigating the relationship between team size and metrics like project scope, productivity, effort/cost, and reliability. The results have been surprisingly consistent regardless of application domain, technology, or year group.  I’ll be reviewing what we found in a series of posts.

We are pleased to announce that QSM has received four "Exceptional" ratings from the Army Contractor Performance Assessment Report (CPAR). A CPAR assessment is based on objective facts and supported by program and contract management data, such as cost performance reports, customer comments, quality reviews, and earned contract incentives. The Contractor Performance Assessment Reporting System (CPARS) is the Department of Defense (DoD) Enterprise Solution for collection of contractor Past Performance Information (PPI) as required by the Federal Acquisition Regulation (FAR).

Having provided software estimation tools, training and consulting services to the Army since 2004, we very much appreciate their feedback. We try to hire the best people in the business and hold ourselves to a high standard of exceptional performance on all our contracts. These recent CPAR ratings clearly validate the quality of our staff.

Read the full press release.

Paul Below will be presenting "Optimal Project Performance: Factors that Influence Project Duration" at the 2012 Better Software West Conference on Thursday, June 14 at 4:00 PM.

Speedy delivery is almost always a primary project goal or a significant project constraint. To shorten project duration without sacrificing quality or budget, you need to know where to focus the team’s efforts. Mining the QSM database containing many quantitative metrics and numerous qualitative attributes, Paul Bellow shares the factors that have the greatest influence on project duration. While he’s at it, Paul debunks a couple of myths. For example, many managers consider team skill to be important in determining duration of software projects—not so. The most important factors are certain types of tooling, architecture, testing efficiency, and management/leadership skills, which Paul explores in depth. Learn a technique for normalizing your projects for size by computing the standardized residual of duration. Leave with new facts and data on how to improve your development skills and practices to increase velocity and keep the quality your customers expect.

We are pleased to announce that the Office of the Deputy Assistant Secretary of the Army for Cost and Economics (ODASA-CE) has contracted QSM to provide a comprehensive cost methodology, which includes tools, consulting support, and on-site training. This contract is a continuation of a successful working relationship between QSM and the Army that began in 2004. With the new contract, QSM will be providing estimation assistance on major ACAT 1 programs (major acquisition programs).  QSM will also help establish a metrics database with software data from the Defense and Cost Research Center (DCARC) and from DASA-CE data collection efforts. This database will be used for program analysis and evaluation. 

Read the full press release here.

"Everything should be made as simple as possible, but not simpler."

-  Albert Einstein

How’s your software measurement program doing?  Is it well funded and supported by management, or do you worry about your job the next time the organization decides it needs to be “leaner and meaner”?  Many measurement programs are cancelled or fade into meaningless obscurity.  Why?  Some things are out of your control; but here are a few that will improve your odds for success:

We’ve all heard the cliché, "Work smarter not harder."  In an article he wrote for ACM’s Communications magazine, Phil Armour wonders, “If we were smart enough to do that, wouldn’t we already be doing it?” Sometimes we simply don’t know how to work smarter.  But sometimes we don’t work smarter because we choose ... or are not allowed to do things right the first time. 

Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”  Sharpening our axe requires several things:

Software is everywhere in modern life - from automobiles, airplanes, utilities, banks, to complex systems and global communications networks. They run the gamut from tiny applets that comprise just a handful of instructions to giant systems running millions of lines of code that take years to build.

Software professionals are at the front lines of this information revolution.  This post addresses Frequently Asked Questions about measuring the size of software applications after they’re finished and estimating the work for a project that has yet to be started. We hope it will help software professionals do a better job of describing what they are building for their companies as software continues to grow in strategic importance to our companies and to our daily lives.

Question:  What do we mean by the term, “Software Size”

Answer:  For starters, think of T-shirts – Small, Medium, Large, or Extra-Large, or houses that can range from a small summer cottage all the way up to a 20,000 sq ft Hollywood mansion on a sprawling estate.

So it goes with software. You can have a small program with a few cool features, or a huge, complex computerized trading system for the New York Stock Exchange comprised of millions of lines of code, and everything in-between.

Question:  I have a large project and its size is 20 people. Is that what you mean?

Answer:  Not quite. That’s actually the number of the people on your team, or number of staff resources on the project.  It’s not the amount of functionality, or the volume of software created by a team of that size. 

Question:  Ok, so you’re saying that small feature sets for a software program - or a long list of features - is what you mean by the size of the software. Do you also mean lines of code?

QSM has been collaborating with Forrester Research on a report focused on the current state of Agile development. Prior Forrester data shows an adoption rate of about 38% among developers in 2010 and continuous growth YoY in the last three years. However few have really scaled it to the enterprise level. Have you?

To get a better data representation, we encourage to participate in this survey. Tell us about your current and future Agile development plans. This survey will ask questions like: 

• What are the expected and achieved benefits of Agile?
• How is Agile being adopted?
• What is Agile actually improving in organizations and how are results being measured?
• Which Agile practices are the most commonly used? 

To participate in this survey, click here.

More Agile resources from QSM:

• Estimating Agile Projects Webinar 
• Beyond the Hype: Thoughts on Agile Development

Here's a risk question for you:

If today’s weather forecast predicts a 40% chance of rain and it actually rains, was that forecast “inaccurate”?  If the weather channel predicts a 40% chance of rain, but the sun shines all day, was the forecast “accurate”?

Software project estimates, like weather forecasts, should always be accompanied by some explicit attempt to quantify the risk that the actual outcome will differ significantly from the estimated outcome.  Estimates delivered without explicit risk assessment are more like targets: goals someone wants to achieve.

It turns out that whether it rains or not is actually a poor measure of forecasting accuracy.  A 40% chance of rain forecast is accurate if, on 100 days where the forecast said 40%, it rained on 40 days and didn’t rain on 60. Likewise, the accuracy of an individual software project estimate is not determined by whether the project actually achieves its committed estimate.  We can see this with a simple example: if SLIM-Estimate predicts only a 10% probability of achieving a schedule but the organization decides to commit to a plan with a 90% chance of failing, we could actually consider the estimate to be “more accurate” if the software project fails than if it is successful.

What most organizations are really looking for is not so much accurate estimates as accurate commitments, where the commitment is based on the estimate plus an appropriate level of risk resourcing.  But even with best contingency planning, there is always a finite chance of “failure”—it’s just a lot less than if we don’t resource risk. 

After being away from QSM and the software world for three years, I was blown away by SLIM v8.0's dynamic product integration. I knew it was coming, yet I was still impressed by the simplicity and power of analysis promoted by real-time data and tool links across the SLIM Suite that frees managers to focus on the important program issues.

SLIM-MasterPlan is the center of the SLIM Suite product integration.  It improves upon previously existing program management features of aggregating multiple SLIM-Estimate projects and ancillary tasks with two new capabilities: 

• Linking SLIM-Control workbooks to provide real-time project tracking and control at the program level 
• Performing What If analysis at this higher management view to consider a wider range of potential outcomes.

The What If analysis feature is what I want to highlight.

A good personal development coach knows the "power of the question."  Questions lead to discovery, innovation, and action that brings about positive change.  Better questions lead to better answers.  SLIM's power and distinction has always been fast and easy evaluation of the impact of change, and exploring the realm of possible outcomes.  That's what we are doing when we ask ourselves "What If…?" (or our boss asks us - and we better know the answer!).  SLIM's solution logs make it easy to compare estimates, plans, and forecasts to alternative solutions, QSM trends, and your historical project database.