In twelve years of software development, I’ve never seen a project go exactly as planned.

Functionality changes. Unanticipated obstacles arise. Sometimes things that we think might take a week actually take three. Yet, all too often, we put too much detail into a project timeline. Putting a delivery deadline on every little component means we become slaves to our own timeline. We’ve decided how long every single step will take without having taken any of the steps yet. It’s impossible to come up with the perfect plan at the very beginning.

So, when you begin your plan, plan with less detail.

Build timeline deliverables in sizeable chunks, not in small breadcrumbs. If you’re estimating an eight-week project, give yourself eight weekly deliverables rather than forty daily ones. Instead of defining when each individual interaction of your application can be delivered, decide when a complete section can be delivered. In the end, it’s the same amount of time but with fewer checkpoints in between.

When our timelines get too detailed and our delivery dates become too frequent, there’s no wiggle room to experiment or reconsider the details of an application as we go. We’re forced to stick to a rigid schedule of guessed tasks, as if an ignorant micro-manager were hovering over us constantly. Then when the timing of a few of those small tasks goes awry, suddenly the entire timeline feels like it’s crumbling right in front of us. That’s not motivating, nor is it how good software gets built.

A lot of front-end developers approach screen design in drastically different ways. Some like to mock up a screen perfectly in Photoshop and then translate the visual into HTML and CSS. Others like to start directly in code. Some like to focus strictly on the markup structure first before putting in a single color or font size. Others need to see the design unfold as they build the structure. Some start by building for the lowest common denominator and work their way up. Others start with the optimal screen resolution and work on gracefully degrading their layouts later.

Setting a deadline for delivering completed screens is a good milestone. But making deadlines for all the in-between components specifically (just the HTML or just the CSS) isn’t. It doesn’t give a developer the liberty to work the way she works most efficiently.

Giving ourselves a reasonable amount of time between deliverables enables us to play. It breaks down a large project into bite-size mini-projects where we still get the chance to approach the build the way we want. It gives us the chance to iterate a few times before our next deadline. A week (or two) before our next deliverable gives us the opportunity to make a few mistakes and still recover.