More than a living

Sometimes, you can provide too much detail.

What? Rick? Mr. Over explain everything? Surely you jest.

No, I’m serious. (Re-reading this post, I realize I have committed this sin, yet again.)

Let me give you an example.

If you are around me for any period of time, you’ll hear me utter a common phrase.

“I’m not a designer.”

I realize that I’m not a designer. I don’t pretend to be. And I try to be as forthright about that as I can.

I’ve worked with designers and other creatives for a long, long, long time. By comparison, the fact that I’m not a designer has been reinforced, time and time again.

So, I’ve learned to work with creatives in ways that get us both producing the best results possible. And I like to think that I tend to do a pretty good job. Usually.

But I also makes mistakes.

As we’ve been developing Kumquat, I’ve made this “too much detail” mistake a few times.

I’ve been trying to be helpful. I’ve been trying to provide analogy and construct in the hopes that it could be something upon which to improve. A starting point.

But it hasn’t. Instead, it became a template.

Admittedly, Kumquat is truly a labor of love. And I’m emotionally tied to it. And I think about it. A lot. (Yes, I’m too close to the problem.) So, I might provide my recommendations with a bit of fervor. But I always try to couch them as suggestions not dictates. I try to provide concrete examples or specific features or interesting functionality that would make it better. And when I do, I provide it with the caveat that it is not the solution, rather it is a potential solution to the problem.

I know it may not be the best answer.

But I feel obligated to provide explicit detail to describe a problem. To give the recipient all the facts. To help illustrate one possible solution to the problem.

In doing this, I hope to receive feedback along the lines of “That’s an interesting (ahem) take on it. But maybe we could think about it this way…”

I always expect people to be looking for a better way.

Best laid plans.

The truth of the matter? We all deal with bad clients who provide specific detail and don’t want critiques. Who don’t want a better solution. They want you to do what they say. What’s more, we’re all exceptionally busy. So, bringing an existing idea to fruition–without a great deal of additional questioning or reframing–is often the most efficient way to complete the task, for everyone involved.

But when you’re expecting creativity–as opposed to production–this type of response can be frustrating.

And that’s where my “too much information” mistake exacerbates the problem. You see, that explicit detail impairs creativity. Rather than enhancing it.

It provides an answer, instead of a riddle. It provides an end, instead of a beginning.

So the next time you’re working to solve a problem, try asking the question. Instead of providing the answer. You’ll not only get the type of feedback you’re seeking, you might actually get some really creative solutions.

Try eliminating some of the information. Too little rather than too much. See what happens.

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.”