29
May
07

Some thoughts on multi-project workloads

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

A question that pops up time and time again in forums, newsletters, and blogs, goes something like the following:

“People say the best advice is to work on one thing at a time. But when pressed, everyone who is successful says they work on multiple projects at once. What gives?”

Well, there are two useful ways of looking at this. At least, two ways that I’ve found useful. You might agree or disagree.

The first way: Focus on one task at a time.

If they are writing an article, they sit down and write that article until they are finished. They don’t write three lines, then read their email, then write another paragraph, then have a look at that latest Wordpress plugin, and so on.

But when they’ve finished that task, their next task might be on a completely unrelated project.

The second way: Work on one project at a time.

This is where I’m starting to move towards. I’ve got or had a number of projects on the go at any one time recently:

  1. Release Stay On Focus 1.0
  2. Release the fix for the missing Stay On Focus icon issue
  3. Release “toast” 1.0 (application name still to be defined)
  4. Release RSS Promoter 2.0
  5. Launch MostPopularPlugins.com
  6. Release The File Tagger 1.0
  7. Get The File Tagger 2.0 to beta testers
  8. Progress my test “monthly strategies” project (more on this in the future)
  9. Release IdeaBoost 1.0

And to an extent, I’ve done this via the “one task at a time” approach, with the result that some of these are incomplete or took longer than I wanted.

But I used the “one project at a time” method for MostPopularPlugins.com - the work for that was done in one day, including writing a custom plugin.

And I started to use the “one project at a time” method for the IdeaBoost software, when I’ve realised that some of those projects are incomplete, and need finishing.

So, I’ve come up with a hybrid system. Or, more accurately, a refinement of the second method:

The third way: Work on one project at a time and don’t deviate from that project until you can’t do anything yourself.

This is the way I’ll be working now. Working on one project until I can’t do anything else. So for the “toast” software, I’ve totally outsourced development, and now all I can do is sit back and wait for the developer to do his stuff, whilst I switch to another project: the Stay On Focus bugfix.

I’ll write the bugfix myself, so I can work on that until it’s complete and released to the user base.

Then, when I’ve released that bugfix, I’ll have nothing to do until some users have upgraded and tested it. So I’ll go to work on Stay On Focus The File Tagger 2.0, for which I’ve got a potentially huge joint venture deal brewing in the background.

Once I’ve released that to the JV partner for review, and whilst I wait for his feedback, I’ll work on the RSS Promoter technical manual I need to write.

When I’ve done that (which again is done only by me), I’ll move back onto Most Popular Plugins and release the details of it’s plugin to the various plugin directories.

Then, whilst those submissions are under review, I’ll start watching the training videos which I need to for my “monthly strategies” project.

And when I’ve watched them, I’ll come back to “toast” and continue the launch.

And so on.

Do multiple tasks on one project until:

A) You have completed the project and have no more tasks to do
B) You are waiting for someone else to do the next task
C) You are waiting for feedback from someone before you continue

The “gotchas” with this method are:

A) Have a definite end-point. I know what the terms “release” and “launch” mean. They relate to a checklist I’ve written for releasing software and launching sites. Once I’ve done that checklist, the product is officially released or the website is officially launched. Of course, they might not be successful, but then I add follow-on projects to promote the product/website, in very specific ways, and each of those projects have definite end-points.

B) Make sure that whilst you are waiting for someone else, there is TRULY nothing you can do. For example, whilst I’m waiting for the developer to write my “toast” application, I COULD work on the sales page, sales process, etc, but to be honest, that product is low on my priorities so I’ll work on the other products that will actually make a difference to the bottom line.

But the trick here is to CONSCIOUSLY make that decision. My thoughts are: I’ll delay work on “toast” until I’ve watched those training videos. Not: I’ll delay work on “toast” till later. Nor: “I’ll write the sales page for toast… oh, what’s the URL for those videos? ah, there it is…. Ooooh, that one sounds interesting, I’ll just watch that one for now….”

Focus. Focus. Focus.


Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • del.icio.us
  • Netvouz
  • DZone
  • ThisNext
  • MisterWong
  • Wists

2 Responses to “Some thoughts on multi-project workloads”

  1. Andrew Says:

    Update (about 1 hour later). I’ve just released the Stay On Focus fix to the people who reported the issue. Nothing else for me to do till they come back to me (I’ll give them till end of business Thursday, then if I’ve not heard, I’ll release it to the wider user base).

    Time to work on The File Tagger 2.0, which includes tasks: release beta testing instructions to the beta testers (they’ve already got the software itself); create a new sales page for this version

    Andy

  2. Andrew Says:

    Update: Just under 24 hours real time later, but about 7 hours of working time elapsed.

    I’ve released the beta version of The File Tagger 2.0 to the testers, after finding and fixing a number of issues whilst I was writing the testing script.

    Whilst I’m waiting for them, I’ll start writing the RSS Promoter 2.0 technical supplement.

    Onwards!

Leave a Reply