Resolutions for 2014

Chris Gibson  —  January 8, 2014 — 1 Comment

This might be a bit of a hackneyed blog post for this time of year, but – there you have it. These are more for my own reference than anything else; a list to check each month, to make sure we’re on the right track.

These, then, are our New Year’s Resolutions for 2014.

Stop issuing ballpark costs

We’ve frequently (and especially recently) been caught out by clients wanting “ballpark costs”. These are the chicken-and-egg projects, whereby a client won’t commit until they know the likely cost – but you don’t know what they really want until they commit, so you can’t estimate costs.

Our solution has always been to ask the client for a budget to work to, and then provide a spec for a website that delivers as much as possible, within this budget. Too often, though, we’ve failed to do this, and been persuaded to issue ballpark costs regardless.

(This merits its own blog post, I think. Essentially, by asking for a budget up-front, clients often worry that you’ll charge them that full amount, rather than possibly quoting them a figure that’s comfortably lower. However, this is the wrong way of looking at it. We should be charging them their full budget, if that’s what’s available – our job is to get the maximum return for the client’s money. I always feel that it’s similar to “sniping” on eBay, where people incrementally bid tiny amounts on an item to get a bargain. If that item then goes to someone else for a higher figure, and you’d have been happy to pay that higher sum, then you really should have just bid the maximum amount you were happy to pay in the first place. Establish how much you can afford to spend, and then get the best possible product for your money).

Anyway, I digress. A ballpark cost very quickly becomes a fixed cost, within which the client feels they can demand pretty much anything they want. No more ballpark costs — I firmly believe that if a client can’t give you at least a rough budget before you start, they aren’t really serious about the project. A quick test for a client who claims not to have a figure in mind, is to quote ~£50k. When that comes back as “far higher than we expected”, simply ask them what they expected. That figure is their budget.

There are caveats, as always. If a ballpark figure is genuinely essential (for example, if a sales department is trying to sell in a new tool to their management team, and honestly don’t know what funding will be made available), then I’ll always (a) quote high, and (b) set aside some concrete time to review the initial spec before eventually starting work. If the spec exceeds the ballpark, then the ballpark must be revised.

Offer formal support to all clients

We’ve always, since starting the company, struggled to find the best way to support existing clients and projects. As our client base has grown, the general level of support requests — bug reports, or small “can you just…” changes — has grown hugely. We can literally lose days to handling these requests, often without ever raising an invoice.

One solution we put in place was to increase our hourly rate to a fairly high level; this made it viable to carry out — and invoice for — an hour or two of work here or there. However, this still leaves a lot of very small jobs (say, half an hour or so) un-billable, as I try to weigh up “keeping the client happy” with “charging them £200 for a fairly small job”.

What I’ve realised, though, is that by keeping these clients happy, we start to let down other, paying clients, because the small pieces of work distract us from the larger, important projects. For 2014, all work will be billable.

I have a grand plan as to how we can implement this, in a fair and constructive way. My next blog post will go into much more detail. Watch this space.

Always be professional over email

OK, 99% of the time my emails are professional, calm and helpful (I hope). However, on some projects — especially those that started with a ballpark cost! — it’s easy for frustrations to boil over. I do occasionally find myself writing long, slightly tetchy emails that go into far too much detail. Emails which spend far too much time explaining why I think a request is unreasonable, or what underlying external issues I feel have caused a specific delay or problem. This is almost always unnecessary, and has no benefit.

This year, all emails will be replied to with a straight bat; polite, friendly, and to the point.

Check emails at set times

Also regarding email, I really need to stick to my own policy of checking emails at set times. This works extremely well; I don’t enforce it for staff, as I think it’s a personal decision, but I find it hugely increases my own productivity. However, I do find myself drifting back to my inbox when I need a break, or when I’m simply procrastinating. Not this year.

Drop IE8 support

Sorry, Windows users. If you’re still running Windows XP (which was released in 2001) and you refuse to use Chrome or Firefox or Safari rather than IE8 (released in 2009), then we can’t help you. The websites we build might work. Should work. Almost certainly will work. But they won’t look great, and there are no guarantees either way.

Transition to Laravel or similar

This is more of a technical goal than a resolution. This is the year that we’ll leave our current PHP framework of choice (Codeigniter, now discontinued) and switch to something more current. At the moment, the best option would appear to be Laravel, although this may yet change. What we will be doing is assessing a few frameworks, making a decision and then transitioning to it. This will be a fairly major shift, but a necessary one.

Chris Gibson

Posts

My Google Profile

One response to Resolutions for 2014

  1. Hi Chris,

    Good to hear about the plans for the year! As far as choosing a framework goes, i would recommend going with Yii

    In case you need help with developers for the framework, you know who to contact ; )

Leave a Reply to Dhruv Cancel reply

*

Text formatting is available via select HTML.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>