Archives For Business

I will be out of the office for most of June.

This is for various reasons. Partly, we’ve been struggling with a few tricky, long-term projects recently, and we need to focus on these in order to finish them off. (I’ll post a longer blog post about these at the end of the week).

Partly, my wife goes back to work next week after taking four years out to have our three kids, and I’ll be juggling childcare while we get used to the new arrangement.

Mostly, though, I’m feeling burnt out. As some clients will know, I’ve recently had testicular cancer, requiring surgery and chemotherapy, and while it’s all relatively minor as these things go, I’ve only taken four days off work in total. That’s not ideal.

So, I’m taking June off, which means that we’re pretty much closed. This will allow me to recharge, and also to spend some time thinking about where the company goes from here.

I’ve spent a lot of time over the past six months putting a very robust support system in place for clients who want it, so no existing clients will be inconvenienced. It will still be possible to raise support tickets, and these will still be addressed in due course.

It will also be possible to book in future work, although we obviously wouldn’t be able to start anything until July.

Otherwise, I’ll be back in a few weeks.

Thanks,

Chris

This is a post inspired by the “Red Matter” Content Creation Club, from our buddies at Burning Red.

This week, we were challenged to come up with a simple “list” piece, choosing the top five to ten “things” that are related to our business.

This has inspired me to finally put together a “top five web apps” list, which is something I’ve been meaning to do for a while anyway. This is the whole point of Red Matter, to encourage you to make time for your blog, and I highly recommend it.

So without further ado… these are the top five web apps that we’d genuinely struggle to run the business without.

1. Nirvana

nirvana

This is a simple GTD task manager, based in the cloud so everything synchronises nicely between devices.

I use this application constantly. Everything I do, is listed in this application. If it’s not listed, it won’t get done; it’s as simple as that. If someone emails me and asks me to do something, I immediately create a “to do” item for myself (usually with a link to the Gmail URL for that email, which is very handy). I start every day by arranging my outstanding items into order of priority, reschedule those that won’t get done, and so on. It’s not a collaborative tool — you don’t assign tasks to others, or review group progress — but it’s not designed to be. This allows me, as an individual, to better manage my own time.

Nirvana is based on GTD, so it comes with all the features you’d expect to see; a “Focus” list, a “Someday” list and so on. Fundamentally, though, I just find it absolutely vital to have a task list to work through. I’ve tried many, many solutions, but none has worked as well and so seamlessly as Nirvana.

2. Passpack

passpackThis is a secure, online password manager, and another tool that I find vital. All our passwords — all of them — are stored on this site. Again, the fact that it’s based in the cloud means that all our devices automatically have access to the latest data, and all team members can access or add passwords whenever necessary.

Passpack only store encrypted data, using 256 bit encryption, so even if data was lost there would be very, very little risk.

I’m always amazed to see agencies relying on Excel documents saved on shared drives to store passwords, or individual developers running their own password applications and accounts locally. It’s essential for us to have a centralised password database, accessible remotely, and Passpack fits the bill. It’s not perfect; the website could do with a bit of an overhaul, and using it on mobile is a bit clunky. Still, this is definitely something we’d struggle to live without.

3. Bitbucket

bitbucketA technical one, this, and one that all developers will have heard of and almost certainly used themselves.

Given that we usually have more than one person working on a website build — either concurrently, or just picking up various tasks at different times — we need some way to ensure that the codebase is kept consistent, and that it’s impossible to overwrite each other’s work. This is where Bitbucket comes in, as it allows you to host as many private “code repositories” as you want. (If you have no idea what this means, there’s a nice guide to version control here).

Once you get used to working this way, it’s impossible to go back. No more synchronising files over FTP, or asking someone what files they’ve been been working on. Just pull files from Bitbucket, make your changes, and push them back in.

