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.
- I assumed that a small team would need less slush time.
- 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.”
Be careful with small projects & bigger teams:
Some small complex projects need multidimensional teams incorporating varied expertise for implementation. And teams become large(r).
Hiring specialists/consultants (hourly basis) can enlarge the team when needed and minimize slack. However, dedication/focus to (purpose) of project(s) is wanting, and this can be costly.
We have overcome this “catch 22″/dilemma over the years by building an in-house team of a projects director, purchasing manager, cost-control engineer, project engineers & supervisors; and a battery of external specialist design consultants & contractors and labor, awarded assignment after competitive biding.
To offset the large inherent slack associated with such an in-house team profile for small projects, specialist consultants and team of petty contractors and labor is deployed concurrently on several small projects which are generically similar, and in close proximity.
There is slack, anyhow. But the team works with a lot of confidence gained from shared experiences. The efficiency and competitive (intra-project) flavor generated, propels team creativity, and quality and speed of delivery is enhanced manifold, at a very reasonable cost, below industry averages.
Thanks, Iqbal. I appreciate the insight from the voice of experience.
I think my first inclination is to make the timeline more slack, before making the team larger. But, when I’m working against a real deadline, then expanding the team seems the only reasonable means of accomplishing the goal.
My experience is limited to being midway through the process — similar to your situation, Rick. It might be difficult to discern the forest from the trees right now, but I can at least comment on our current state..
I know how it is working in the shadow of a looming deadline. I feel like moving the delivery date is a slippery slope — once you move it once, the urgency of meeting that date naturally slides because “moving it again” seems like more of an option.
For Dust Jacket Review, we’ve set a date of June ’07. Publicizing the date, on the other hand, seems to increase urgency – we have others’ expectations to meet, rather than just our own.
That said, I’m relying on my developer to accurately estimate the duration of his piece.