Using the fishbowl to your advantage.


This has been sitting around in the dusty Drafts section for ages now. I haven’t posted in a while so I thought I’d give it the nod and send it to the Majors. You’ve been warned.

Fishbowling is a concept well-known to people that take on projects under a certain time-frame. Urban dictionary failed me with a proper definition, but basically the idea behind fishbowling is that if you are given a certain amount of time to complete a set of tasks that you’ll take the entire time to do it. Lots of things feed into this. Procrastination, perfectionism, feature-creep and so on and so forth. In terms of game development, fishbowling can be very bad. But it doesn’t have to be.

Admitting this tendency is the first step to overcoming it. Once you admit that you’re powerless to the “just one last little thing” disease, only then can you begin to harness its true power. It’s actually pretty easy if you’ve got the willpower. I’ll forgo the Frodo reference here [even though its perfect] and yield to my better judgment.

Armed with this knowledge, it’s time to setup your plan. And this coicides with the “sprint” ideology behind Agile or Scrum, but those often get lost in the shuffle because they are far too sterile. Getting shit done is messy, it’s a ton of work and an elaborate plan is ultimately a waste of time you could have spent doing shit. DISCLAIMER: I work in a small team, like sometimes it’s just me [smallTeams > bigTeams]. But even if you do wield a big team that needs constant management and clear meetable goals, a huge plan and project management software doesn’t get to the real issue about what’s hard about either finishing a project or letting it finish you. It’s finding the will to do what needs doing that’s tough.

The problem with project management software [for me] is that it’s too specific. Each sprint has a reasonable amount of items contained within it. If it gets overloaded it’s specifically designed to stop you from making a mistake and overloading. On the surface, that would seem to work really well for projects. All you need to do is know every last little thing that you’ll need to do. Oh. Whoops. I guess I don’t, I mean I have an idea, in fact a pretty clear idea for the most part. But those clear ideas cannot be broken down into smaller tasks, sub-tasks, dependencies and so on [let alone how many hours each one will take].

So… say I’m redesigning a website, the intuition website to be exact, and I’m estimating how long it will take. It should probably take a couple weeks of work, max.

  1. Make up a quality mockup.
  2. Refine the mockup into finished graphics.
  3. Restructure the CSS and implement the new tags and graphics.
  4. Setup any extraneous plugins and other features we want.
  5. Then take another pass and polish up any rough edges.

Seems pretty straightforward. Of course, within all of those items there are a plethora of tasks that may take quite awhile on their own. Polish being the main offender. If I were to plan this out over 2 weeks, the early stages may take way longer than they really need to. I could make up 20 mockups because I’d have the time to do so. Or maybe I’d get satisfied with the mockup early on and call it a day because I got that checked off. Regardless, what really only needs to take a day or two might end up taking 5 days because I’ll give myself that amount of time in the plan. A low percentage of that is quality time spent working.

Instead, I’ll pick out each of these guys. I’m going to start and finish the mockup by the end of the day, that way I’ll have the website finished in three days total. Now, that’s wholly unrealistic, but it turns the big fishbowl problem into an advantage. Instead of the project growing into the time allotted, you’re fitting the project into a fishbowl it can’t fit into. Some things get cut, but the beauty of this method is that it’s all temporary. It’s all a huge lie to yourself.

Because in reality, I really do have two weeks to make this site. If the fish can’t fit into the far-too-small bowl I take it out and make the bowl a bit bigger. No big deal. Now it took 5 days instead of 3 and I’m still ahead of the curve. The key to this is to be completely and ridiculously unrealistic about your estimates. You’ve got to believe it too. Suspend the two opposing ideas in your head, knowing that it’s never going to happen in this lifetime, but that it’s also most certainly is going to happen. Or you could just go all the way down the rabbit-hole and delude yourself into truly believing you can pass through solid matter. That’s a bit weird though and people might stare. ;)

Once the mockup is done, I jump right into the next thing, make a lofty claim that I will part the Red Sea and move forward with a blind energy that can only be explained by “temporary insanity.” That’s the entire basis for this “strategy” of getting stuff done. Sure it’s not the healthiest, nor is it calculated in the least, but it works really well for me. Give it a shot. If it doesn’t work, you’ll at least have seen the other side of the fishbowl equation and maybe you’ll think twice next time it comes up.

05/27

COMMENTS

05/28

We deal with this constantly at work, we quote so many projects, from .5 hour jobs to 300 hours jobs. We track everything through a project management system we’ve developed, fondly named “sputnik.” Both quotes and time, as well as notes along the way, just tones of historical data.

What we’ve found is this. When we quote a job, let’s say for the sake of argument a 10 hour job. We immediately need to add 20%-50% to our quote. We call this time “coordination time” So our quote for the job would be 12-15 hours. With 2-5 hours of coordination time. Coordination time is a really poor name for this time, it should really be called, “we can’t accurately guess how long this job is actually going to take us, so to be safe we have to add time” time. But when we look at the job, we don’t look at Coordination time. We actually look at the original 10 hour quote as our allotted time. We effectively Fishbowl ourselves.

You would not believe how accurate this method is. 90% of our jobs fall within this 12-15 hour time, or under it. The few jobs that go over are due to fact that something went terribly wrong.

We have also found that it is not humanely possible for us as designer to work more than 6 billable hours (actual production hours) in a 8 hour day. Too much BS comes up throughout the day to deal with, you need to take mind breaks, things like that. So being 100% efficient in our office is working 6 billable hours a day. Our best designers are 90% efficient.

Taking all of this into account, if you quote using our method, and quote correctly, and then schedule your day wisely, that is, know that you cannot work 8 productive hours in an 8 hour day. You can actually schedule yourself pretty accurately.

Now don’t get me wrong, Fishbowling still happens. Most of us tend to use the time allotted to us, all of it, even though if we didn’t need to use it, and if we didn’t use it, we would be more profitable. And again… we all know there is “coordination” time built into each job, so we are continually lying to ourselves. But the systems works really well, and helps us avoid scope creep and “just one more thing” disease.

project management is fun like that.

05/28

I think the time management geeks more often call this “Parkinson’s Law.”

05/29

ah cool, thanks for sharing that. I think you’re right on the money with that.

That whole 20-50% thing sounds like a good rule of thumb, we tend to call that “polish” hours when we’re dealing with a contract, but really yea, it can be filed under “unforeseen issues” and whatnot. We’ve certainly been burnt before by underestimating a quote and not allotting for enough “Coordination time” before. I like that, “coordination time,” it’s kind of like “synergy” or some other savvy business euphemism.

BTW, when I wrote this, I was coming from a place of working on our own site so there was no _real_ budget/deadline so this is what I kind of came up with as far as a “system” to deal with that. It was more of a ramble, and probably why I didn’t publish it as soon as I was done writing it. :)

05/29

It was a well thought our ramble. I found it interesting that you are oranically discovering many of the things we have figured out over the past couple of years through pretty intense study of our project history.

We always quote every project, even our own pieces, internal work, etc. The reason being is almost exactly what you’re talking about. Creating parameters, and essentially “fishbowling” yourself actually stimulates the creative process. If the project is open ended, not only will you work on it forever, but the direction will tend to be off, or the scope will creep out of control.

Anyways. All that aside, I appreciated and enjoyed your ramble.

05/29

Coefficient of Inefficiency

NOT REQUIRED