It’s not your technical ability.  That’s a given, otherwise you wouldn’t be in this job would you?

It’s not finding a push-over client.  The client is busy and has their own problems to solve.  

It’s a combination of organisation, management and communication.  

Stay organised.  Always know what is outstanding, who is doing it and when it will be done.  

Manage your client.  Software projects are strange in that so much of the process is intangible until final delivery.  So manage your client.  Guide them to where you need them to be.  Make it easier for them to be a good client than a bad one.  It won’t always work - sometimes there are clients who simply don’t fit - but for the most part it’s your job to keep them on the straight and narrow.  

Talk to them.  Always keep them up to date.  Respond to questions as quickly as possible - at least within a day.  Even if the answer is “I’m a bit busy at the moment but I’ll get back to you before the end of the week”.  With all these intangibles flying around the client looks to you to keep them grounded.  

A perfect example of this is a recent job I have been working on.  My client was a marketing agency.  Their client was a small business - we mainly dealt with the MD and Head of Marketing.  There was also a couple of people from an SEO involved.  

For some reason every job I did for them seemed to take a lot longer than the estimate.  I got the feeling that, despite the eventual, fantastic, results, there was a lingering undercurrent.  So I persuaded them to organise the project through good old Basecamp.  

And the reasons for the delays became immediately apparent to everyone, from the SEOs to the MD.  What would start out as 8 To-Do items assigned to me quickly became 30-odd To-Do items, assigned to everyone else involved - as questions were raised, slight changes in direction were needed and designs were reworked.  

With all this stuff out in the open the next phase of the project went much more smoothly than the earlier ones - because I managed the client into organising things through a better channel for communication.  

Because, the way I look at it is, at the end of the day, it’s your job, your client and your responsibility to keep things ticking over.  Don’t you think?  

Everyone’s favourite shared host, Dreamhost, has had a major fuck-up. They accidentally billed a lot of their customers for a year in advance. Some of them were billed repeatedly. Some had accounts suspended for non-payment, others incurred overdraft and credit limit fees.

Ignoring the fact that it never should have happened (test, test, and test again where money is concerned), Dreamhost responded in their standard way. An update on their status page and a jokey blog post. The status page is good - an apology, they pinpointed who made the mistake (rather than hiding behind corporate anonymity) and stated what they were doing to set things right.

It’s the blog post I have an issue with. When you have made a $7.5million mistake (that’s what they claim the extra billing adds up to), you shouldn’t make light of it. When you have caused your customers to incur bank charges and fees, you don’t joke around. But, fair enough, that’s Dreamhost’s style (and originally one of the things that I liked about them). Where I really have problems is with this statement:

Really, it’s sort of amazing this never happened before in the last ten years.

When you’ve fucked up royally, especially when it comes from not testing your systems properly, you can’t (in a joking manner) say “ho ho, well it was always going to happen one day, it just happened to be today”. It doesn’t exactly fill me with confidence that it isn’t going to happen again in a couple of months.

It just ain’t good enough, is it?

I have been planning this post, on and off, for months. Then I almost shelved it, when I read Shane’s excellent “Just like Air“.

You see I wanted to write something very similar. Not the bit about “money being like air” (although that would be nice, it’s not my goal). No, it’s the bit about small business being best.

When I decided to embark on this enterprise, I spent ages reading (mainly online, but a few books too) about how to proceed. One thing that still trips me up is how to refer to 3hv in articles. Should I use “I” as, at present, there is only me? Or should I use “we” as people won’t want to buy from a one man band?

And actually, I now use both, depending upon the circumstance. Firstly, 3hv is a one man band (at least for now). But I do work with others as needed.

And there is no reason for most “small to medium” size businesses not to want to work with a one man band. You see, I can offer things that the bigger companies can’t.

Personal Service: you will be speaking to the person doing the work. Not an account manager (who has no technical knowledge) or a help-desker (who has no idea about your particular circumstances). But me. The head honcho. The big kahuna. You can even have my mobile number if you want (in fact it’s on the web-site).

Fast Moving: the world of technology moves at a bewildering pace. Although I have been using Ruby on Rails for years if the time comes to switch I can switch. I don’t have a massive investment in existing technologies. I don’t have a vested interest in promoting one over the other. In fact, being small means that my major vested interest is in keeping costs down - and I can pass that on to you.

