Redesigning my workflow timeline (stage #2)

Missed the first post on my workflow timeline? You can find it here.

Stage #2: Development and build

You might have noticed last time that I didn’t include anything about setting a launch date or exchanging contracts in that new design of the first stage. Well we’re going to cover that stuff now. Before we start though, it’s worth noting that because I’m going to be charging for the design concept, I am going to need some kind of contract in place to cover everyone (the client and I) for that work and transaction, regardless of the fact that it involves a relatively small sum. To do this I’m going to cannibalise the contract I already have, cutting out everything not relevant to the design concept stage. Perhaps that is a topic for another time.

Back to today: we’re going to assume that everything has gone to plan so far and that the client is happy for me to crack on and get their new website under construction. Before that can happen we must get the contract in place. This is the full contract that covers that whole project from this point onwards, and there are two things covered in the contract I’m going to write about here. First: the launch date, because it features in the workflow. Second: the estimated cost, because whereas previously we’d be asking for half that estimate now, the rebalancing of this process calls for us to make a change here. Let’s jump right in.

People can find setting launch dates for their projects difficult for a number of reasons. In some cases there’s a perception of pressure that a fixed timescale can bring, in others it could be genuine uncertainty in how long these things take. Herein lies one of the great benefits of getting professional help with a project: not only do we have a pretty good idea of how long these things take, but nearly all of that timescale pressure is placed squarely on our shoulders. Hiring a web developer isn’t just about gaining access to technical knowledge and skill, it’s giving your project a manager, a lead, so that you achieve your biggest goal: the website gets finished, and in a timely manner.

This is why I set launch dates at this stage. It brings a clarity and focus to the whole project. It allows us both to schedule our time effectively towards that deadline, and it prevents us falling into a number situations where trust and good feeling breaks down.

Second thing: the estimate. This is the estimated total cost of my services across the rest of the project (not including the design concept phase, because that’s considered done and dusted at this point). As an aside: whilst it’s really important that all parties have a solid idea of how much everything is going to cost, it’s also important that it remains an estimate – as opposed to a guaranteed fixed amount. Projects can change and evolve as they go along, and it’s worthwhile making sure the wording used reflects this. In the vast majority of cases my clients pay exactly what I estimated them originally, but it seems like a good process should take into account as many possibilities as it can.

I’m working with the idea that there will end up being three stages to this overall in this workflow. So whilst it might make sense to split the estimate in half at this point, with two stages remaining, doing so doesn’t really match the time share across these final two stages – there’s much closer to a two-thirds, one-third split. In the spirit of rebalancing let’s make this happen. Assuming we’re working on the low end of my fee, I’ll take off the first stage payment and then find 66%: roughly £170. This leaves a £105 final payment on launch, which feels like a good amount to cover the work involved at that stage. All this playing around with numbers and percentages is making me want to build a spreadsheet that’ll calculate this stuff for me – so I have.

With the contract signed it’s time to get to work. In my original workflow I’ve split up the process into more parts than I really think is necessary. Perhaps sometimes the pursuit of straightforwardness leads to overcomplexity. Rather like that sentence. Let’s cut all that out for the new design and just talk about it here instead.

There’s usually an initial period of further provisioning now, where the client sends me more material – images, videos, copy – to put into the website. The truth is that this usually continues throughout the whole of this stage of the project during our back-and-forth communication. The same is true for the approval and alterations step – it’s an ongoing thing – so there’s no point in tacking it on the end anymore. It’s all part of the development period.

The amount of time I allow for this stage now adds up to 3-6 weeks. I can imagine this seeming like either a short or long amount of time to develop and build a website to a launch ready state, depending on your experience – but it’s a realistic timeframe for me, the way I work, and the kinds of projects I work on. Of course, larger and more complex projects will take the longest and can exceed what I’ve stated here.

By the end of this stage we should be at a point where the client is happy with what we’ve created: they will have navigated and agreed a development build of the site. The site will be feature complete and in most cases up and running on the server, albeit returning an under construction page.

The new design for this stage of the workflow is below, and in the final article for this topic we’ll take a look at the third stage, and close out by putting them all together for the completed redesign of my workflow. I’m excited. Are you excited? Well, I am.

My workflow timeline redesign: stage 2