There are lots of other people offering the same service, of course, or you can host your own repositories quite easily. Bitbucket works very well though. It also allows you to maintain a small Wiki for each project, which is useful for setting out the key information about a website that everyone needs to know. They also have a very simple “issue tracker”, which has actually replaced more advanced alternatives (such as Basecamp) for our internal task management. Even better, it’s free, although to have more than five users (as we do) you have to pay a small monthly fee. It’s still extremely affordable, though.

Bitbucket actually had a few very brief network issues the other day (a rare occurrence) and we were literally struggling to get anything done.

4. Deploy

deployAnother technical one. Code repositories, such as those hosted by Bitbucket, allow us to maintain a consistent, shared, protected codebase for all our projects. However, there’s no automatic way to transfer those files to a web server (ie, deployment); at the most basic level, one individual user still has to checkout the latest version of the code, and then FTP everything to the server.

This is where Deploy comes in. Essentially, you give it the name of your Bitbucket repository, and you tell it how to connect to your server. You can then click a big button labelled “Deploy”, and it will automagically copy all the latest files from the repository directly to the server.

This is such an efficient way to work, we couldn’t ever go back to using FTP. FTP is a faff. It’s slow, clunky, and actually synchronising files — working out what’s newer, what’s been changed, what can be overwritten and so on — is a nuisance. Theoretically, of course, code repositories help with this, as you can be confident that the files you’re uploading are the very latest ones. However, you’re still unsure which files to upload, so unless you upload the entire codebase each time — which would take ages — then FTP is still fiddly.

Using Deploy, the process of uploading website changes to a site is quick and painless, so much so that it pretty much happens behind the scenes. (Indeed, for “client preview” sites, we usually configure deploy to automatically copy files as soon as we commit them to the repository, which removes any manual steps completely). Reverting to FTP would be a huge retrograde step.

5. Crunch

crunchNot a technical one, this, and arguably not even a web app. However, it is another online service that has removed a huge amount of time-consuming administration and legwork from our normal working day.

Crunch are online accountants, meaning that they provide a full accountancy service. If you have a full Crunch account, you don’t need a separate accountant (indeed, we moved to Crunch from our previous accountants some years ago). However, not only do they manage your accounts, they also give you access to a very comprehensive website that allows you to:

  • Issue invoices
  • File expenses
  • Pay your VAT, PAYE and Corporation Tax bills
  • Review your income, outgoings, tax liabilities and so on

For us, the ability to issue invoices and file expenses directly from the website is brilliant. We no longer have to create an invoice separately, and then make sure that we’ve sent a copy of that invoice to our accountant. Because we issue invoices directly through Crunch, they’re automatically filed with the accountant, so they’re automatically added to our tax record and so on. Crunch then makes it easy to see what invoices are owning, which are overdue and so on.

Similarly, recording expenses in the system means that there’s no separate paperwork, no envelope of receipts to stuff and send off by post. Crunch even have an app called “Snap” that allows you to take photographs of your receipts using your phone, and file them automatically.

Managing our accounts with our old accountants was painful, a slow system of updating an Excel spreadsheet like it was 1996. Crunch’s web app makes everything really easy.

Note: the link to Crunch here is a referral link, which rewards us if anyone happens to subsequently sign up. However, this has no bearing on my recommendation; Crunch are excellent and I don’t know why anyone would use anyone else. If you want a standard link with no referral code, though, it’s http://www.crunch.co.uk/.

As I briefly discussed in our “New Year’s Resolutions” blog post, one of our key aims for this year is to formalise and improve the level of support we offer our customers.

We currently offer just one support package, which costs £400 p/m.

Although this works very well for some clients (and will continue to do so), it’s has proved to be simply too expensive for others. Our full support contract is designed to offer frequent, prioritised, out-of-hours support, and most clients don’t need anything so comprehensive.

Instead, they just want ongoing, occasional maintenance for their website, and the reassurance of knowing that someone is on hand to help out if necessary.

We’re therefore introducing a second-tier support contract, which I’m calling “managed hosting”.

