The Hogan Formula For Software Estimation

July 26, 2015 at 6:20 pm in Tech, Work

Measuring how long a software project will take is a futile endeavor. Unfortunately, people who hire software developers have a habit of asking for the impossible. Like when they want you to build a Facebook clone in 2 weeks for $200.

So to appease my clients and managers over the years, I developed a formula to somewhat accurately address the “how long will it take” question. And despite it being a bit tounge-in-cheek, it’s startlingly accurate when you sit down and think about it.

Here is the formula:

TimeToComplete = (bestGuess * 2) + 1 --> Shift to the next unit of time.

Here’s an example. Someone comes to me and wants me to build a 5 page web site for them. My immediate thought is that building 5 pages of HTML with a Bootstrap theme should take me about 6 hours. That’s based on my experience as a developer over the years. I know I’ll use a bunch of pre-existing things and I know my way around CSS and HTML.
So if I run that through my formula, here’s what I get:

(6 * 2) + 1 = 13 hours --> Shift to next unit of time = 13 days.

It’ll take 13 days to complete this project, according to this formula. Does that make sense? Let’s look.

Day 1: I meet with the client and gather some specific details about the project. It turns out that the client needs 6 pages, not 5, but one of them is a contact form. I’ll be writing a little PHP. Client insists they have all the copy already written for all the pages, and they have photographs. After the meeting, an emergency for another client comes up and I have to deal with that. I can’t spend any more time today working on this project because I’m burned out.

Day 2: I build a mockup of the homepage in HTML with Bootstrap. I then develop a couple additional options. I put a PDF together and I show it to the client by sending an email. I get no reply.

Day 3: I follow up with the client. No reply.

Day 4: It’s Saturday.

Day 5: It’s Sunday.

Day 6: I call the client, since email isn’t working. The client replies that they like the first mockup idea I sent, and wants to proceed with that. I ask for content for the “About” page. They tell me they’ll have their office person send it over. I build out the pages in the template they chose using mocked up content. Productive day.

Day 7: I push the work up to a staging server so the client can play with it. I still don’t have content. I send the URL to the client. They play with it but tell me it doesn’t work on their machine. I test the site in multiple browsers and everything looks fine I head to the client site to see what the issue is with the site. The site comes up fine. They were confused because the text “Lorem Ipsum” was displayed on the page instead of the text they wanted. I ask again about the copy they were going to send over, and they hand me hand-written notes, saying their office person was out of town this week.

Day 8: I key in the content, because I’m nice. I push up the new site. They send me over some photos which I need to adjust to fit. This takes most of the day, but the site is eventually deployed. I get on the phone and walk them through the contact form. They have changes.

Day 9: I’m unable to work on the site much due to other obligations. But I do fix the contact form and ask them to test it.

Day 10: The site is complete, but I’m waiting on final approval from the client. The person in charge has taken a long weekend.

Day 11: It’s Saturday again. But the client does approve the work, with a couple of minor changes. I state that I can make those changes on Monday and I can make it live on Monday.

Day 12: Sunday again.

Day 13: I work through the changes and get on the phone with the client, who says things look great. I put the site live and they use Dwolla to send over a payment. Done.

Does that sound like a realistic scenario?

The problem I’ve found is that developers only think in terms of code. So when you ask “How long will it take to get something done” they immediately drop into “How long would it take to code up an untested first version of something based on what I’ve done before?” As developers, we have to remember that software is 20% code and 80% people. People need time to think about things, they need time to review, and they need time to recover from mistakes or bad choices. We have to factor in vacations, distractions, and many many other things.

Developers love to be a hero with their estimations. I’ve done this. I’ve said “Oh yea that’ll be easy. I’ll just get that done in 10 minutes. And sure enough, two days later I’m still working on it.

Now, in the only-somewhat-fictional scenario I outlined, the client had all their ducks in a row. They paid on time. I didn’t have to work with the ISP to recover their web site password and login information. I didn’t have to deal with people who nitpicked every pixel of the design. All of those things factor in to how long it takes, and all of those have nothing to do with how fast you can write code.

You will have to provide time-based estimates to people who don’t understand software. Do right by them, and yourself, by doing whatever you can to be as honest as possible. Maybe my formula will help you make a more informed decision. Or maybe it can just be a joke between you and your team. Because when you’re talking about a project that would “only take six months” and you’re on year two.

1 comment

One Response to “The Hogan Formula For Software Estimation”

  1. I love it! I love the shift in time. So 13 hours in 13 days, that means I only have to work 1 hour a day!!!!

    Just kidding.

    I would be curious to know how long this scenario actually took, if it is not hypothetical. You showed 13 hours. Was it or would you expect it to be finished in 13 hours?

    Also, do you estimate 13 hours, but do you quote 26 hours for a 50% PM? Or does your billable hourly rate contain a 50% PM?

    In other words, I have worked where I bid 13 hours at $40 an hour, but I had to maintain a 50% PM, so I quoted 26 hours at $40, but only got 13 hours to complete it.

    I’ve worked in corporate software for so long. I’ve seen people look at a project and decide it is worth $10,000 to the customer. They never actually mapped out what had to be done, factor in changes, etc. They were sure they were going to make a huge profit. We have a phrase “All’s you gotta do…”.

    But rarely does anyone truly get the customer involved as they develop, plan for changes, bug fixes, support, training, documentation, and plan for updates to core system in conjunction with this new “special”.

    We were losing our shirts because we wrote specials that weren’t tested well enough, had all sorts of “fixes” (real and customer changes) after billed, and new updates to the core systems were that made the special incompatible.

    But hey, the line item for specials was impressive.

    Loved your blog post, keep it up!

Leave a Reply