Sunday, December 11, 2011

PMRobot Google+ Hangout

Just a quick little note that this Wednesday, December 14th at 11:00am Eastern, we'll be hosting a Google+ Hangout to chat about the latest PMRobot release.

Put PMRobot in your Google+ circles and join us to learn and give your feedback.

In the meantime, check out our new front page video explaining how PMRobot is the best all-in-one solution for software consultants!

Monday, December 5, 2011

You are not 90% done

Have you ever had a programmer tell you that they're 90% done?

It happens all the time. Don't believe them.

I'm a programmer. I should know.

You see, there's a funny thing with software. It's very fluid, and can end up being very complicated.

For simple tasks, it's fairly easy to estimate the effort required, based on previous experience.

An example often used in project management literature is "digging a ditch".

If an average man can dig a 10 meter long ditch in 1 hour, then some excellently simple math can tell you that:
  • That same man can dig a 20 meter ditch in 2 hours
  • 30 men can dig a 300 meter ditch in 1 hour
  • 500 men can dig 50 100 meter ditches in 1 hour

Unfortunately there are a lot of people that still try to apply this same logic to software development.

It simply doesn't work. Here's why. Let me tell you a little story.

Mark the Manager gives Peter the Programmer a specification for a new, complex feature in an existing, complicated piece of software.

Mark asks for an estimate, to which Peter replies, "Well, there are a lot of unknowns, but based on the spec, I think 2-3 weeks. Worst case scenario? 4 weeks."

Mark would like it done faster, but agrees to the estimated timeline and gives the green light.

Peter starts working steadily, 40 hours a week, with no vacation, personal, or sick time.

Here are his progress reports:
  • Week 1: 35% complete -- Perfectly on schedule
  • Week 2: 65% complete -- A bit behind, but still on track
  • Week 3: 85% complete -- Uh oh, but at least we'll have it next week
  • Week 4: 90% complete -- Ok, now we're late
  • Week 5: 95% complete -- Customers are getting anxious
  • Week 6: 97% complete -- Customers are irate
  • Week 7: 99% complete -- Customers are leaving
  • Week 8: 100% complete -- We are bankrupt

Disaster! What went so terribly wrong?

Perhaps the following visualization will help:

This is such a common curve in software development, it should have a name. If it doesn't already, I propose calling it the "Programmer Optimism Curve" or POC.

So what do we do to prevent this from happening? There is clearly no silver bullet solution.

I've written about my 5-step software development estimation method. That can certainly help.

The "story point" methodology from Agile can also work well when you have a long project with the same team members.

Jeff Atwood has some good suggestions about listing todo items too.

Of course, "knowing is half the battle," so now that you're aware of the problem, you can start taking active steps to keep it from sinking your ship.

Monday, November 28, 2011

Eating your own dog food

There's an odd term in the software industry called "eating your own dog food."

Microsoft coined this term in the late 80s.

The main idea is that companies that make a product should use that product on a daily basis. That way, you can experience the pleasure (or pain) yourself, and have a better idea of where to focus resources.

At PMRobot, we use our own software every day.

It was conceived and born in our sister company, Syllogistic Software, and continues a core element of our processes.

"Dogfooding," as its often referred to, is absolutely essential when building a product, because it really helps motivate internal innovation, and quick fixes to problems.

A similar example, dating all the way back to 1981, is when Apple decreed in a memo:
“EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.” - An Apple On Every Desk
If an annoying change makes it to the server, we experience the pain first hand, instead of just hearing a second hand account from our customers.

If you develop a product, consider making daily use of that product a habit.

I guarantee it will help you produce something of much higher quality.

Sunday, November 6, 2011

You can't assign 1 task to 2 people

This is one of my biggest pet peeves with certain project management software packages out there.

You cannot assign one task to more than one person!

And yet there is tons of project management software out there that lets people adopt this bad practice. Have you ever tried asking a group a question? It just leads to individuals assuming that someone else will take care of it.

You: "Hey team, Is the release going to be ready for Friday?"

Developer: "Well, I've done everything I can, but the client hasn't sent their logo yet."

QA Person: "The file interface is still buggy, but I'm not sure if I'm supposed to log bugs about that yet."

What's wrong here? There's no clear responsibility and no one owns the task.

Responsibility is key to all projects, and every task needs one person to be ultimately responsible for moving it forward.

This does not mean that multiple people can't collaborate and contribute towards the solution, but multiple assignment is often very dangerous.

Instead of both people taking responsibility, each one assumes the other one has it covered, and nobody takes any action.

This is why in most companies, there is a single CFO who is ultimately responsible for the finances or a COO who takes ownership of sales and operations. They would not be able to succeed without support from their teams and colleagues, but at the end of the day, they are responsible.

