Since I’m in a self-deprecating mood, now seems to be as good of a time as any to write the next entry in our series of mistakes surrounding the development of Kumquat.

Kumquat launches on February 14. No really. It says it right there on the schedule. February 14, 2007.

So where is it?

Well, it didn’t launch then. So, then it was going to launch in mid-March. And then April 1. And then Tax Day.

Again, where is it?

It’s still in testing and development.

I know, I hear you, “bad estimator.”

Yes and no.

I’ve estimated creative projects for a long time. I’ve estimated Web projects for more than a decade. Heck, I’ve even estimated construction projects that came in closer to on-time than this one.

So where was the disconnect?

Well, Kumquat is still on the shelf because of two critical mistakes. Two mistakes that I made.

1. I assumed that a small team would need less slush time.
2. I failed to mitigate the risk in the schedule, given that each person played such a large role.

As for #1, I had in my head that most large and unwieldy projects, by design, needed a great deal of slush in the schedule. And by “slush” I mean the difference between the actual work effort and the date on which that work effort is said to be due. Because inevitably, on big projects, things happen. So, you have to be prepared.

I had assumed that, given the size of the team, that we could keep to a tighter schedule. Run lean and mean as it were. I assumed that passion would be a big driver.

And I did account for slush. Just slightly less than for some big-team projects I’ve managed.

But guess what?

We ate that slush up.

Which brings us to #2, failing to mitigate risk.

Why do smaller teams actually need more slush? Because each person plays such a huge role in the process.

In larger projects, there is always someone to pick up the slack. An understudy. A boss. Someone to keep the process moving. But on smaller projects? No safety net.

Every illness. Every failure to respond. Every failure to handoff. Every slipping of the schedule. Every little thing has a much larger impact on smaller teams.

But we were lucky, we’re only running against our own desire to make Kumquat available to a larger group. If we were running against a firm deadline, we would be in trouble. Big trouble.

And this isn’t any one person’s fault. Other than mine, in estimating.

Because things happen. It’s a fact of life. As is making mistakes.

So my advice with small teams?

Estimate the amount of work. Create some slush. Pick a date. Now double the slush. Move your date. That’s closer to your actual delivery date. Do this on as small of a scale as possible.

And if you’re running your project with a firm deadline?

Find ways to expand your team. Create an understudy system. Or a safety net system. Figure out some way to keep the project moving when one of your critical components becomes suddenly “unavailable.”