This will cost £100 per month, and will offer:

  • Hosting on our latest dedicated server
  • A monthly website report, generated by Sitebeam
  • Access to our support email address, for emergency, out of hours use
  • Small updates and changes carried out free of charge, within limits

This last point is perhaps the most important. Up until now, all clients have been billed at £80 p/h for website updates, with an unofficial minimum charge of two hours.

However, it’s often been difficult to judge whether a very minor amend is simply too small to justify raising an invoice for £160+. In such cases, we’ve attempted to squeeze in the work for free, as a favour; but free work often slips down the priority list, or gets in the way of paid work. This doesn’t benefit us, or any of our clients.

For 2014, all work will be billable. However, for clients with a managed hosting contract, anything taking roughly 30 minutes or less will be carried out for free. We can’t guarantee a fast turnaround, but we will aim to complete all such work within five working days. (T&Cs will also obviously apply; for example, we wouldn’t expect to make more than two or three such changes a month, as a rule).

Where a change will take longer than 30 minutes, we will carry this work out at £60 p/h, with no minimum charge. This obviously represents a reduction on our previous hourly rate; the intention being that the new lower rate will be offset by the cost of the monthly support contract.

However. In the absence of a support contract, an hourly rate will no longer be available. It will be necessary for clients without support contracts to book a full day of our time, at the standard rate of £400.

I genuinely feel that this will offer a better service to our clients. This new support structure isn’t designed to increase our income; as I say, I hope that the monthly fee will be offset by the lower hourly rate.

Instead, it should mean that there will be no ambiguity about our responsibilities once a site has launched, and no confusion about whether or not a particular change request is chargeable.

(Incidentally, it will be perfectly possible to set up a managed hosting contract for a site hosted elsewhere; as long as we have sufficient access to that server, we can still offer the same support contract.)

I’ll soon be updating our rates page, and producing a more detailed explanation of exactly what a managed hosting contract will offer. This will cover the exact specification of the server, discuss the “Sitebeam” report in more detail, and generally clarify the conditions for any free work. I’ll also provide details of how a managed hosting contract differs from a full support contract, with clear examples showing how individual requests would be handled/costed under each one.

If any clients reading this have any questions, please get in touch. Otherwise, watch this space!

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.

OK, hands up. When it comes to Twitter, agencies in glass houses shouldn’t throw stones. I’m not massively happy with our Twitter feed as it stands. It’s an odd mix of industry news, technical PHP tips, and a few random non-work things that amuse or interest me. I also find it hard to strike the balance between tweeting as “the company”, and tweeting as an individual (I think this is quite a common problem for small agencies). I’m working on it.

Having said that, these are the top five tweets from marketing agencies that always make me think, “Oh, come on — you really should get Twitter by now”.

1. “Morning! How was everyone’s weekend?!”

A schoolboy error: you have confused Twitter with “text messaging”, or perhaps, “greeting your co-workers”. What is the point of this tweet? Are you actually interested? Really? Are you expecting a hundred different replies? Mine was fine, thanks, quite busy running around after the kids but all good fun. You? Will you then reply with a summary of your own weekend? Nobody gains anything from this exchange. Nobody follows you in order to be asked how their weekend was, unless they’re extremely lonely.

Invariably, no-one replies to these tweets. I always want to respond after a few hours with a photo of some tumbleweeds, but never dare.

2. “Today’s Google Doodle”.

Last I checked, Google was the world’s most popular search engine by a huge margin, with about eight trillion searches a second. It’s probably the first page that 90% of your followers have looked at when getting online that morning. They have already seen the Google Doodle. Plus, Google have doodles all the time now, it’s not even news. You may as well tweet, “The sun is in the sky”. Yes, we know. We’re looking at it right now. Cheers.

3. A popular meme, posted about five days too late.

