How to Use Big Data to Improve Your Software Projects

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.  

New Article: Is It Bigger Than a Breadbox? Getting Started with Release Estimation

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, 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!

Blog Post Categories 
Estimation Agile Articles

"Building an Estimation Center of Excellence" Webinar Replay and Q&A Highlights

If you were unable to attend "Building an Estimation Center of Excellence," the webinar replay and slides are now available. Here are the Q&A highlights:

How do you handle estimating change requests (scope creep). Do you estimate the entire project again, or do you just estimate the impact of the change requests?

It would depend on where we were in the project lifecycle. If we were still fairly early on (somewhere between the feasibility assessment and the refined estimate), I would add those into my sizing assumptions and re-estimate the project. If I'm already farther along and I get changes when I'm already constructing the system, then I would use my adaptive forecasting and add those in within the context of everything else I have to build as part of the deliverable release. This is because the impact will be bigger if we're farther along and we already have everything integrated and we're into testing versus earlier on when not a lot has been constructed. QSM's forecasting capabilities will be able to tell us the impact on schedule and cost.

Should the center of excellence estimate all projects regardless of size, or if the project is small, then have the project teams estimate it?

Blog Post Categories 
Webinars Estimation

Updated Performance Benchmark Table

The latest version of QSM’s Performance Benchmark Table is live!

QSM is excited to announce the release of their latest version of the Performance Benchmark Table.  Last updated in 2009, the table provides a high-level reference for benchmarking and estimating IT, Engineering, and Real Time Systems.  It displays industry average duration, effort, staff, and SLOC (or FP) per Person Month for the full range of project sizes encompassed by each trend group. 

The results were analyzed from a database of 1,115 high or moderate confidence projects completed between 2008 and 2012.  Sixteen countries and 52 different languages were represented in this sample.  In addition to the industry average, minimum and maximum values were also provided for each metric to help give a range of possible results.

The project sizes differed somewhat from the previous version to accommodate the new range of sizes present in the data.  Rather than using the same project sizes across trend groups, we selected project sizes specific to each trend.  Since Business projects are typically smaller than Engineering or Real Time projects, this allows readers to select a size relevant to the type of project they’re estimating or benchmarking.  

This tool can be particularly useful to developers and/ or project managers who are new to estimation or do not have historical project data.  

Blog Post Categories 
Benchmarking Estimation

Webinar - Building an Estimation Center of Excellence

On Thursday, June 13, at 1:00 PM EDT, Larry Putnam, Jr. will present Building an Estimation Center of Excellence.

The pressure to succeed in software development is higher than ever - the current economic climate demands we do more with less, there is fierce global and domestic competition, time-to-market expectations are high, and your company's reputation is on the line. When projects fail, the failure to meet expectations is more often an estimation or business decision failure than a production or execution issue. In this webinar, industry expert Larry Putnam, Jr. takes you through the key elements and step-by-step process for setting up an estimation center of excellence that will ensure your projects succeed.

Larry Putnam, Jr. has 25 years of experience using the Putnam-SLIM Methodology. He has participated in hundreds of estimation and oversight service engagements, and is responsible for product management of the SLIM Suite of software measurement tools and customer care programs. Since becoming Co-CEO, Larry has built QSM's capabilities in sales, customer support, product requirements and most recently in creating a world class consulting organization. Larry has delivered numerous speeches at conferences on software estimation and measurement, and has trained - over a five-year period - more than 1,000 software professionals on industry best practice measurement, estimation and control techniques and in the use of the SLIM Suite.

Watch the replay!

Blog Post Categories 
Webinars Estimation

Estimating for the Business Plan

Having worked in sales and customer service at QSM for over 17 years, I speak to hundreds of professionals each year that are directly or indirectly involved with software development projects using many different development processes. One of the things that I hear from time to time is that estimating is not as important when working with more iterative development methodologies. Some of the reasons I hear most often are that “team sizes are smaller,” “work can be deferred until the next iteration,” “we are different,” and “we are agile.”

As I dig deeper though, I find that the fundamental questions that software estimates answer are relevant, no matter what development methodology is being used. Before committing to a project, executives and managers need to determine reasonable cost, schedule, and how much they can deliver. This is when not very much is known and before any detailed planning occurs.  Estimating helps mitigate risk early in the project lifecycle. Companies also need to have reliable information in order to negotiate with clients. How can we negotiate a schedule and a budget on any project without a defensible estimate? 

