estimate

How I make very early software cost estimates (Part 1)

Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.

The problem

Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.

The solution

I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:

This is a page from my book, “A Survival Guide for New Consultants”

Contractual matters

“The moment you start seeing life as non-serious, 
a playfulness,
all the burden in your heart disappears.”

Osho

To run a consulting business you’ll need a few simple business service contracts to make sales, but I can’t really provide those for you here. You can get those from your lawyer, or from some of the legal dot-com websites that are available these days.

Software best practice: Never say “X% done”

Note: This is a post from 2007 that I just updated a little bit because I think there’s still some value in it.

A lot of people have written to say that it’s unfair that I think developers should never say “I’m 75% done,” or “I’m 90% done.”

So, to explain myself, here’s why I think you should never use a phrase like that:

How I Estimate Software Development Projects (book cover design)

I like to have fun with graphics once in a while, so when I created my new eBook, How I Estimate Software Development Projects, I took a couple of hours to come up with a cover I kinda-sorta like. I could do much better given a couple of days, but for only working on it for a few hours, I’m okay with this.

How I Estimate Software Development Projects (free PDF)

Over the last few weeks I’ve taken a little time here and there to put my notes on software cost estimating together, and the end result is a free, 100-page PDF that I’m sharing here today. The PDF covers most everything I know about the art and science of estimating the time and cost of software development projects.

At the moment I can’t think of too much to add to the book, as I cover a lot of ground in the book’s Preface, and in its “Three Lessons.” So, without any further ado, here is the download link for the book:

Dear Business Analyst: If you can’t count the Function Points, you’re about to enter a world of hurt

One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you’re doing as a business analyst. For example, here’s one of the guidelines I came up with after I learned about FPA:

If you can’t count the Function Points when you’re about to start developing a software project, you’re about to enter a world of hurt.

Software cost estimation

The last few weeks I've been looking at ways of estimating software development projects using "Use Cases". I'm all over Use Cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.