Not too long ago, I was asked by a client of mine how long it would take to complete a certain large project. After thinking about it for a while, I gave what I thought was a fair estimate given all of the parameters, possible hurdles and building in time for contingencies. The client then asked me if I could do it faster than that. They asked if I could do it in about a third of what I had estimated.
h3. Making The Best Use of Time
I am sure that we have all faced this riddle at some point in our careers or even in our “regular” lives. In this age of corporate downsizing, outsourcing and trying to get the same amount done with less resources, some of us face it daily. I would even argue that the current near Atkins Diet sized obsession with productivity many are having is directly tied to this quest for time management alchemy. Not just how to optimize the time we have but how to actually make time itself somehow change and bend to our will.
After some thought, I offered the client following response…
Time not spent on the front end of a project is usually spent on the back end. Sometimes, it is even multiplied. Therefore, it will take the same amount of time, if not more, no matter what.
You see, the time that project would have taken did not somehow magically change because the actual time that I was given to complete it had. Could I have done that job in the timeframe the client wanted? Sure. Would I have had to spend just as much time as I originally quoted after the fact correcting mistakes and problems because I rushed through it? Probably. Would it be harder, and thus take more time, to make such corrections after the fact than to get them done right the first time? Definitely. Yet I can’t even tell you for how long, by how many clients and managers and in how many different ways I have been asked to do this very thing. I know I am not alone. As a matter of fact, a common joke in the computer industry is “You can have it cheap, you can have it fast or you can have it done well. Pick two.”
What you trade in time you most often exchange for quality or quantity. Sometimes you have to change the project or task that you set out to do. Sometimes you just don’t have the time you need for the project at hand. Maybe you cut a corner here and there. Maybe you drop less important aspects. In this case, the time itself does not change. The quality or quantity of the project changes accordingly with the time saved. It is now a different project, with possibly less than satisfactory results.
I try to use this approach with even the simplest items on my daily task list. For instance, I try to take an honest look at what I want to accomplish in the 15 minutes of time I may have to make a phone call. I am not going to make a call that I know has an hour worth of discussion in that time frame. If I do, I know that I will be trading a true discussion of the topics for bullet points at best. I may have to make another call to the same person later that will make up for, or even equal the time I chose not to spend in the first place. Is that the most effective use of the time? I think not.
Therefore, when you have a block of time to fill be careful to choose the right sized task to fill it. Like most things in this world, when it comes to time, nothing is free.
Author Bio: Patrick Rhone is a computer consultant and writer who is obsessed with productivity, organization, gadgets and expensive office supplies. More of his work can be found at http://patrickrhone.com.
Excellent article! I have faced that problem exactly a week ago. I had to estimate a project that resulted in a time of 5 months. Obviously the client wanted to kill me!!! He find it hard to belive that… some years ago, for a project like this, I would have estimated 2 months, I would have delayed it a lot and delivered a work full of bugs. It’s difficult to trust project management experience for clients.
Well, there are ways to speed up long, complex projects, but they’re rarely acceptable to management or the customer.
Here’s a story, probably an urban legend. A Disney “imagineer” was asked how long it would take to create a new attraction and he quickly replied, “two years.” When asked if he could do it quicker he said, “Yes, I could do it in 16 weeks.” When asked about the difference he told them, “eliminate all of the reviews, committees, management changes, and other projects on our plate and give me the full budget up front and I can get it done in that time.”
They, of course, wouldn’t do that. I often include a “customer delay” into project estimates, but you know, I never estimate enough time for that.
You could always deliver a third of the product with the understanding that the rest will get done in the timeframe you’ve estimated.
What I mean is, depending on the project, you could launch a stripped down, yet functional version to begin with and then build on it. I think the concept of v.1, v.2 is getting lost these days. Why does a project have to be completed in it’s entirety right away? Aren’t there some functional pieces that can be launched in advance to keep people happy?
This reminds me of the oft-quoted phrase in software development (and something Irepeatedly tell my clients: “Cheap, Fast, or Good. You may choose two.” The amazing thing is how often they choose cheap and fast.
Equally common is when a client thinks of something else they’d like done, and then can’t grasp that they either have to increase the budget, or drop a different part of the scope of work to accommodate the new task. The main thing I find is that the “give ’em an inch, they’ll take a mile” philosophy is really true, and it takes discipline to stick to what you know is the right quote, the right promise.
I actually just finished reading a good article on this topic – ‘Painless Software Schedules’ by Joel on Software: http://www.joelonsoftware.com/articles/fog0000000245.html
It’s useful stuff because it allows you to plot a project out from the very start, with every little piece estimated in hours, so if your manager (or client) says “do it faster” you can point to the schedule and say “not possible, but here’s a heap of fluff features we can scratch or postpone if you want to pull the release date forward”.