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.

Sometimes business life follows literature. Recently, I came across the following quote and I had to pause:

“Before we build a better mousetrap, we need to find
out if there are any mice out there.” - Yogi Berra

It reminded me of a conversation I had over lunch 15 years ago, when I was president of the International Function Point Users Group (IFPUG) and Charles Symons was president of the UK Software Metrics Association (UKSMA), where we were talking about the future of software sizing.  IFPUG is the inventor of the original method to size software using a measure called “Function Points.”  Charles is the creator of a similar UK method called Mark II function points and a co-creator of the Common Software Metrics International Consortium (COSMIC) sizing method that was, at the time, still in its infancy.  I’m paraphrasing with the words but I believe it captures the content of our conversation:

“The problem with function points,” Charles remarked, “is that they aren’t yet perfect enough.  What we need is a better mousetrap and the world will beat a path to our door.”

I disagreed saying “I don’t think that’s the problem at all – I think the problem is that world doesn’t yet see mice as a problem.”

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: 

My manager frequently says “You can’t manage what you can’t measure” and then tells us to collect more and more metrics, willy-nilly. We’ve done this for years now and it just doesn’t seem to make sense to collect all this data that’s never used, when we’ve got better things to do like developing software. What can we do to make him stop this unproductive exercise?

– Over Metricated

Dear Over: 

 This is a common situation in software development: management pursuit of metrics without a clear plan to use them.

The “you can’t manage what you can’t measure” is a paraphrase of Tom DeMarco’s quote, “You can't manage what you can't control, and you can't control what you don't measure.”¹ What is interesting is that DeMarco’s follow-up quote 13 years later is seldom cited: “Metrics cost a ton of money. It costs a lot to collect them badly and a lot more to collect them well... At its best... metrics can inform and guide developers, and help organizations to improve.  At its worst, it can do actual harm… And there is an entire range between the two extremes...”² 

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:

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!

Hi Carol:

Thanks for this excellent initiative. One of my key clients is planning to move away from FP counting as they think it’s expensive, takes time, does not measure non-functional work and also they do not want to invest in auditing the FP results. Instead, they are considering using LOC. We have tried explaining them all the shortcoming of LOC but no use. In fact we advised them to use SNAP along with FP but looks like they are just focusing on cost!

In your article on 'Size Matters', I noticed you had mentioned few other techniques to measure size like RICE Objects and Implementation Units. Would like to learn more about these and would like to understand if these are industry standards. Can you please share some insights?

– Sizing Enthusiast

Dear Sizing:

Because you are someone who knows the value of functional sizing (aka function points,) it is frustrating when management focuses on the cost of measurement rather than the value delivered.  I’m wondering whether there is a disconnect between the perceived value and the cost of FP counting. There are a couple of potential issues here that I’d like you to consider before we get into the sizing alternatives

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:

Is your agile team’s velocity constant from sprint to sprint? No? That’s not a surprise. Many teams assume that their velocity will be constant. In this article, the third in a series recently published on Projectmanagement.com, QSM's Andy Berner explains why that’s not the right expectation--and how that affects how you use this metric.

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!

In our recent webinar, Function Point Analysis Over the Years, presented by Don Beckett, we received some great questions from our audience. Here are the highlights from the Q&A:

Q: The advice in recent years is to break large projects down into smaller ones to make them more likely to "succeed" by whatever measure. Is the advice now to make projects bigger?

A: I don't know if it's advice, but the data seemed to indicate that there is a benefit to grouping projects by larger size than the projects that are 50 or 100 function points. So I would say, where it's possible, where they can be grouped together, it would be a good idea.

Q: Why do you use the PI (Productivity Index) as opposed to the industry standard hours per function point or function points per person month?

A: Well hours per function point and function points per person month are ratios that take the ratio between effort and size and what we have found is that the schedule has a huge impact on how productive a project can be. The PI incorporates three major things: the size of the project, the amount of effort leveraged against it, and the time required to do it, so in a sense, it accounts for schedule, which function points per person month does not do. So that's why we use it.

Q: How do we convert a project from SLOC to function points to find the PI for a specific project?