When you're short on time, don't rush

I was running late for work this morning. I was convinced I was going to miss the bus. So I rushed. I rushed to put my lunch in my bag, inadvertently opening the lid in the process and spilling my lunch into my bag. Now I was running even later.

I continued to rush. I put my shoes on and ran out the door, realising I had forgotten to pick up my access card. I rushed back inside. I eventually made it to the bus stop, without my wallet. I turned around and headed back home. I was definitely running late for work this morning.

My travails reminded me of the old saying, “if you think safety is expensive, you should see how expensive an accident is”.

Rushing your project

We do the same thing on our projects. When time gets tight, when that self-imposed deadline gets closer and we're not ready, we rush.

Rushing on a project looks a little like rushing for the bus in a morning. As a result, mistakes will be made. Maybe the testing wasn't performed as diligently? Maybe we chose not to add logging to a key part of the system? Maybe we didn't set up the security as tightly as we should? But at least we made it on time.

The definition of rushing is to deal with something hurriedly. When time is short, it's the obvious tempting tactic. If we rush, things take less time and therefore we will make the deadline. But things can only take less time in one of a few scenarios:

• We do less work, but not by design. Fewer checks, for example, or missing things out.

• We work longer hours. Which is a recipe for mistakes.

• We increase the number of people. But we all know 9 women can't make a baby in a month.

Just look at those scenarios. None of them are good. All of them give us sub optimal outcomes that as Project Managers we shouldn't want. And rushing is expensive. Adding more people costs more. Working longer hours costs overtime. Missing things out comes to bite you later.

So, if rushing gives a worse result and costs more money, what's the alternative?

Instead of rushing, do different

There's only really two options left if we agree that rushing always leads to a sub optimal result - take longer, or plan to deliver less.

In rushing for my bus, I could have taken the decision to buy lunch - plan to do less - or get to work later - take longer. Both would have been a preferable outcome to where I ended up. The same is true for your project.

What tasks can you defer, by design, that will help you meet the deadline? Are there nice-to-haves that you can do later? Are there tasks not contributing to the outcome that you can defer?

Alternatively, have the conversation that rushing always leads to an inferior outcome and take the time needed to do the job properly. If you don't have time to do the job properly, when do you have time to do it again?