“Check out this baby being snatched by an eagle!!” Yeah, we checked that out on Monday, when every other man and his dog tweeted the same link. Then we found out on Wednesday that it was faked. It’s Friday now. This is the Internet. Today’s news is pretty much today’s fish-and-chip wrapper. You may as well retweet your equally pointless “How was everyone’s weekend?” tweet for all the relevance this has.

4. “Great week last week, two big client wins!”

This is maybe a bit of a harsh one — after all, what is Twitter for if not self-promotion? — but to me, this always just sounds a little too smug. If you’re working with some nice clients, or have started an interesting project, tell us what it is. Even if you can’t name names, you can add some substance. Whooping about your latest wins tells us nothing; for all we know, you’re making it up and you haven’t won anything for months.

Tweeting “Yay for us!” is the Twitter equivalent of the Facebook status “Rubbish day today :-(“. It’s designed purely to elicit a response (“U OK hun?”), to which you can tap your nose and appear mysterious, secretly hoping people will ask more. We won’t.

5. “Don’t miss our latest TV advert tonight!”

This one is baffling. “Make sure you tune in for our latest dog food commercial, 7:15 tonight during Cowboy Builders on Five“. Seriously? Newsflash, no-one enjoys watching TV adverts. I’m not sure people even enjoy watching TV much nowadays. One of the many benefits of downloading TV shows is that you’re not interrupted every 15 minutes by idiotic adverts for toothpaste. (Hey Sensodyne; if you’re going to pretend that you’re interviewing a dentist live, and wiggle the camera around as if it’s a handycam, that’s fine. Rapidly cutting through multiple camera angles is pushing it a little, though).

Either way, no-one — absolutely no-one — is going to purposely tune into a TV show halfway through, to watch an advert you have produced. OK, you will. Your colleagues will. And so you should, you’ve produced some work that you’re proud of. Really, though, this is an internal memo. Not a tweet.

Our email policy

Chris Gibson  —  March 20, 2013 — 2 Comments

NB: This is really an update for clients, rather than a blog article. However, it may raise some interesting questions, so I’ve posted it here regardless.

Over the last few months, we’ve found the number of emails we receive to be very distracting.

It was becoming clear that when we weren’t receiving emails — when we were working offline, or out-of-hours — our productivity increased. This was purely because we weren’t having to continually respond to messages, and we could focus on the tasks in hand.

Obviously, communication is very important, and email is an excellent communication tool. Ultimately, though, it’s equally important that we don’t miss key deadlines because we’ve been sidetracked by day-to-day minutiae.

So — we’ve implemented a new policy that aims to address this.

From now on, we will only check emails at three points throughout the day:

  • 9am
  • 12pm
  • 4pm

There will be very few exceptions to this rule!

This means that most emails should still be answered within three or four working hours. If an enquiry is especially urgent, clients should call the office; the main number will always be answered during office hours.

This isn’t something that’s just designed to make our lives easier. It will, I believe, allow us to provide a better all-round service to all clients. However, if this will affect you, and you have any comments or questions, please don’t hesitate to get in touch.

We also have several other changes in the pipeline, regarding scheduling, costs and our support/warranty packages. These will be explained in future blog posts!

A quick addendum to this; any emails from clients with support contracts will be checked throughout the day, and not only at these fixed points.

We work with a large number of digital agencies, usually building websites based on designs that they’ve produced.

Almost all of these agencies are staffed by talented, creative people, and are a pleasure to work with. However, most of them also make the same mistakes time and time again, especially in the context of outsourcing work.

Here, in no particular order and broken into the three key areas of Visual Design, Project Management and Technical Tools, are our top ten.

Visual Design

1. Failing to produce working website designs

This has been possibly the greatest failing of digital agencies ever since I started building websites professionally in 2001. Just because someone is a great print designer, that does not make them a great web designer. It doesn’t even make them “a web designer”. Building a website requires an understanding of UI, of user journeys, of how a website works. It’s actually surprisingly rare that we receive designs from an agency that demonstrate this understanding.

To take some examples at random, we frequently sit down with a new batch of designs and immediately ask questions like:

What does that link/button do?

Don’t add any kind of link or button to a template unless you know where it goes, and what the next page looks like. I’m forever asking clients, “Where does that ‘Read more…’ link go?”, and even they have no idea.

Why is there a search box in the top corner?

Has search been agreed as part of the functionality? If not, don’t add a search box to the designs. (If it has, have you produced a design for the search results page?).

What happens when this form fails validation, or submits successfully?

Do add error states to your forms. Do make sure you include a “Submit” button. Do think about how the “Thank you” page will look. Don’t redesign form elements so they look pretty. Honestly, just don’t.

2. Failing to understand the difference between templates, and page designs

Most websites — especially CMS-driven sites — will be powered by a relatively small number of templates. For example, we may have:

  • The homepage
  • A “section” page
  • A “content” page
  • A “form” page (e.g., “Contact us”)

… plus templates for FAQs, news articles, galleries and so on.

When producing the designs for the site, you just need to produce one design per template. No more, and definitely no fewer. There’s no point producing several near-identical versions of the “content” template, unless each clearly illustrates how the layout will handle varying amounts of content.

Speaking of which, each layout must be able to handle varying amounts of content where required; don’t line everything up nicely with single lines of text, if the client is likely to use the CMS to add three or four lines of text to each panel.

3. Producing website designs in vector formats

A website is fundamentally made up of bitmap graphics. This may change in the future, if Canvas becomes more widely used, but for the time being, websites are rendered using pixels. This means that in order to reproduce designs faithfully on screen, the originals should also be bitmap images.

It therefore follows that the following file formats are not, in our opinion, entirely suitable for website design:

  • Illustrator
  • InDesign
  • Fireworks
  • PDF

It is just about possible to work from vector files like these. However, the resulting HTML pages will be an interpretation, rather than an exact reproduction. The design will have determined roughly where the elements should go, but the front-end developer will have to implement this layout as best they can, using (bitmap) images and CSS and so on. There is no point producing vector graphics and then complaining that a layout isn’t pixel-perfect *; this makes no sense whatsoever.

* Whether or not we should ever strive for “pixel-perfect” reproduction is another issue, but the overall point is still valid.

Yes, Illustrator might be “easier” or “quicker” than Photoshop, if you’re more familiar with the former than the latter. This is besides the point. If a front-end developer explained that he was going to use tables for layout, because hey, it’s quicker and easier as he hasn’t really used CSS that much, that probably wouldn’t go down well.

If you’re producing website templates, use a bitmap editor; Photoshop, Pixelmator, Acorn, Gimp, as you choose. Just not Illustrator. Or Fireworks. Or InDesign. Especially not InDesign.

Project Management

4. Failing to understand the concept of “signing off”

I have had the following conversation with agency clients about 100 times.

Me: So, are these designs the final versions? They’re definitely signed off?
Client: Yes! Pretty much!

Look closely; the answer the client has given above is, in fact, “No”. See also:

  • Yes! We just need to make a few changes.
  • Yes! All apart from pages A, B and C.
  • Yes! Their MD just needs to take a quick look.
  • Yes! Any changes from now on will be very minor.

The starting point of any front-end (and sometimes back-end) development will ideally be a set of complete, final, approved visuals. If this isn’t possible for any reason, that’s OK. However, everyone needs to be very clear that this is the case, and not cheerfully pretend that the design phase is complete, when evidently it is not.

Incidentally, when the design is signed off, and when the end client decides to actually bother looking at it properly two weeks later, and requests some changes, that’s no problem. However, if you’re outsourcing the build, these changes will take time, cost money, and impact on the overall schedule. Don’t just say to the client, “Yes, of course, easily done, no charge, we’ll do it today!” and expect your external developers to say the same to you.

5. Failing to produce a working schedule

It’s staggering how many companies are unable to schedule web projects. This usually begins with a failure to get the designs completed and signed off within any sensible period (see “signing off”, above). Once the designs slip, the entire project starts to fall apart.

Agencies also fail to get the actual content (text and image) from their client in time, leaving it until the last minute, and then realising that the content won’t fit in the templates produced. This is usually due to giving the end client far too much leeway; or, compounding their failure to get the designs signed off, and accepting content that is also “95% complete… it’s mostly there, just a few pages missing” and so on.

This rapidly descends into “beer-and-pizza” scheduling, whereby any sensible planning is replaced with a wide-eyed optimism, and the idea that an entire week’s work can be done in one evening if the Project Manager orders beer and pizza for the designs and developers. This may wash with internal staff (even if it still won’t actually get the work done), but when outsourcing work, your hopeful offers of food and drink are unlikely to be accepted. You just need a formal, realistic schedule that everyone sticks to.

I had the following conversation with a sizeable Manchester agency recently:

Client: We need the website live within ten days.
Me: But you haven’t produced a spec, or a site map, or any designs.
Client: Yes, X will be doing all that by the end of the week
Me: Well, it’s Thursday afternoon now. Will X really be able to produce all this, and get everything signed off by the client, for Monday morning?
Client: Yes, yes, but he’s just very busy at the moment.
Me: OK. In my professional opinion, based on where you are now, you will not launch this site within ten days. It cannot be done.
Client: Yes, haha! It is very tight! Haha!
Me: No. I don’t think you’re really listening to what I’m saying…

Again, beer-and-pizza scheduling. I contacted the client on the Monday to see how they were getting on. I never received a reply, and I suspect the project died a death.

Clear, realistic milestones are very easy to put in place, once you stop telling the end client what they want to hear, and instead telling them what can actually be achieved. In our experience, this leads to a much smoother project and ultimately a much happier client.

7. Forwarding client emails verbatim

An easy one, this. As an agency, if you’re outsourcing development work, then you earn your money by managing the client, and making sense of what they want — converting their wish lists into a clear, formal brief. If you’re just going to forward emails from your client, with the line “Please see email from client below!!” then you may as well not be involved; we’d certainly make a lot more profit if you weren’t.

This also often goes hand in hand with a failure to understand how outsourcing works. An outside agency, or a freelancer, is not just another member of your development team. Neither are they still responsible for maintaining the website years after the launch. Unless they’re charging a day rate, and have been booked to work on that specific day, you can’t just send them an email saying, “Please make this change to the site today!”. The question you need to ask is, “We’d like to make this change to the site; how long will it take, what will it cost, and when can it be done by?”.

Technical Tools

8. Using Excel as an issue tracker

The following is a list of people who need to use Excel:

  1. Accountants

You will note that “Project Managers” does not appear on this list. This is because Excel is a spreadsheet tool; it is not an alternative to Word when you want to use fancy table-based layouts, and it is distinctly not an issue tracker.

It always starts out fine, with one column for “Issue” and one comment for “Actioned yes/no”. Then you add another column for “Developer comments”. And another one for “Agency/client comments”. Then you need another column for “Developer response”. Then you decide it’s all getting a bit messy, so you add your comments to the “follow-up” cells, but in green. Then you highlight “completed” rows in yellow, and “urgent” ones in red. Then you add some more rows. Ignore the first three rows, though, the client has changed their mind. I think.

Excel hasn’t been an acceptable way of tracking issues since about 2002, and it was pretty crap then. Use Codebase. Use Basecamp. use BitBucket, GitHub, Campfire, Sifter. Anything but Excel.

9. Using Dropbox as the main file repository

Dropbox is great. It has many benefits, when used internally. However, when sending files to external developers, it is not (in our opinion) entirely appropriate.

External companies almost always need a final, definitive version of a file to work from, whether that’s a spec, a design, a content document or whatever. When this file can change at a moment’s notice, the concept of “signing anything off” (above) is lost.

If a front-end developer starts to build a design as HTML, you shouldn’t then update your Dropbox version with a new logo, and assume that the developer will monitor the folder, pick up the new version and change course. That is a process with no controls whatsoever.

Similarly, if you’re providing content documents, these should be supplied in (ideally) one single, signed-off batch. You can’t just create a folder called “Content”, and drop documents into it as and when you receive them, unless this way of working has been clearly defined in advance.

10. Using entirely inappropriate hosting

It’s amazing how often a client will give us details for the kind of hosting account that you might find in a Christmas cracker; a Crapspace Home User Plus account that costs £3.99 a month and doesn’t come with a database. If a website is worth building, it’s worth putting on a decent server. And for God’s sake, if you’re an agency, don’t let your client arrange hosting themselves, or we’ll be back to Crapspace — or worse, using IIS because Tim, their obstructive in-house IT guy, will only use Windows. Specify your hosting requirements and spend sensible money on it. Incidentally, Melbourne (based here in Manchester) are excellent.

As an aside, I’m forever being told that a client’s email is down, or that their emails are being incorrectly flagged as spam — or, I’ll receive an out-of-office reply every single time I email a client over the course of a week. Email is important. Find a reliable provider, and pay for it if necessary.

Since rebranding as an agency, we’ve had a general rule that we (almost always) ask a client what their budget is, before we provide them with a proposal or even costs.

This article aims to explain why, and the benefits that we feel that this approach offers.

A little history

When I first started freelancing, I’d reply to pretty much any enquiry, without any quality control. I’d put a lot of effort into these responses, practically writing a full technical specification for each one.

I eventually learned – and this took me far longer than it should have done – that there are some leads that will never lead to any paid work. Some “clients” literally have no money to spend. Others are under the impression that websites are cheap to build, and that they can somehow build a booming online business in their spare time, for an outlay of £500. Asking for a client’s budget immediately filters these people out; indeed, you’ll almost certainly never hear from them again.

Other clients do have some money to spend, but simply can’t afford the website they want. In such cases, asking them to define their financial limits immediately makes it clear if the project will be viable.

Some common examples

Over the past few years, two types of enquiry have been very common (and always without a defined budget in place):

“I need a website building, and it must have a CMS”

As a freelancer, I’d spend a long time compiling a list of questions in response. How big is the site? How much of it needs to be under the control of the CMS? Do you need to add pages, or just edit existing ones? How many users will the CMS have?”, and so on.

Now, by establishing the budget up-front, we can instead just advise the client on exactly how comprehensive the CMS can be, or whether a CMS is even a viable/cost-effective option.

“I’ve had a great idea for a project — it’s a bit like [insert name of large, successful website here]”

This was very common. I’ve previously been approached for websites that were “Facebook… for brands!” and (even better) “Facebook… for dogs!“.

In both cases, I’ve explained that these projects would need huge amount of planning and R&D, and that they’d be expensive. Facebook… for brands! didn’t even bother to reply, despite the fact that I’d taken the time to include some helpful pointers in my email.

Facebook…for dogs! explained testily that their budget was only £3k, but that they had now found an alternative developer, who had “the right attitude” and who could deliver the project within budget. One year on, I’m still waiting to see the finished website.

The client’s concern

Of course, the client’s concern is always that by stating a budget (say, £10k), they’ll receive a quote from their agency of exactly (or perhaps just under) £10k. My view is that this is exactly what will happen — and, exactly what should happen.

By setting out a budget, the client is asking “What can you offer me at this price?”. The onus is then on the agency to come back with the best possible solution, for that cost. If the solution meets all the client’s requirements, then any concerns about costs have already been addressed, because the solution already fits the budget.

The inverse approach, which is more common, is for the client to effectively say, “Here’s a summary of what I want; please go away and guess what I want to spend, and then give me a specification that meets that budget”. This is often counterproductive, as per the next example.

A better case-study

More recently, a project came along that illustrated exactly why a predefined budget is important.

We were approached by an organisation who asked us to pitch for the rebuild of their website. The project was going to tender, but they knew of us via an existing client and thought we might be a good fit.

I went down for an initial meeting, and the project (a large CMS job) sounded ideal for us. However, when I asked them about budget, I was told that there was no fixed budget, and the client was “looking for best value but doesn’t want to limit the project at this stage”.

It then transpired that another of our clients, a much larger agency, were also pitching for the work. After consultation, we decided to present a joint tender document. This made a lot of sense — they had a lot of resource, not to mention an existing relationship with the client, but were short on the specific technical know-how. We had exactly the right skills, but less resource.

In fact, the unofficial feedback I received from the client after our first meeting, was that that they had reservations about using such a small company. A joint proposition with a larger partner agency therefore seemed ideal.

However, after submitting a joint tender document, the eventual response from the client was that the cost we’d quoted was above budget — and what’s more, that most of the proposals they’d received were also too expensive.

Clearly, the client had in fact been allocated a budget for the job, but were reluctant to share this with us. This was a mistake for three reasons:

1. It wasted their time.

The client will have spent considerable time meeting agencies and reviewing proposals, only to find that they were too expensive. If they’d given a fixed budget, either the proposals would have been under budget, or some agencies may have chosen not to pursue the work.

2. It wasted our time

To an extent, this is the nature of pitching for work; we frequently discuss projects with potential clients (or, existing clients) that come to nothing. That’s part of the job.

However, in this specific instance, we spent a good amount of time with our partner agency, producing a proposal that was always going to be too expensive. The client sabotaged their own process by aiming to bring in a large company, but then balking at the associated costs. Defining their (limited) budget in advance would have made it clear that the project was too small for the larger agency. We could then have potentially pitched a more cost-effective solution ourselves, giving the client another option (see below).

3. It ultimately limited their options.

For our proposal, we pitched a comprehensive CMS that would have been very powerful and flexible, but one which came at a price. Had we known that they had a smaller budget, we could have proposed a CMS that was more limited, but which would still have served their purpose and have been affordable.

If the lower-cost solution had been insufficient, or weaker than the competition’s offering, then the client would (and should) also have rejected our proposal. However, they would at least have had a range of options to look at. Instead, most of the tender documents they received were out of budget, and therefore had to be ruled out — leaving them with presumably only around two or three suppliers to choose from.

If the client had been up-front about the fact that they did have a budget to work within, this would have all been avoided, to the direct benefit of the client.

Conclusion

In our experience, asking for a client’s budget up-front is very beneficial, for three main reasons:

  1. It filters out clients who claim to want a website, but who actually have no money to spend. (They actually just want to know what the site would cost, if they ever did have any money; the equivalent to having your house valued when you have no desire to move).
  2. It encourages other, genuine clients to think about their budget, and what they can afford, as opposed to what they want.
  3. It allows you to define a website that is the very best that a client can afford.

Most clients have been very willing to discuss budgets once asked, and all of our most successful recent projects have started in this way.

Fundamentally, pitching for work can all too often involve guessing what the client has to spend, and then proposing a site that you hope will be affordable. Asking for budgets up front inverts the process; rather than allowing the specification to dictate the cost, you allow the cost to dictate the specification.

… what a way to make a living.

I’ve been struck recently by the number of people in our Twitter stream who appear to be working ludicrous hours — up at six, still working at ten, and carrying on throughout weekends and holidays. For example…

Continue Reading…

A new blog

Chris Gibson  —  April 4, 2012 — Leave a comment

Despite being fairly late to the party, our recent adoption of Twitter has proven to be an effective new business tool. It’s led to at least one substantial project that would otherwise have passed us by, and generated several more decent leads.

In that spirit, I’ve decided to launch a blog. This will become either a useful output for articles and code samples that are too substantial for Twitter — or, another drain on our time that we will quickly start to resent. Time will tell!