Setting Realistic Timeframes For Your Clients

Website Design General UX Reading Time: 3 minutes

Setting realistic project timeframes for your clients is a key player in ensuring a clients happiness. Not only this but in doing so you will have a useful internal reference for how the project should progress. Unfortunately, anyone who deals with project work knows all too well that not everything can be foreseen or predicted. That doesn’t mean you should give up though and tell the client “it’ll be done when it’s done.” In this article, I’m going to take you through the necessary contributors in setting realistic timeframes.

Understanding and managing client needs and expectations

This should start before the project even begins. When you were scoping the project you should have had a very strong and clear understanding of what the client wants and expects in order to give them a price for your time. That being said, sometimes knowing what they’ve said and knowing what they expect can be two different things.

In our industry, for example, some clients will come to us a say they want a website. Do we have to discern how many pages?; what are the key features?; is it eCommerce?; Who’s providing the content, us or you? Some clients won’t know the answers to these questions, some will. This is where our understanding of expectations comes into play.

If we hadn’t asked this question, we could have been under the impression we’re building a 5-page brochure website whilst the client believes they have paid for a 20-page website with us writing all the content. Spend extra time chatting to the client to make sure you are on the same page about key features, specific expectations and the goals of the project. You will save time in the long run and prevent potentially damaging issues due to miscommunication.

Giving (and sticking to) dates and milestones

This is as important for you as it is the client. Dates and milestones aren’t only for you to uphold, but also the client – for example when the client is going to get you the information you’re waiting on by, and making it clear delays in doing so will cause delays in the project. Equally, if you overstep your own dates, you can identify that there may be a delay overall and how to prevent it from happening next time. Identifying delays early on allow you to plan accordingly. No one wants to be told last minute that a project is running late when it should be launching – being aware of this weeks prior will help.

3 tier approach

If you’re continuously struggling to hit deadlines, consider a 3 tier approach (this can be particularly helpful when working with developers and ought to be used internally unless you really need to mention it to the client). These tiers consist around 3 different dates based on 3 variables: date 1 is if there are no issues, and everything goes perfectly; date 2 is if there are minor problems, typically in testing and rolling out; and date 3 is if there are multiple unforeseen issues and/or the worst case scenario takes place. The last one can obviously be the trickiest to give a date to, but when trying to do so you should consider how much time you can dedicate to this project once it is overdue from the given dates (and resources you can pull away from other projects).

It’s also not uncommon for clients to request extra features mid-build. If you have clear dates laid out, you will be able to generate a strong idea of when the additions will be completed and how much this may delay a project by.

Dates and milestones are a key component for both parties involved and should not be overlooked!

Allocating enough time for thorough testing and final changes

A healthy amount of time should always be dedicated to final changes, final testing, and roll out. However, even when these dates have been set and given, overstepping them can be easily done as the project is “so close to completion” – sprinting these final hurdles can quickly turn into a marathon if you don’t stay on top of them. Ensure you are clear and concise when asking for a final feedback list. Make it clear that once the changes are done from this list, you are ready to go live. It is all too easy to ask for final feedback and doing things well out of scope.

Test as you go to prevent major issues prior to go live, and get multiple people to test if possible. Finally, make sure you have everything ready to roll the project out/hand it over to the client/go live well before you need to do so. Sometimes you don’t know what barriers you face in getting required logins/resources to roll out until you ask – So, get prepared for this by getting them in advanced.

No matter what, you can never predict the future, but following these steps you should be able to give a pretty good guess (and stick to it!)