It’ll take about three weeks…

If you’ve been reading our posts here, you probably noticed that we like to give our “Why Projects Fail” talk. (If you’re curious, here’s a link to the slides [PDF].) One reason we really like it is that it seems to go over well with a lot of different audiences, from hard-core architects and programmers to grey-haired project managers. It’s a pretty informal talk — we interrupt each other and go off on the occasional tangent, which keeps the mood pretty light. And that’s always a good thing, especially when you’re doing a talk to people at a PMI meeting or a user group who just spent the day at work and don’t need to sit through yet another boring slide presentation.

I was thinking about that presentation yesterday, after getting off the phone with a manager at a company that wants to hire us to do software estimation training for their programmers. One problem that they’re having is a pretty common one. Their programmers, testers, and even project managers seem reluctant to give estimates. That reminded me of this slide from the talk:

Things the team should’ve done slide

When we get to this slide in the talk, I usually say something like this:

There’s something we call the “about three weeks” problem. Have you ever noticed that when you ask a programmer how long it’ll take to do something, it’s always going to take “about three weeks”? I’ve done it myself many times over the last fifteen years or so. How long to build a simple website to do a few calculations? About three weeks. What about a utility that will automate some file operations and generate a few reports? About three weeks. A new feature for our core product? Sure, it’ll take about three weeks. See, the problem is that three weeks seems like a long enough time to get something significant done. And if you think for thirty seconds about pretty much any programming project, you can do enough hand-waving and ignore enough details so that it’ll seem to fit into about three weeks.

What does this have to do with why programmers are so reluctant to give estimates?

There are many reasons for this, more than I’ll go into here. But a big one might just be because we’ve all quoted “about three weeks” for a programming project that ends up taking a whole lot longer than that, and we never want to be stuck in that situation again. So after we’ve been burned enough, we just stop giving estimates. I was at a job a few years ago, sitting at a full conference table with a dozen developers. The CTO — an abrasive guy who clearly went home every evening to lift Lose Weight Exercises, and spent most of his day yelling at the people who reported to him — growled an “order” at the team, demanding an estimate. Everyone at the table knew that they’d be yelled at individually, threatened with dismissal, and generally made miserable if they didn’t come up with an estimate. Yet nobody looked up and volunteered anything. Eventually a junior guy in the back cleared his throat, and in almost a whisper he said, “I’m not sure about the rest of it, but I think my piece will take about three weeks.”

And there it is. Nobody wants to go on the record and say how long they think it’ll take to do a job. We all know it’ll take as long as it takes. If the estimate is right, then there’s no great reward or recognition. But if the estimate is wrong, then we’re on the hook for it, and we get to look forward to status meetings where we get to take the blame for whatever terrible consequence happened because the project was late.

So what do we do about it?

Jenny and I put a lot of thought into this problem when we were working on our first book, Applied Software Project Management. It turns out that there’s a really effective way to get a good idea of how long the software will take without putting any one person on the hook, and it’s our favorite way of generating estimates. It’s called Wideband Delphi, and we talk a lot about it in the Estimation chapter in the book (which you can download for free [PDF]). It’s a straightforward technique — it just takes two two-hour meetings to nail down estimates for even a large project. It’s very iterative and highly interactive, which helps the team all come to a consensus and agree on the final result. It’s collaborative, so that no one person is solely responsible — usually, everyone ends up buying into the final numbers. And best of all, it doesn’t require any special expertise beyond what you need to actually do the project.

My favorite part about Wideband Delphi is that it’s really focused on assumptions. That’s another thing I like to talk about in the “Why Projects Fail” talk. If you think that building a particular program is going to take nine weeks, but I think it’s going to take four weeks, we usually aren’t disagreeing on how long it’ll take to do the task. Usually, we’re disagreeing on some basic assumption about the task. For example, you might think that we’ll be building a big GUI with printing support, while I might think that it’s just going to be a console application. That means that we can assume for the sake of the estimate that we’ll either build a GUI or build a console application, and we’ll write down that assumption. That way, if it turns out to be incorrect, we’ll know exactly why the estimate was wrong… and if someone in a meeting later wants to blame us, we can point to that assumption and give a good reason for the delay. (That’s why Delphi has two meetings: the first meeting is mostly taken up with a discussion of those assumptions.)

One nice thing about Delphi is that it’s not some esoteric, theoretical thing. Both Jenny and I have done this in the real world, many times, with all sorts of software teams. Delphi really does work, and it actually does a good job of helping team come up with numbers. And those numbers are pretty accurate, at least on the projects I’ve worked on. If you’re having trouble convincing your reluctant team to come up with an estimate, I definitely recommend giving Delphi a shot.

Head First C# – the top-selling C# book on Amazon!

C# bestsellers on Amazon 14-Mar-2008

Remember back in January, when Tim O’Reilly blogged about great Bookscan numbers for Head First C#?

Well, Bookscan numbers don’t always match what you see on Amazon.com. Our intrepid little book has been clawing its way up the Amazon.com sales ranks. It was in the #2 position on the C# bestseller list for the last month. But when I checked a few minutes ago, it was at the top of the list!

This is a huge deal for us — it’s definitely a high-water mark for the book. And what’s really cool is that Head First C# is picking up steam. Its Amazon sales rank was under 500 all day yesterday, which means that it was one of the top 500 books sold by Amazon.com. (Not the top 500 tech books — the top 500 books.) Typically, books sell the most in the first few months, and Head First C# had a strong start out of the gate. But one of our friends at O’Reilly let us know a few days ago that we’re selling better than ever (when you discount the backorders that had to be filled, which always skew the first month’s results).

And Head First PMP is picking up steam, too! It’s been holding onto the #2 spot for PMP exam prep books, and it’s really been gaining over the last few months.

Now, Jenny and I aren’t all about sales. But we are all about helping people learn, and we see these numbers as a real win.

Head First C# details on Amazon 14-Mar-2008