Sometimes when I'm about to start writing a post, I think to myself that I can't write about something so obvious but then I usually consider the incident that has prompted the post and realise that, especially when it comes to IT, there's a lot of truth in the old adage that there's nothing common about common sense.
In this particular case, I was talking to an acquaintance who has a friend - let's call her Julie - who works for a well known IT provider. Julie's job is to sort out what this provider is going to deliver after a contract has been signed. In this particular case, the company for whom she works has just signed a huge contract with a well known mobile 'phone company. A project has been determined, a cost agreed, a contract signed and now Julie has to work out what actually will be delivered as part of that deal.
Putting this into a household context highlights the absurdity of the situation. Let's say you decide to have your kitchen refurbished. Uncertain of exactly what it is you're buying, you might decide to engage a large, nationally known company to come and measure up with a view to doing the work. A representative turns up at your house, you say to him "I'd like a new kitchen, please". You'd certainly expect him to take a look at your kitchen and maybe even ask you for a few ideas about what you want.
At that point, would you sign a contract and agree to hand over your money upon completion? Of course not. You'd want to see some designs, talk about materials and colour schemes, perhaps look at the prices the company was going to charge for your appliances.
So why is business so very different? Well, to be fair, it isn't always. We do find that with a lot of SMEs, particularly those owned by one person or a small group of people, a great deal of care is taken to understand where the money will be spent. But as a simple rule of thumb, we find the larger the business, the less detail we are asked to provide.
However, whilst a relaxed attitude such as this might seem like an opportunity to get away with being a little less diligent, we like to be absolutely sure what it is that we are being asked to deliver. There must be a specification of some sort. Even, for a small job, say a text change on a website, where the request might take the form of a 'phone call, we will still follow up with an email to confirm what we are proposing to do. But for a job that is going to cost tens of thousands of pounds surely it makes absolute sense for both sides to have a clear specification?
There are a couple of principle reasons, in my experience, why this doesn't happen. (Three, if you count sheer negligence.)
Firstly, the client doesn't understand what they are buying. This is a very legitimate problem. As I have mentioned before in my postings, people are usually pretty good at buying something they can understand, business cards or brochures, for example. Buying a website and, particularly, software is very different. For example, two years ago we put a site live for a new client. It was a fairly straightforward build job and it had passed through UAT and been signed off by the client without incident. So I was surprised when the client rang with a complaint: they had looked on Google and they couldn't find the site. Now I was able to explain that Google and other search engines don't work instantaneously but there was no reason for the client to know that. This isn't a great example because it would have been hard to trap this expectation at any point in the development but it does highlight the fact that you have to work hard to anticipate and manage your client's expectations.
The other problem is when the client doesn't have the time or inclination to get into the detail of the work. A very good example of this is when a client wants a bespoke e-commerce site. During my initial conversations with them, they will often say something along the lines of "we both know what we're talking about: just an e-commerce site". However, when the site is delivered and suddenly it does get some attention, you can find that what the client was talking about was Amazon.
As a footnote to the examples above, this leaves negligence. There used to be a saying that "no one ever got sacked for buying IBM". The implication there being that if you hire a big 'name' company, no one can blame you if the deliverable isn't up to scratch.
So, the bottom line here is that a decent specification protects both sides in the business relationship. As a provider, we know exactly what we're committed to delivering and the client knows what they are buying. This enables us to quote price and time-scales accurately: in fact, I don't know how we would stick to our promise to deliver on time and on budget if we didn't do this.
For larger jobs, we may even charge for the preparation of the specification. This is not always an easy sell but in addition to protecting both parties once it comes to development, it also means we have the time to do really detailed design and analysis. Furthermore, the client can use the specification as a tender document to get the best price for development. I'm pleased to say that, so far, the development work has always come back to us but with the specification done properly, this is not a done deal.
No comments:
Post a Comment