When looking at QSM research based on our database of over 10,000 industry projects, a common theme that we see in failed projects is that development team performance is often not the issue. When it comes to missed schedules and budgets, many of the problems occur when expectations are too high and when estimates are not a priority. If we don’t have a reliable estimate up front before the project starts, it’s tough to plan ahead. 

Blog Post Categories 

What Basketball Can Teach Us About Software Estimation

I discovered early on that the player who learned the fundamentals of basketball is going to have a much better chance of succeeding and rising through the levels of competition than the player who was content to do things his own way. A player should be interested in learning why things are done a certain way. The reasons behind the teaching often go a long way to helping develop the skill. — John Wooden

John Wooden is regarded as one of the greatest college basketball coaches. He believed that after talent, courage, and character, fundamentals built successful teams. Successful software projects result from knowing and practicing fundamentals as well, and it begins with estimation.

I thought it would be fun to see if Coach Wooden, by way of noted quotes, could help simplify a few SLIM core concepts.

John Wooden

SLIM Core Concepts

"Don't let what you cannot do interfere with what you can do."

Estimates are uncertain. The accuracy of your estimate depends on the detail and relevance of the data upon which it is derived. Do not succumb to “paralysis by analysis.” You cannot commit to a detailed estimate early in the life cycle because you simply do not have the data to support it.  What you can do is generate a reasonable expected result within a range of potential outcomes based upon industry data or your past performance. The estimate will be good enough to allow data-driven decisions and negotiations.  You can improve the estimate as soon as more detailed information is available.

Blog Post Categories 

Does Your Estimate Accurately Reflect the Five Dimensions of Software Trade-offs?

A recent series of posts by Karl Wiegers eloquently discusses the "reality of tradeoffs" software professionals deal with every day, going beyond the typical success drivers (time, cost, and quality) to include product features and staff. He shares inspiring practical information by making distinctions between constraints, drivers, and degrees of freedom, each representing the amount of flexibility the project manager has to adjust a key factor.

SLIM-Estimate has modeled the non-linear interdependencies of these metrics for over thirty years. It accounts for Wiegers’s five project success factors explicitly, showing the tradeoffs between them in real time. I have mapped Wiegers’s Five Dimensions to SLIM-Estimate’s parameters to show how you can use SLIM-Estimate quantify the trade-offs Wiegers describes.

Blog Post Categories 
Estimation Tips & Tricks

Process and Tools Together

At QSM we offer Estimation Process Consulting Services and the SLIM-Estimate tool. In my 16 years at QSM, I have probably spoken with hundreds of project managers about the pain that they have in the estimation area. Many tell me that they want to finish implementing their process before they bring in a tool.

One of the things that I have learned over the years is that it can be extremely beneficial to bring in the tool while the process is being developed. A successful estimation process implementation is about getting the right project data in the right place for consistent collaboration and results. Implement both the process and the tool at the same time and you can save a ton of money in rework costs down the road. 

A good estimation tool provides a roadmap and a communication vehicle for a successful estimation process. The tool collects the core metrics that the process requires. It also streamlines the results to give the user exactly what they need to know: risk, size, duration, effort, reliability, and productivity.

Some will spend years writing and implementing their process. Why not get the estimation tool in place sooner to make things easier?

Blog Post Categories 

For More Accurate Software Estimates, Avoid Hidden Risk Buffers

A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding.  The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’.  The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit.  Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk.  Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management.  It is documented.  It is measured and therefore managed.”  Ms. Brockmeier is correct in promoting contingency as the better management tool.  The challenge is having a method to measure and document this contingency and the known unknowns it is buffering.

Implicit Risk Buffer

Padding is a natural result of bottoms-up, effort-based estimation techniques.  Estimating low-level WBS elements creates more opportunity for padding, because the number of unknowns grows with the task list.  The estimator is consciously or unconsciously assessing the risk of each task, considering its dependencies and complexities.  What is being implied in the effort estimate is: 1] an assessment of product size and complexity, and 2] a productivity valuation.

Blog Post Categories 
Risk Management Estimation