Wow – it’s been a long time coming, hasn’t it? I’ve been off actually doing what I’ve been telling you all about – for the most part! Sometimes we all slip up, so I’ll tell you about that now. As ever, you can see all the previous parts of the series here.
So last time we talked a bit about time management, and why Gantt charts – even simple ones – are a lot handier than you might think. But how do you actually do the doing? It’s not just enough to send your Gantt to your supplier and leave them to it – you also need to make sure you know what’s going on.
A good web developer will send you regular updates on progress. Make sure you check with them at the outset how they deal with this sort of thing. It might be enough that they just email if they’re going to miss a milestone; it depends how time-critical your project is, how much you trust the supplier, and so on. If you don’t know them that well, agree with them at the outset that they’ll email you every Friday morning (for example) with an update on what’s done and what’s next. A lot of the time they’ll work hard for a while and have nothing you can really see – loads of technical set-up work, for example, which doesn’t show on the front end. Getting updates can put your mind at rest that things are actually happening.
You might be working with a couple of suppliers at the same time, in which case it’s (possibly) your job as project manager to make sure they all know what’s going on. There’s nothing worse as a developer than to expect a design, plan your workload around it, and then not hear anything about it for a week or more because the designer fell off his trendy scooter and no-one told you. If you’re managing the project, get everyone involved to email you their updates on the Thursday, then send the pertinent updates to everyone on the Friday morning.
You’ll get some developers – good developers, good workers – who slip up. We all do it. I did it recently; I took on a job which was interesting but had no budget, and because it had no budget I got complacent about project management, didn’t spec it, and it soon got out of hand. The natural reaction to this as a developer is to cut off communication, bury yourself in the work as much as possible, and try to push it through as quickly as possible, which I did; we all ended up getting really frustrated with each other for no reason, and a simple project took twice as long and caused twice as much heartache as it needed to.
Burying ourselves in the work is great in many respects, because it means that we’re actually doing it for you and want it cleared out of the way. But from your point of view, you’ve made one or two changes – which seem to you to be quite minor – and now your developer is in a strop and ignoring you. Shutting off communication also means that we don’t get the chance to discuss those bits of the project which are causing us issues – bits that you might not even be that tied to. When we’re trying to finish a project we can be of the mindset that “damn it – I’ll just do this extra thing and get it out of the way” when really we should be telling you the impact it will have.
Don’t panic; but don’t let us get away with it. The best thing to do with a quiet developer is to call them, on a landline if they have one, or on a number you’ve not called them from before if not (otherwise we see the number and suddenly we’re in a meeting…). Don’t get annoyed or upset; we’re working on it (hopefully). But do remind us of our commitment to you, ask if there’s anything you can do, if the spec is clear, and what the updated plan is. See if there’s anything we need which might help. Often, some real content – a product, an article, a content page – is a brilliant thing to send through because it lets us see what you want in context, and it reminds us that we’re actually working on someone’s business, not an anonymous project.
There are, of course, those projects which reach a point which becomes impossible to salvage. Maybe your designer has overpromised – which can be a common cause of delays – or has taken on another project with a bigger budget which, sadly, has a bit more weight when it comes to deadlines (although in reality clearing the smaller projects first is a better way of working). Maybe they’ve utterly misinterpreted your brief, or just don’t care. Whatever the cause, if a project is dragging for months, or the changes you send through just aren’t done, tt might be time to sack your supplier.
First up, think carefully about whether it’s possible to salvage it. If it’s an agency, talk to your account manager or the owner and see if they know what’s up; it could be that they don’t, and can put someone else on your project or just have one big push to finish you off. Agency owners should care about all clients, big or small, because they know about reputation and repeat business; people working for agencies can often lose sight of the fact they’re working for a business which needs to care for customers. They just turn up, code, go home.
If it’s an individual, talk to them, and see what the issue is. If it’s a genuine problem they have no control over – bereavement, personal issues and so on – then discuss if there’s anyone else they know who could help out, and ask them to bill for what they’ve done so far and hand it all over (this might require some handover documentation).
It could be that all the project needs is a bit of clarity. Most developers won’t take kindly to the idea of coming in and sitting with them as they make changes; it’s too easy to say “oh, just try that font a little bigger… now smaller… now purple… now take the swearing out…”. What does help, though, is a clear end point. Make a list of all the things which are needed in order to get to a point that you’re happy enough with the project to move on. Refer back to the original functional spec. Set a clear deadline – first a deadline to get your developer’s agreement on what’s left and if anything is not possible, then a deadline to get things done. If they say something isn’t possible but it was in the original spec, explain that it was promised and that you’d appreciate that coming off the final bill. Make sure you check that what you’re asking in this final list actually was in the original spec; if not, then you really shouldn’t be upset that it’s not done by the deadline. Of course, by not adding to the spec in the first place you can – hopefully – avoid this situation. Always remember: the functional spec is the most important document in the project and is the final word.
If the issue is just that they’re rubbish and don’t care, and it’s clear nothing is ever going to get finished, try not to be too angry. Explain carefully what’s missing; calmly tell them that you’ve decided that it’s better for both of you if you move on and find another supplier; get everything you can from the supplier in order that you can hand it over to someone else. If they’re not prepared to give you any of the code, assets or work they’ve done then (with legal advice if possible – try the Citizen’s Advice Bureau or Business Link) you probably shouldn’t pay them. If they do hand over what’s been done so far, then pay for what’s been done, but don’t feel you have to pay the full project cost if the full project isn’t done.
Then draw a line under it and move on. Small business is an emotional thing. We put our hearts into what we do; when others let us down it’s easy to feel very angry and upset and hurt, and while this is perfectly justified, it won’t help you. Bad suppliers won’t prosper in the long run. Warn people off them by all means, but don’t try to get revenge; life is too short. Find a good supplier, spec it all clearly, and get it done.
Next time we’ll wrap up by talking about launching a site and what you can expect; we’ll also go through the ideas of soft and hard launches and why publicising a website launch can be a bad, bad idea. And also a good idea.