Software projects often commit to unrealistic schedule and budget expectations due to little or no information about the size and scope or productivity. Yet the business reality is that projects must be estimated early in the life cycle to support business goals and strategic planning. These challenges can be overcome with a transparent and collaborative estimation process. It depends on metrics collection, analysis, risk comparison, and a structure for sharing the right information with the right people at the right time.

In an article recently published on Projects at Work, Laura Zuber explores the benefits of collaborative software project estimates and identifies best practices for implementing them.

Read the full article!

In the recent Washington Post article How the Obama Campaign Won the Race for Voter Data, Joel Kowsky writes about how the 2012 Obama campaign used analytics to improve their campaign strategy, and to ultimately secure the presidential victory.  

Regardless of where you stand on the political spectrum, it’s hard to argue that Barack Obama’s campaign strategy was anything short of impressive.  As soon as Obama took office in 2009, his team began preparing for his 2012 campaign.  From the start there was a strong emphasis on measuring the campaign’s progress.  Jim Messina, Obama’s 2012 campaign manager, stated 

“There’s always been two campaigns since the Internet was invented, the campaign online and the campaign on the doors.  What I wanted was, I didn’t care where you organized, what time you organized, how you organized, as long as I could track it, I can measure it, and I can encourage you to do more of it.”

The team began by conducting a postmortem study on their 2008 campaign where they analyzed the number of homes visited, phone calls placed, and voters registered by each field organizer and volunteer.  The result was a 500 page report which highlighted areas of improvement for the 2012 campaign.  

The suggestions led the Obama campaign to invest in building customized software that would integrate all the data the campaign had collected on voters, donors, and volunteers and link to individual voter profile.  This software analyzed previously collected data to calculate the likelihood of candidate support, the likelihood of election day turnout, and the degree of persuasion for each voter.  

Function point analysis has played an important role in software measurement and analysis for 30 years, but what will be the role of function points in the future? Will they have staying power? Expanding off of a recent article for IFPUG's Metrics Views, Don Beckett looks at the QSM software project database and examines a set of validated projects counted in function points that have completed since the year 2000 to see what they tell about productivity, schedule, and staffing. We are fortunate to have several thousand projects in this sample to work with as this allows us to parse the data many different ways and still have enough projects to be statistically significant. For this study only unadjusted function points were used.

Read the full white paper!

It's no secret we're advocates of smaller teams, but it's always nice when others agree. Baseline's Tony Kontzer leveraged some of our most recent data for an informative slideshow about team size.

At one time or another, almost all information technology professionals have heard cries for more resources. They may even have been the one asking for help. "If only there were more people available for this project," they've said, "then maybe it would get done on time." Well, it turns out that more staffing is not the equivalent of optimal staffing. In fact, smaller project teams are more productive and can complete projects cheaper and faster than larger ones, according to a recent study from software life cycle consultancy Quantitative Software Management. That should be good news for IT departments that have seen their ranks depleted in recent years.

To see more results from QSM's recent study, read Don Beckett's post on the correlation between staffing and schedule.

It’s becoming clear to organizations adopting Agile methods that one still needs to estimate how long a project or a release of a product will take. It won’t suffice for businesses to simply take guesses or accept unreasonable constraints. We must be able to derive credible estimates, based on a history of similar projects. How can we estimate a project in advance while still maintaining the ability to manage the backlog in an agile manner?

In this article, recently published on Projectmanagement.com, QSM's Andy Berner answers that question, compares release-level estimation to the techniques used for iteration estimation, and gives some pointers on getting started with release estimation in an agile environment.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article here!

In my previous blog post, I discussed the similarities between software and home improvement projects, and how the planning process greatly impacts the project lifecycle.  Better planning in and of itself is a great way to streamline the Construct & Test Phase of development.  However, when you plan is equally important to the development process.

While watching home improvement shows, like Discovery Home’s "Flip That House," one of the primary concerns of the project manager is often how quickly the team can get started so that they can meet their target deadline.  One cringe-worthy line that I distinctly remember was “as long as we have activity, we have productivity.”  Unfortunately, activity and productivity do not necessarily go hand in hand.  

For instance, in software development a project manager may tell a developer at the beginning of a project to start building a system.  If the requirements have not yet been determined, it’s challenging for the developer to build anything.  Yes, it’s possible for the developer to start building something while the project manager decides what should actually be built.  However, once the requirements are finalized it’s very likely that the developer will have to go back and rework the code so that the system will have the desired functionality.  

Agile is all the rage these days, but what happens to Agile projects when they're forced to scale to the size of major government enterprise initiatives? In this article, originally published in the May-June 2013 issue of Modern Government, Larry Putnam, Jr. looks at 93 Agile projects completed between 2002-2012 to see how these projects fared as their sizes increased. The study examines Early Adopters (2002-2008) vs. Later Adopters (2009-2012), as well as analyzing Agile vs. Non-Agile projects. The results may surprise you!

Read the full article here.