In a recent, highly-discussed article for Dr. Dobb's, QSM's Carol Dekkers asks a tough question: why are we so woefully poor at estimating software projects? It's a tough pill to swallow considering software developers are among the smartest people on the planet, often boasting advanced degrees in mathematics, engineering, or computer science. Yet study upon study cites that less than one-third of projects are delivered on time or on budget. The problem of software project estimation is not straightforward. To get the heart of the issue, Carol Dekkers takes us through the five top misperceptions about software estimating, and what we can do to address them.

Read the full article on Dr. Dobb's!

I think it’s safe to say that nobody really enjoys hearing bad news.  It’s especially hard if you’re the person who has to deliver the bad news, particularly to a superior.  How will your boss react?  Will you be the one held responsible (unfairly) for the project failure?  These are all reasons for keeping the ‘bad news’ to yourself and letting those in charge find out on their own.  

I’ll share a story about one of the first jobs I ever held, as an assistant manager at a summer swimming pool.  My supervisor had a very hands-off approach to management and would often rely on me and the other assistant managers to handle the day-to-day operations of the pool.  Whenever I would deliver less-than-favorable news to him, such as our pool vacuum breaking, or a health inspector dropping by to schedule a visit, my supervisor would literally stick his fingers in his ears and say “La la la la la, I can’t hear you.  Taylor, you know how I feel about bad news.  Fix the problem.”  This put me in a very awkward situation, because as a high school student, I didn’t necessarily have the training or the authority to fix every problem myself, in order to shield him from the ‘bad news.’  

Unfortunately, this type of management exists beyond the pool house and can frequently be found in the corporate world as well.  In an environment where your reputation can mean everything, stakeholders can be very reluctant to receive bad news about the status of their project.  The silver lining in this is that receiving ‘bad news’ isn’t necessarily always a bad thing.  Allow me to explain.

Dear Carol: 

I work in IT and we do a lot of our software development projects based on pre-defined delivery dates (no one really knows where they come from).  Sometimes this works out, but usually we end up delivering the project months late because we had no idea the project was as big or as complex as anyone had originally thought. A friend says his company uses “t-shirt sizing” for software project estimates and I’ve never heard of it. What can you tell me about this new approach?

- I’m willing to learn from the fashion industry 

Dear I’m willing:

T-shirt sizing has been around in one form or another for a few years but it is not a widespread mainstream estimating method.  It is a quick and dirty way to estimate software size using ranges of size.  Once you have the relative size (e.g., XS, Small, Medium, Large, XL, XXL, or larger), you can enter it into several different estimating tools as the size on which to base the estimate. While this doesn’t give you a guaranteed size for the software to be delivered, it is better than not having any idea of the size.  Size (scope) is one of the three main tenets of the triple constraints (scope, budget and schedule) for project management.  Given one, you can estimate the other two.

Can advances in data-driven estimation turn software project failure into a distant memory? Well, if learning from experience is the key to success, imagine what you could do with real-time access to three decades of research, thousands of projects and more than 600 industry trends. In this article, originally published on Projects at Work, QSM's Larry Putnam, Jr. identifies key benefits of employing estimation best practices for project success.

As Co-CEO for QSM, Larry Putnam, Jr.'s has more than 25 years of experience in software measurement, estimating and project control. He joined QSM in 1987 and has worked in every aspect of the business, including business development, customer support, professional services and now executive management.

Read the full article!

QSM hosts a free advice column for software professionals who seek help to solve project management, communication and general software project issues. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!

Dear Carol: 

I’ve been a member of many software development teams and I simply don’t understand the point of doing early project estimates before we know what are the requirements. It just causes problems once the project starts because the estimate becomes the budget and drives the schedule. Obviously, the estimates are wrong because they are based on flawed/incomplete data, so why would anyone even bother doing an estimate when the budget and schedule go awry as soon as the project starts? Estimates cause management and project managers to “stress out” trying to meet an artificial date and budget – we ought to abandon estimates and just get to work on the project! What am I missing here? 

- Looking for answers     

Dear Looking:

You’re not the first person to question the point of estimating before requirements are known; it can seem futile when it seems that they turn into budgets and schedules.  Even though there is uncertainty (and risk) with early estimates, there are reasons that companies do early estimates:

As 2013 begins to wind down and everyone begins making plans for 2014, I wanted to take a moment to reflect on all the projects we’ve worked on this year.  Despite our relatively small company size, we’ve managed to accomplish quite a bit over the last year.  Below, I’ll recap everything we’ve been up to and also highlight some of our great resources and publications in case you missed them earlier:

One of the most common objections we hear from companies with regard to getting started with top-down estimation is that it’s not needed, because they already have a detailed planning spreadsheet in place. Customers will concede that their estimation practices are not perfect, but that they are working “OK.” But, when it comes to spending your company’s money on software projects is “OK” enough?  

If you were unable to attend our recent webinar, Bringing Estimation and Business Intelligence to the Enterprise, a replay is now available.

Successful software development estimates depend upon more than just inputs, especially at the enterprise level. They require collaboration between stakeholders, consistency in estimation methods, and historical basis. It's also essential to account for uncertainty and risk. In this webinar, Keith Ciocco demonstrates how SLIM-Estimate and SLIM-WebServices work together to bring reliable business intelligence to the enterprise, while leveraging historical data to increase estimation accuracy and credibility.

Watch the replay!

image via Techwell

A large part of software estimation is dealing with the unknown. At the earliest stages of a software project, the uncertainty surrounding schedule and budget is at its highest and diminishes as a project reaches completion. In the estimation community, we refer to this as the "cone of uncertainty." Of course, it is at the widest point of this cone where estimation is typically needed. So how can organizations keep their customers feeling secure and informed when requirements are still being flushed out and budgets aren't yet established? In his recent a blog post on Techwell, Noel Wurst identifies strategies for flattening the dreaded cone of uncertainty.

Read the full post here!