How I handle timeframes and scheduling ⏳

Scheduling work involves juggling the expectations of many people at once. There’s each individual client’s competing desire to be at the top of the list as well as my very real desire to not be an overworked trainwreck.

To figure out where a project can fit in to my diary, big or small, I start by figuring out how much time is needed for each task I’ve outlined in the proposal. Accurately estimating time was very difficult early on in my career. At that point, I didn’t have enough experience to know how much time it would take me to build certain features or how much project management would be required for a particular site.

Estimating time became easier eventually but it’s not an exact science, it’s the result of a soup of factors including: the size of the site, the quantity of features and functionality, the desired transitions and state changes, the number of stakeholders involved, the behaviour of the stakeholders (if a stakeholder is difficult during the proposal process, it’s an indication that more project management might be needed), the tech awareness of the stakeholders (this can indicate that more handover time than normal will be needed so that I can properly educate them about their website), and so on.

Besides the time required to execute the task, there’s the time that might be needed to learn about the task.

Often, there’s very little learning time involved. A lot of the client work that I do is stuff that I know like the back of my hand. But I don’t just want to repeat the same work over and over, that’s boring and it would mean I’m probably not keeping up-to-date with the tools of my trade. Because of that, I always try to make sure there’s at least one new-to-me (or new-ish) element in each project that I do. I won’t usually include this learning time in the billable hours I estimate to the client, but it’s critical that I account for it in my scheduling nonetheless.

An exception: I will include learning time in my billable hours if the learning involves software that is only relevant for work with that client, for example a proprietary e-newsletter system. I’ll also bill for it if it’s some ancient piece of software that a client needs me to learn exclusively so that they can keep some old system alive. That second instance is often a red flag though… If a client is determined not to update an old code base, there had better be a very convincing reason why.

Accurate time tracking is the most useful way to learn how much time things take, without question. BUT. I loathe time tracking with all of my being. I mention this mostly to be clear that it’s not easy and it’s something I’m still trying to improve. I’d recommend trying out as many methods or tools as you can to find the best fit for you. I’m trying the app Timing at the moment, we’ll see how that goes.

At any rate, once I’ve ironed out exactly how many hours are scoped for each task in a project, that needs to be turned in to a schedule. I don’t give fixed dates in my proposal schedules (more on this), but I do need to give accurate timeframes for different phases of work. For example, I’ll usually break it down in to an exploration / prototyping phase, the full build phase, the testing / amendments phase (this is when the client adds content as well, if there’s a CMS), and the post-launch phase (this is a fixed period of time where the client is allowed to follow up with any bugs they encounter or final tweaks that are within the scope of the site).

The critical thing to remember: as an independent web developer, always assume you will have four hours or less of billable working time in a day.

This is a relatively common refrain when trying to work out your rates, but it took me embarrassingly long to apply it to my scheduling practices as well. I tend to have very long days and very tough weeks when I don’t stick to this.

Besides the head-down-work part of the day where I’m actually writing code or working on other dev tasks, there are a ton of other little things to keep on top of. Sending invoices, putting together proposals for new work, renewing software licenses, researching technology, corresponding with collaborators (a.k.a. scrolling through Twitter), logging expenses, writing, etc. This is all important work and when I fall behind on any of it, I immediately get stressed and twitchy. Particularly writing, it helps me process my thoughts and frees up space in my brain. I don’t have to remember everything if it’s written down!

So if I think it’s going to take 32 hours to pull the first full build of a site together and I assume I’ll have four working hours per day at most, I need to assume it will take me 8 working days minimum to get that work done.

Realistically it will take longer since I usually have more than one project on the go at once (good for my mental health, keeps things interesting, and good for my cash flow). And it is *always* better to give it more wiggle room, 30% greater than the minimum expected timeframe at the very least. This lets me account for unusual circumstances like a brief illness or a scope adjustment, and it should allow me to avoid deploying any changes before a weekend or holiday.

With all that in mind, if I had very few other active projects on, I would probably propose a 3–4 week timeframe for a 32 hour task. This would give me ample time to complete the task, and if there was a deployment involved it would allow me to deploy earlier in the week as opposed to a Friday.

Obviously, circumstances change. Sometimes a project really does have to be delivered sooner, in which case a rush fee is in order. And delays happen. My work could get thrown out due to serious illness (a very real consideration in these times…), the client might need months more time on their content, etc.

It’s important to know where you stand in that event, making a solid agreement document all the more important. I’m currently working on my agreement and hope to share more about that process soon.

There’s also another aspect to all this; actually keeping up with project schedules over time. This falls more under project management, another topic I’ve got *opinions* about. More soon.

This is one of a few posts on processes, the day-to-day practicalities that let me finish the boring stuff quickly so that I can spend more time on the fun part of work. Proposals, pricing, contracts, etc. See the Processes category for more.