Is email draining your productivity?

Mark Suster recently posted an article about "Why Email May Be Draining Your Company's Productivity."

Although I agree with some points, like batching email:

He suggest you never check first thing in the morning. He also suggests you only check periodically and leave your email off at other times so as not to be disturbed.

...I don't agree with this:

“I would far rather give out my mobile phone number than my email address.”

The good thing with email is that you can shut it off. I like to reserve my cell phone for urgent, time-sensitive communication.

Email, meanwhile, can be batched and processed when convenient.

And not all of it needs to be responded to. You don't really need to reply with "Thanks Bob" when Bob sends you the attachment you asked for.

So is email draining your productivity?

Probably, but there are some straightforward ways to be more effective. I wrote about "How to get people to respond to your email" a while back and suggested:

• Make emails as short and concise as possible.
• Write a concise, relevant subject line!
• Separate your short sentences into paragraphs with a space between them.
• If you are making multiple points, or asking multiple questions, put them in a numbered list.
• Edit your emails multiple times, and cut out unnecessary words and sentences.

Then on the other side, batch process your emails, as Mark (and Tim Ferris) suggest.

Hopefully those tips will help you tame the lion that is email :)

5 steps to estimate software development time

Here's an oldie but a goodie from my personal blog summarized for you here:

Estimating software development time is really, really hard. Here's my method:

1. Come up with your best, realistic estimate using your favorite technique.
2. Ok, you have your absolutely realistic number now, right?
3. It's not realistic. There are aspects you haven't thought of. Double the number. This is your best case scenario estimate, if there are no snags or major changes along the way.
4. Now double it again. This is your most likely estimate. This is how long the project will probably take.
5. Now double it a final time. This is your worst case scenario. This is how long is might take if you run into several major issues.

So to sum up:

• E = Your original time estimate
• 2(E) = Best case scenario time in reality
• 4(E) = Most likely time in reality
• 8(E) = Worst case scenario time in reality

- Jason Hanley

Multitasking is toxic

Everybody multitasks. But should we?

People consistently overestimate their multitasking ability.

There is huge power and efficiency to be gained by batching similar tasks, or "single-tasking" as I like to call it.

Email, social networking, and especially chat programs are notorious for breaking focus and concentration.

I discovered what a difference this makes when I was running my company from New Zealand and all my clients and employees were in North America.

There was a more than a 12-hour time difference, so I was essentially forced to track and batch all my tasks using an early version of PMRobot.

When I got up in the morning, the day had already ended in North America, and I was able to get work done with zero interruptions.

This resulted in a huge productivity boost!

As I'm writing this blog post, I have a number of tabs open for related material, but I've closed Gmail, Twitter, Facebook, and anything that could interrupt my flow.

I do the same thing when I'm programming. Before I open Eclipse to write code, I close everything else that's not related.

What time is it where you are right now? What major goals have you accomplished today? How many interruptions have you had?

Trust me, give single-tasking a try! I guarantee you'll be more productive.

Keep it simple: Ticket workflow

A lot of tracking systems have very complex ticket workflows.

These are often designed to prevent mistakes, but I've found that they often add too many steps to the process, which people eventually ignore.

With PMRobot, we decided to go a different direction, and limit ticket states to:

1. Open - There is work remaining
2. Resolved - The person who did the work believes it is completed
3. Closed - The person who submitted the ticket confirms it is completed
4. Blocked - Work cannot continue due to an external factor (used sparingly)

There are a few common states we decided to leave out since we didn't feel they added sufficient value. Here's why:

New: This is an an open, unassigned ticket. Why add an extra step?

Accepted: This isn't much different than an open, assigned ticket. Again, we don't see a lot of value in adding this extra step.

In progress: This is a useful state to have, but often isn't used correctly. People often mark ticket in progress and then forget about them. Instead, we tend to use time logs and auto-scrum to track what is currently being worked on.

Reopened: This doesn't seem to add much value over the 'open' state. We track and display the number of times a ticket has been reopened, but don't feel it requires a separate state.

What about your process? Do you use states I haven't listed here? Tell us about your experience with ticket workflow.