From the very beginnings of PMRobot, when it was just a simple ticketing system, we designed it to ensure that a ticket could only be assigned to one person at any given time.

This leaves no chance for ambiguity or misunderstanding about who needs to get what done.

If you want to increase your efficiency and reduce the number of things falling through the cracks, make sure you only assign things to one person.

Sunday, October 30, 2011

Boomerang for Gmail Review

As a "follow-up" to Ramy's article about FollowUpThen, I wanted to share my favorite email follow-up service -- Boomerang for Gmail by Baydin.

I've been using it since early beta, and it has become a powerful tool in my email productivity arsenal.

It's basically a snooze button for your email, and integrates right into the familiar Gmail interface.

At $50/year for a personal account, and $150/year for a professional account, it's not cheap compared to Gmail itself.

However, it works very well, is extremely reliable, and could end up being worth the money for someone who sends and receives ridiculous amounts of email. (like yours truly :)

The feature is use most is the basic "Boomerang incoming" functionality. Just tell Boomerang when you want the email to come back (tomorrow 8am, next thursday, etc.) and it disappears and is redelivered at that time.

For power users, here's an example of a more complicated workflow:
  1. You receive an email from Bob asking whether you can meet up next Friday, but you have a tentative meeting scheduled with Mary.
  2. You send an email to Mary asking if the meeting is still on, but click the "Boomerang this message if I don't hear back in 2 days" checkbox.
  3. If Mary responds promptly, nothing happens.
  4. However, if Mary does not reply, Boomerang puts the message back in your Inbox so you can re-ask her, or perhaps give a call or text.

Another feature I use often is the Send Later feature, which is similar to Outlook's Delay Delivery.

I sometimes find myself working at odd hours -- 2am, 3am -- and need to send various emails, like invoices, updates, etc.

Sometimes it might be consider a bit rude to send emails in the middle of the night. What if the recipient forgot to turn off their Blackberry and it buzzes and wakes them up?

I simply draft up the email, press Save, and then use Boomerang's Send Later button. A dropdown lets me specify when (usually "tomorrow morning").

In summary, Boomerang for Gmail is a nicely implemented service that does a great job of filling a void in Gmail's functionality.

Kudos to the folks at Baydin!

Thursday, October 20, 2011

Forget Flagging Emails - Follow Up Then

I've recently been introduced to a great tool that's helped me in managing projects and fits perfectly into my personal workflow of how I deal with emails and keep on top of things where I need to make sure some action gets taken.

In the past, I flagged emails. First in Outlook and then a few years later using "Stars" in Gmail. It works pretty well. After I sent an email, if I wanted to make sure that the person that I sent the email to actually did something with it, I would go into my sent items folder and Star the email. Once a week or so, I would cycle through my Starred items and see if there were any messages I needed to follow up on…

Enter Before I go on. I don't know the people who developed this product and I have no affiliation with them other than being a big fan of their service!

Basically, you can send an email to,, or any other description of time you can think of. After that set amount of time, you'll get a reply/forward from Followupthen (with the same subject line so that message threading works correctly) which basically brings that conversation right back into your inbox.

There's a few reasons I like this. But before that, I'll illustrate the two different ways that I use this service.

If I'm sending an email and I want to basically remind myself to follow up a week later (if I don't hear back from the recipient) it's as easy as BCCing No extra action is required. I don't need to look up the email after sending it and mark it. The recipient has no idea about it and I can feel confident that if I don't hear back in a week, that email conversation will magically pop back into my inbox for me to follow up on.

The other way I've used the service is when I receive an email that I don't necessarily want to write back to immediately. Whether it's a good practice or not, I'm a big fan of a clean inbox. So when I get those emails, if I want to remind myself to reply 2 days later, I simply forward it to and then archive it. Again, it fits right into my workflow, which is what makes the service so useful.

The one downside or questionable part of this is that I am sending some of my emails to this service. I'm careful that nothing with even the mildest amount of confidentiality goes out this way. That being said, considering that Google and Apple basically own most of my information anyway, it's probably not too big of a deal.

Finally, aside from actually using the service, it's also been a good learning for me in terms of creating meaningful business solutions. The service is simple. It does one thing. And it does that thing well. The most important part for me is that it fits into my workflow and as a result, it was really quick to adapt to.

We are taking this lesson into account as we continue to improve PMRobot and looking closely at the workflow of project managers and software developers to ensure that PMRobot slips right into the way most people are working already! Have feedback about how we can improve PMRobot from a workflow point of view? Drop me a line at

Tuesday, October 11, 2011

Hard deadlines motivate people

The vast majority of people seem utterly incapable of doing anything until the very last minute.

Procrastination appears to be human nature, and tends to defy the best project management practices.

Whether learned or inherited, it's a very real phenomenon that project managers need to deal with on a daily basis.

