When is the project going to be done?
All clients ask at least two questions: how much will it cost and when will it be done? If you’re living the project life, the answer to how much should be a flat rate. For a slew of reasons, it’s better to keep your hours and hourly rate to yourself. It’s nobody’s business how much you make per hour. When you can, stick to value when quoting projects. Better yet, get a budget established upfront. The “how much” question is easy enough to answer when you keep it simple. What’s the budget? What’s the value?
The tougher question is when. Time is tricky to pin down. From a service provider’s perspective, the real answer is ASAP. Yuck. ASAP is a four letter word. It gets a bad wrap because you’re usually on the wrong side of it. ASAP is a drag when it comes from someone else. But it can be a lifesaver when it comes from your side.
Front-loading is my favorite method of dealing with ASAP and time. Front-loading is like blitzing. The idea is to go bananas at the beginning of a project. Rather than saving your long hours for a deadline push, you do them first.
A handy complement to front-loading is padding time. If you think something will take two weeks, you’re wrong, quote three. If you don’t run into problems, your initial push and padding lead to an early finish. There’s nothing like beating a deadline to make a client happy.
“The beginning is the most important part of the work.” — Plato
Estimating time is guessing
Why is time such a big problem in the first place? Easy answer: people suck at estimating time. The bigger the project, the bigger the error. If you’re quoting time on a project of any scale, you’ll be wrong. You can work backwards from deadlines and create milestones. But your milestones will be inaccurate. You can chunk down the tasks and error will still be a huge factor.
What actually happens is compression. Time management works like an accordion. Some milestones get stretched and some get compressed. Compression happens when you force yourself to hit your goals at certain times. The issue is that guessing time doesn’t account for unforeseen problems. Any project worth its salt has problems. They’re learning curves. Learning curves are a natural part of innovation. If you’re not innovating, you’re not doing it right.
Front-loading vs. Even Steven
If you have 100 tasks, 80 will be easy. It’s the easy stuff that skews your perspective. Easy, known tasks make projects seem less difficult than they are.
It’s human nature to run through the easy stuff first. But at some point, you have to deal with the tougher tasks. It’s the tough tasks that eat time. Problem-solving is a slow process. It’s deceptive because it represents a low number of line items and tasks. On top of that, you often run into them later in the process. Problems get addressed after the low hanging fruit are gone.
Most projects aren’t evenly paced. The easy stuff gets run through quickly. The problems get solved next, at a much slower pace. Taking an Even Steven approach to time management is risky. It’s the best way to create an unforeseen crunch at the end of your project. Not fun. If you have a real deadline, you can’t take a linear approach and expect to avoid a crunch at the end.
Front-loading prevents the potential risk of a crunch. Plus it feels better. When you start a project you have enthusiasm. You might also have some butterflies in your stomach. You can use this energy to blitz your project and front-load the work.
Want to escape the dread, panic and anxiety of a looming deadline? Avoid the crunch. Use ASAP in your favor. Go bananas and front-load your next project.
