I gave a talk in May 2025 on the same five things I keep coming back to on every project. Here’s the short version.
Before the tips, the numbers that started the talk: 70% of projects fail from a lack of proper planning. 45% of poorly managed web projects go over budget. 63% miss their deadline. None of that’s a surprise once you’ve been in a few. Here’s what actually helps.
1. Don’t rush in
Everyone’s excited to start. That’s the problem. Take the time to actually get to know the client and the project before you touch anything. Don’t assume you’ve understood the brief just because it sounds familiar. And watch for the moment where everyone’s enthusiasm becomes the thing pushing you to skip the bit where you properly listen.
In practice, this means that the first weeks of a project look slower than everyone wants them to. Fewer tasks moving, more questions being asked. That’s not a delay. That’s the bit where you find out a client’s “simple redesign” actually means that three different stakeholder have three different definitions of simple, and you’d much rather know that at the start than discover it six weeks in when the designs go for sign-off.
2. Write your Dungeon Master’s Guide
Write up what you learned in step one. Detail what you’re actually going to do. Get everyone to sign it off. Not because paperwork is fun, but because a shared document is the only thing standing between “I thought we agreed” and an actual disagreement three weeks later.
It doesn’t need to be long (in fact making it long means no one will actually read it). It needs to be specific enough that two people reading it independently would describe the project the same way. If your document could mean two different things depending on who’s reading it, it’s not done yet.
3. Reuse and recycle
If you build websites, some things turn up on every single one. Build yourself a toolbox – code snippets, patterns, whatever you keep rebuilding from scratch for no good reason. If you’re the PM rather than the developer, build your own version: a toolkit of process you take from project to project instead of reinventing it every time.
This is less about efficiency for its own sake an ore about attention. Every hour spent rebuilding something you’ve already solved is an hour spent not noticing the thing that’s actually new and risky about this particular project. Recycling the boring bits buys you time for the bits that need real thought.
4. Have a content plan
A site is only as good as its content, and every one of those lovely fresh pages needs actual text and images to go in it. Plan for that early. Share the plan with the stakeholders, not just the team. Set proper deadlines for it – content has a habit of being the thing that’s “nearly ready” for six weeks straight.
It’s also usually the thing that gets deprioritised, because it doesn’t feel as urgent as design or development until suddenly it’s the only thing standing between you and launch. Treating content like a proper workstream, with its own owner and its own deadline, is the difference between a launch date that holds and one that quietly slips by a week at a time. To quote Douglas Adams “I love deadlines, I love the whoosing noise they make as they go by.”
5. Communication, communication, communication
Regular, transparent updates with the client. Daily standups and shared problem-solving with the team. When something’s properly going wrong, communication is usually the thing that gets you through it, not a clever fix. And even if you’re working alone, check in with yourself about what you’re actually trying to achieve today.
Communication only works if it’s honest, not just frequent. A weekly update that says “all on track” every week until it suddenly isn’t, isn’t communication. It’s a countdown to a surprise. The useful version says what’s actually going well, what’s genuinely a bit wobbly and what you’re doing about the wobbly bit – even when the’s the harder update to send.
Put it together and it’s not complicated: clear communication, an organised and shared content plan, a toolkit you’re not rebuilding every time, and documentation that means nobody’s relying on memory. That’s most of what smooth delivery and a happy client actually come down to. None of it is difficult on its own. The hard part is doing all five, consistently, on the projects where you’re busiest and least inclined to bother.