Some managers try to jumpstart things by setting a "fake" deadline, a week or two before the "real" deadline, so that people actually start working on things and discovering unknown dependencies and challenges before it's too late.

This tends to work -- about once.

Then everyone clues into the trickery and ignores the next "fake" deadline completely.

Nonetheless, I've found that if you want something done, you need to set a deadline, and make people very aware of it.

In PMRobot, we've added a bunch of cues to remind people about deadlines.

The "Due in X days" text turns red at the 3-day mark. Ticket subjects turn bold and red at the same time. Reminder emails are sent out.

In project management, there's no easy way to fight the tide of procrastination, but I've found that it works best to:
  1. Set a realistic due date. Make sure people know what it is.
  2. Enforce the due date. Ensure that people know the consequences of missing it.
  3. Communicate about the due date. Ask people regularly about their progress.
  4. Don't push back the due date. Deliver on time, create a new milestone, and reschedule the missed work items.
How about you? What tools do you use for motivating people to keep on track?

Wednesday, September 28, 2011

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 :)

Monday, September 19, 2011

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

Monday, September 12, 2011

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.

Tuesday, September 6, 2011

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.

Monday, August 29, 2011

Communication: Keep your team small

A common mistake when projects are running late is to add more people.

This is often a disastrous mistake.

Often called "Brook's Law", Fred Brooks stated in The Mythical Man Month that "adding manpower to a late software project makes it later."

I've written about this twice before when explaining how building software is not like building a house.

A key reason for this actually comes from the PMBOK, and has to do with communication.

One of the formulas you must learn when studying for the PMP certification is the following:
For N people, the number of communication channels is (N^2 - N) / 2
This means that the number of communication channels increases exponentially with a linear increase of team members.

I'll explain with a simple visual example. Consider a team of 4 people:

#Channels = (4^2 - 4) / 2 = 6

Now let's add two new members:

#Channels = (6^2 - 6) / 2 = 15

Adding just 2 people has added a whopping 9 new communication channels!

Technology and design consulting projects often require a lot of detailed communication, so you can see how large teams can get out of control quickly.

So keep your team as small as possible, and if you're running late, think twice about adding more people.

Want more? Be sure to subscribe to our RSS feed.

Monday, August 22, 2011

5 tips to get paid quick

"Money money money money. Monnnney!" - O'Jays, For the love of money

Getting paid for consulting work can sometimes be a challenge.

And it often seems like the largest clients are the slowest to pay.

Here are some tips to help you get paid quicker:

5: State your terms

If you don't put them on the invoice, they'll assume. And that might mean 60 days, 90 days, or longer!

4: Set a date

Even if you have your terms, put the specific due date for that particular invoice somewhere large and visible.

3: Have a penalty

Make sure you have a stated penalty for late payments (usually 1-2%/month). And if they're consistently late -- charge it!

2: Remind them

Sometimes invoices get misplaced or misfiled. Make sure you track when they're due and remind your clients about upcoming invoices and the penalties they'll face if not paid on time.

...and the number one tip:

1: Put it in the contract

Make sure your terms, penalties, and all your invoicing policies are listed in the contract your client signs at the beginning of a job.

Monday, August 15, 2011

5 Project Accountability Tips

Where does the buck stop?

When you're managing a project, it stops with you.

Save yourself a lot of trouble by making accountability clear.

Here are five quick ways:

5. Be specific

Your team members can't read your mind! Think about tasks from their perspective and add as many details as possible.

4. Assign tasks to one person

If you assign a task to multiple people, everyone thinks someone else will handle it, and nobody does.

3. Ask questions to one person

Don't CC the entire team. Ask one member a specific question.

2. Ask one question at a time

People are busy. Make things easy for them. Send separate emails, or number your questions so it's easy for them to respond to each one.

...and the number one tip:

1. Keep track

As a project manager, you need to track all of your "open loops." When a team member agrees to do something, make sure it's tracked somewhere you can both access, so it's clear what they've committed to.

Anything I've missed? Let me know in the comments or by email:

Monday, August 8, 2011

You have to spend time to make time

"We're too busy to try something new."

Trust me, I completely understand.

Syllogistic Software used to have project information scattered across 5 different systems.

I would spend 8 hours a day emailing, and copying stuff back and forth.

There had to be a better way!

We invested hundreds of hours testing and tweaking a system to track and automate the repetitive stuff.

Soon, it took only 2 hours a day to manage the same number of projects!

Now you can benefit from this same system.

Think carefully about how much time you'll spend today doing manual project management tasks that could be automated.

Each month you delay, you could be wasting 100+ hours of billable time!

So spend some time today, and make time for tomorrow...

Ready to invest the time, but not sure how to get started? Post your questions here, visit, or email me directly at