Better value: when you hire a large company, what are you paying for? It’s not just the team that is doing the work. There is the help-desk staff, the account managers, the HR Director, the big, fancy office, the company cars, the sales reps. With 3hv, you pay for me, any expenses that are incurred and any outside help we need to bring in to get the job done. Minimal overheads means more bang for your buck (as they say).

Decisions at the Speed of Light: I don’t have to run things by my manager, who has to run things by the regional manager who has to run things by the Finance Director. Because I do all three roles. Meaning that decisions get made quickly. Transparently.

Effective Communications: no chinese whispers as the sales guy says “X”, the implementer says “Y” and the developer says “Z”. The words travel from you to me and back again. Meaning less miscommunications, less wasted time and less frustration.

Priorities: I don’t have hundreds of clients. At the time of writing I have two major clients and a few minor ones. That means that when you hire me I have to treat you as a priority. Every single client is vitally important to me. Meaning I go out of my way to give you the best possible service.

As I say, read Shane’s article. It is inspiring. The wave of the future is micro-companies, doing what they love, exceeding expectations and delighting their customers in a way that is unlike the mega-corporations that surround us today. So join us - if you need a web-site, some software writing or a bit of advice on how best to proceed, contact 3hv today and see how things are changing.

Meeting Room photo by tsk.

Need a web-site but don’t have the technical knowledge to do it yourself?

Choosing a supplier can be a daunting task. How can you trust the techie guy when you don’t know your PHP from your RSS? Just what is the difference between a designer and a developer? Are you being overcharged? What exactly does that word on the invoice mean?

Firstly, it helps if you have some idea what you want. What is the goal of your site? Is it to let people know you exist? Is it to boost sales? Is it a portfolio of your work? A good designer should tailor their designs to meet these criteria.

Who is going to be visiting your site? Where do you want them to go? If you’re wanting an online store, which set of pages does your typical customer have to navigate to place an order. It can be useful to draw up a quick flowchart of how you see your “average” visitor moving through the site. In theory, this can give your designer an idea of how many pages you need and what needs to be on each one. However, be prepared for this to change. A decent designer will also know what works and what doesn’t and should be able to modify your ideas accordingly (of course, explaining why these changes are needed).

The flowchart plus a few ideas on the goals, design and layout should be more than enough for the designer to prepare a quote. Watch out if the quote is simply a price - if so, ask for a detailed breakdown. There are two reasons for this - firstly it forces the designer to think through exactly what needs to be done; secondly, it gives you the opportunity to question any of the items you are not sure about. If you are not satisfied with their explanation of what an item is then just walk away. Most problems with web design and software development stem from miscommunication and misunderstanding. If they cannot express what needs to be done in terms that you can understand, at this early stage, you can be sure that there will be problems down the line.

Next, you need to ask how they will deal with changes to the specification or design. This is because you can be absolutely sure that changes will be required at some point - when you see the final layout you decide that you want it a different shade of green, or they may come across some unforeseen technical problem that mandates a change of tack. No matter what the cause it will happen and your supplier needs to be able to deal with it - preferably without adding a zero onto the price!

Then, ask how the project will be delivered. Will you sit there, twiddling your thumbs until, magically, X weeks later, you see the finished article (and then decide upon that different shade of green)? Or do they break the project down into “milestones” giving you the opportunity to comment and feed back early in the process (when changes are easier and cheaper to make)? This also links to another important point - when do they pay the bill? Is it a deposit up-front and the rest on completion? Or staged payments, linked to each milestone? And what is the sign-off process - how do you and they agree on that what was delivered is what was required?

Lastly, what happens after completion? If you want changes making, do they charge an hourly rate or do they charge a percentage per year as a “support fee”? Do they host the site and charge annually for that as well? And, this one is vital, who owns the source code (the computer code that makes up your site)? If they own it and you decide to switch suppliers for whatever reason, your new supplier will have to start from scratch. If you own it, your new supplier may (or may not) be able to use it as a starting point (depending upon the technologies used, the competence of the initial supplier in writing the code and the competence of the new supplier in reading the code).

As for technology, don’t let anyone bamboozle you. Most web technologies (ASP, ASP.Net, PHP, Python, Perl, Ruby on Rails) are all much of a muchness. I prefer Ruby on Rails - it has a number of benefits to me - however, the benefit to you should be reflected in a lower quote and smoother project delivery. Beyond that, you shouldn’t need to care.

Of course, the easiest way is to contact 3hv.