My thoughts on Cumbria Chamber of Commerce's budget response

On Monday evening, I was in Worthing visiting a friend of mine. For dinner, we went to an Italian restaurant that overlooks the beach and has a large decked area out the front, so we were able to eat al fresco whilst enjoying the sea view.

When the time came to settle the bill, the waiter bought the card machine over and processed the payment but, just as he was tearing off the receipt for me, he lost his grip on my card, which fell to the deck and right through the gap between two planks.

The waiter was incredibly apologetic but I told him not to worry; I could just order a new card. However, he wasn’t satisfied with this and used the torch on his ‘phone to peer through the decking. There was my card, about six inches below the decking. This served only to confirm to me that the card was irretrievably lost.

Our determined waiter did not agree, however, and disappeared for a minute or two before returning with two long knives and some blu-tack. And, after three or four minutes effort - accompanied by a little muttered cursing - the waiter passed me back my card.

I’m sure you’ll agree that this young man displayed great conscientiousness here: I’d told him it didn’t matter but he took responsibility for the situation and made every effort to return my card to me, successfully as it turned out.

I’m telling you this to illustrate my argument that any business is only as good as its staff. Your restaurant might serve amazing food but a surly waiting staff will drive away your customers. Your product might be amazing but if your warehouse staff are careless with it or don’t see orders out of the door on time, then people will stop buying from you and go elsewhere. I’m sure you can think of many, many examples for yourself. The bottom line is that your staff is the vital component of your business. (Unless, of course, you are in a monopoly, which might explain a thing or two about BT.)

And since this is a matter of common sense, really, I was very surprised to receive Cumbria Chamber of Commerce’s response to the budget. Sure, I expected it to be business focused, but I also expected a little more insight into the fact that it is the employees that make businesses successful.

Below, I have taken sections of their response to comment on but you can find the entire response at the bottom of this post.

National Living Wage/Minimum Wage
"This, combined with the welfare changes, shows a real move from welfare payments to payments for economic activity - increasing the motivation to work and rewarding work."

There’s a non sequitur here or at the very least an assumption that people who are unemployed need to be coerced into working. Removing people’s benefits does not magically present them with jobs for which they are qualified or able to do. According to the IFS, thirteen million families will be, on average, £280 worse off under the new budget. Nowhere near all of those people are unemployed, so how does cutting their benefits increase their motivation to work?
And how many companies want staff who are distracted and stressed by government imposed financial hardship?

"There is of course a real concern about the cost to businesses, and particularly SMEs. What makes it more palatable to business are the changes to Employers' National Insurance and to Corporation Tax."

Firstly, Rob Johnston illustrates in his second sentence why the concern is not real at all. The real concern should be why are so many businesses not paying their staff a living wage already. If your business can't afford to pay people a living wage then, frankly, you don’t really have a business. Not a proper one, anyway.

"It's difficult to take a global position on the impact as the combination of changes will have differing impacts on different businesses. And there is a need to follow on evidence based approach and minimise the impact on smaller businesses in particular."

I have no idea what that paragraph means. Onwards, then...

"It is a concern that there's an acknowledgement of 60,000 jobs expected to go, possibly mitigated to an extent by NI and taxation changes. While many more jobs are expected to be created these won't be in the same businesses, and businesses may well be lost, while new jobs created may not be in the same geographic areas or available to those losing out. A poorly paid job is still a job after all."

There you have it, a budget for working people that acknowledges losses of 60,000 jobs yet thinks that reducing benefits will incentivise people to find work. It's just bloody nonsense.
And, finally, “A poorly paid job is a still a job after all”. So, suck it up, poor people; be grateful for the job you have, even if you aren't being paid properly for doing it.

Apprenticeship Levy
"This is good news, with businesses positively rewarded for employing apprentices. The challenge is how the money will flow - which we have yet to see. It's to be hoped that there will not be an over bureaucratic system that doesn't work for smaller businesses."

Now this is absolutely clear cut evidence of the government’s smoke and mirrors approach to statistics. If you need to incentivise companies to take on apprentices, then there is no genuine requirement for those apprentices. This simply massages employment figures.

Corporation Tax
"Again this is good news for business. It will mean more money left in the business to make the business flow and to invest and sends out a tremendous message to the world that Britain is open for business."
I’ve two things to say about this. Firstly, if the government want to do anything useful related to corporation tax, perhaps they could start by collecting the £120 billion of unpaid corporation tax (and then we wouldn't need to cut welfare by £12 billion).
Secondly, telling businesses that Britain is a place where you don’t have to pay much tax is not the same as Britain being open for business.

One further comment I’d make is that both the chamber and the chancellor seem have to missed a key point about reinvigorating the economy here. One thing that we can say for certain is that people on lower incomes – say the bottom 50% of earners – spend their money. That might be on simply making ends meet, buying clothes and food, paying their bills, or perhaps, for those earning a bit more,  on holidays, cars and home improvements, eating out and buying luxury goods. What they don’t have the scope to do is put large amounts of money into ISAs, trust funds, and high interest accounts. So, if you want to grow your economy, don’t take money away from those who will spend it!

Rob Johnston blithely states that “This Budget has certainly shifted the agenda with a balance of politics and economics that provides a stimulus to the economy while making much needed changes to the welfare system and continuing to tackle the deficit”.

I would challenge him on all three points there: I don’t believe that this does provide a stimulus to the economy in that it takes money away from those most likely to spend it. I don’t agree that the changes to the welfare system are “much needed” and I’m irritated by this unfounded assertion. And finally, whilst we might be continuing to tackle the deficit, Osborne is doing it in pretty much the least effectual manner possible.

This budget was callous, as was Rob Johnston’s response. All economic arguments to one side, we should be taking care of those who need benefits. Remember, a high percentage of those people receiving tax credits, for example, are in families where at least one adult is in full time employment.

If we want successful businesses and a growing economy, then it makes sense for everyone to take good care of employees, whether it’s through a decent living wage – and not what Osborne counts as a living wage – or through providing benefits.

Buying into the rightwing narrative that is constantly played out in the press of scroungers and layabouts, and a need to cut welfare, is damaging to both our economy and our social fabric. Your company will not be successful if it is staffed by people who are distracted by fundamental concerns about how they are to feed and clothe their families.

Frankly, I'm appalled by how the Chamber has slavishly bought into the government’s narrative. I wouldn't pay money to any right wing organisation, so now I must question why I'm paying membership to Cumbria’s chamber of commerce.


The full text of the response

"This Budget has certainly shifted the agenda with a balance of politics and economics that provides a stimulus to the economy while making much needed changes to the welfare system and continuing to tackle the deficit.
Businesses will welcome the new permanent Annual Investment Allowance, further Corporation Tax reductions and lower National Insurance, as well as commitments to childcare and higher education that help them employ Britain's best."
Commenting on specific measures he adds:
National Living Wage/Minimum Wage
"This, combined with the welfare changes, shows a real move from welfare payments to payments for economic activity - increasing the motivation to work and rewarding work.
There is of course a real concern about the cost to businesses, and particularly SMEs. What makes it more palatable to business are the changes to Employers' National Insurance and to Corporation Tax.
It's difficult to take a global position on the impact as the combination of changes will have differing impacts on different businesses. And there is a need to follow on evidence based approach and minimise the impact on smaller businesses in particular.
It is a concern that there's an acknowledgement of 60,000 jobs expected to go, possibly mitigated to an extent by NI and taxation changes. While many more jobs are expected to be created these won't be in the same businesses, and businesses may well be lost, while new jobs created may not be in the same geographic areas or available to those losing out. A poorly paid job is still a job after all."
Apprenticeship Levy
"This is good news, with businesses positively rewarded for employing apprentices. The challenge is how the money will flow - which we have yet to see. It's to be hoped that there will not be an over bureaucratic system that doesn't work for smaller businesses."
Northern Powerhouse, Devolution of Powers and Enterprise Zones
"It will be interesting to find out more about the plans with Cornwall and how Cumbria could potentially benefit from similar moves.
We note the reference to the new enterprise zones and hope to see announcement of an Enterprise Zone for Carlisle soon!"
Annual Investment Allowance
"Making the £200k allowance permanent is really good news which should have a real impact on investment and productivity."
Corporation Tax
"Again this is good news for business. It will mean more money left in the business to make the business flow and to invest and sends out a tremendous message to the world that Britain is open for business."
Road Tax
"It's good to see that this is finally being tackled, restructuring an income source that was diminishing, and to see the commitment to spending that income on roads. We need to make sure that we see enough of this spend coming through here in Cumbria."

Our first ten years

A little over ten years ago I was in my thirteenth year of working as an IT freelancer. I'd worked in all sorts of roles - developer, systems analyst, test manager, project manager - during that time, for a variety of blue-chip companies. I'd also been running a hobby company, Meantime Internet Technologies, since 1996.

In the summer of 2004, I was working on a project for JPMorganChase, based in New York. I'd fly out to New York once every few weeks but for the most part I was working from my home office. My youngest daughter had just been born, we were doing the house up and life was good. And then one of Meantime's clients asked me to do a large project for them.

It was a tremendous opportunity, the chance I'd been waiting for, to give up the day job and run Meantime as a 'proper' company. In my excitement, what I didn't think about was the fact that I had no experience of running a real business, as opposed to the limited company that was my vehicle for freelancing.

So, in October, when my contract with JPMC came to an end, I declined their offer of a renewal and started to work for myself. At this stage, I'd already hired Steve to do the coding and the next step was to rent some office space, which we did, just next door where we are today. Pretty soon there were four of us working on the project and I found that I was enjoying myself hugely, doing things the way I knew they should be done, and watching the software take shape and come to life.

But alongside that pleasure in doing the work, I had the first inklings of the issues that go with running a business, not least the significant issue of finding more work and new clients. By the summer of 2006, I found myself waking in the middle of the night and lying there, worrying, unable to get back to sleep.

A difficult couple of years followed. We did pick up work, although there were some lean times, too, but we also learned the hard way about the difficulty of recruiting people who saw business the way that we did, people who cared about doing things to a high standard, for whom putting the customer first was second nature. So, people came and went but, crucially, the good ones stayed. And somewhere along the way, we seemed to get the hang of recruiting, because we haven't put a foot wrong for several years, up to and hopefully including our latest recruit, Adam.

I've been thinking recently about what I've learned along the way and I think it boils down to two things. Firstly, do what you know to be right, even when it means making a loss. You can't keep making a loss, of course, but meeting the expectations both of your client and yourself is the most important outcome of any project. (If you can't make a profit while doing that, then your pricing structure is wrong.)
Secondly, you need the right people around you. Both Steve and Hannelie have been with me right from the start and Meantime wouldn't be the company it is, today, without them. But it feels like Lou and Martin have been there almost as long and they've helped set that standard for everyone whose joined and stayed subsequently. What we've built over the last ten years is a culture that revolves around our four Cs: Clients, Code, Colleagues and Company.

It hasn't always been easy - God knows I've had to learn an awful lot along the way - but looking back over the last ten years, I'm incredibly proud of what we've achieved as a team. There have been problems, of course - you can't avoid them - but, crucially, we've always put them right. And we've shown what I've always believed to be true, that software can be delivered to specification, on time and on budget.

But I've also learned how much fun you can have along the way, and that's down to both my colleagues and clients. Because of them, I can really enjoy my work. So, thank you to all our clients, and thank you Steve, Hannelie, Louise, Martin, Danny, Paul, Jack, and Ronald, and welcome aboard Adam. Onwards and upwards!

Would you like to work with us?

Last June I wrote (here) about some of the qualities that go to make up a good developer. It's taken us a while to get here to the point where we have the best development team I've ever worked with but now it's time to recruit again.

Why "but", you might ask? Meantime's thriving and this is an opportunity to grow the company: surely this is something to be excited about?! Well, yes, but also hmmm...

It's tricky to find good developers. There are a lot of people out there who can write code and a lot of them can write quite good code but we need people who can write excellent code. And that doesn't mean fancy or complicated, it means code that works, that does what it was intended to do and that is written in a way that other people can pick up and work with.

And we need someone to fit in with our team. They are, as you might expect, great developers with specialisms in a range of areas but they're also a cracking bunch of people to work with. When I've been away, I always love coming back to the office, catching up with people, listening to the jokes and stories.

But we're looking to expand the family now and we need someone who can join us and feel at home. So while you'll get an incisive technical interview from Steve and you'll need to talk to me about the importance of change management, testing, user interfaces and a whole lot more, you'll also find that we'll spend a lot of time listening, so we can learn about you. That's you as a person, not a walking set of IT skills.

Many of our colleagues have been with Meantime for years and we hope that anyone who joins us will be with us for a long time, too.

So, if you're friendly, cheerful, happy working in a team AND you're a web developer, why not get in touch with us?

Return of the mini

Apple vs Microsoft, Mac OS vs Windows, Mac vs.... what? Well, pretty much any appropriate collection of components, actually. 

Whereas Apple have always been able to write their software knowing the target hardware quite precisely, Windows runs on what is, too all intents and purposes, an infinite variety of machines. 

But Microsoft has always been lousy at promoting its real strengths. I mean, they don't write their adverts, they buy a company in to do it for them, yet their campaigns are still rubbish compared with Apple's. Just look their (slightly unsettling) "we built a shop in your front room" advert compared with Apple's well-written "I'm a Mac"/"And I'm a PC" campaign. (Amusing enough to distract anyone from mentioning Apple's underlying assumption that being short-sighted, overweight and middle-aged were all attributes that made you uncool.)

I don't think I've ever thought Microsoft was a wonderful company but in the face of the Apple Fanboys' evangelism I've often found myself provoked into arguing its case against Apple's. That hasn't stopped me buying Apple products: I *love* my iPod, although I wouldn't buy another iPhone, having fallen once for Apple's assumption that their consumers will upgrade their hardware to keep up with their amazing software developments (and I DON'T mean that sarcastically). 

Indeed, I was amazed when less than a year after releasing the first iPhone, Apple had the effrontery to market the second model as "The iPhone you've been waiting for". (Cue Apple Fanboys everywhere: "This is the 'phone I've been waiting for. These are not the 'droids we're looking for.")

And then Windows 8. 

I don't like it. At first I thought I just needed to adapt to the new interface but, months on, I really find it irritating still. So, I've bought a Mac Mini, which I'm going to trial at home first, and today I unpacked it. I love an "unboxing" and it has to be said that Apple's packaging is another area in which they seem to operate with unfailing style. 

Actually, I ran a Mac Mini at home a few years ago but the operating system has moved on considerably since then: I understand that I am now running 'Mavericks' (which I think I'd feel a bit awkward saying out loud). I must say I'm enjoying it so far but I always enjoy setting things up (even Ubuntu!). But, to be honest, my only real reservation is the Apple crowd thinking they've 'won'. Hey, I'm am MAD about Office365 :-)

What makes a good developer?

Quite often when I talk to people about IT development, how projects should be run in order for them to be successful, I use building as an analogy. Let's say you wanted an extension on your house or even a new house. First of all, you'd have to have a think about what you wanted and then you'd probably talk to an architect. The architect will listen to your requirements, perhaps set you straight on a couple of ideas and possibly make a couple of suggestions of her or his own. This is analogous to the stage of an IT project when we first engage with a client and make our proposal.

At some point more detailed plans are required - showing, perhaps, where the outflow pipe from your jacuzzi will run - and this is equivalent to our systems design, the specification that is written by a systems analyst. This stage of the process, which I wrote about a few months ago, is critical to the success of the project. It details our understanding of what the client has requested and we won't start work until that document has been signed off.

So far, so good. We've reached this stage by talking to the client, starting in broad conceptual terms, then getting into more detail and ultimately documenting the project to the point where they can say "Yes, that is exactly what I want. Build it!" On our side, we will have worked out precisely what's involved so that we can give an accurate quote for the work and, crucially, plan the work into our schedules so that we can tell our client precisely when the work will be delivered. It is this process that is a key part in making good on our promise to deliver IT systems on time, on budget and to spec.

It is at this point, then, that the developer gets involved and, if you're not careful, this is where it can all go horribly wrong. You see, being a good developer is about so much more than being able to write code. In fact, in some ways, that's the most trivial part. When we interview for developers at Meantime, we assume they can write code or why else would they be coming for a job with us? (Which isn't to say that they don't get a thorough technical interview from Steve!) The qualities that we're looking for before we employ someone are a little harder to pin down. But I've been in IT for 25 years now and I have met an enormous number of developers, and in this post I'm going to detail some of the things that I think contribute to making a good developer.

One of the most important qualities is sense of place within both the team and the business. One of the worst developers I've ever worked with described himself, without irony, as "the talent". A good developer recognises that he or she is part of the project lifecycle. They appreciate the work that has taken place before a project reached their desk and also respect that work. A developer who thinks they know better than their colleagues or even the client, is not going to deliver what has been promised to the client.

And this sense of place should come from having empathy, which in turn should lead to some serious consideration about what the end users' experience of the software will be. Using good software should be like reading a good book; you should be barely aware that you're doing it. It should be intuitive and responsive. In fact, it is this consideration that has made Apple's products so successful over the years and which is the major flaw with Windows 8. A good developer will put himself in the users' shoes, thinking how will they know what to do, how can I help them through the process and how will I let them know when they've finished? As I've said elsewhere on this blog, the user interface is 5% of what the developer does but 100% of what the user sees.

A good developer will also be a team player. That's a hackneyed term, I know, but it's a useful one. In many ways this is an extension of my first point but a good developer will work well in a team in several respects. Their code will be well laid out and well commented in order to assist any developer who comes to amend it later on. They will respect the change control process, such that their work doesn't overwrite anyone else's - so this is that sense of place, again - and they will understand where they fit into a project, respecting what their colleagues are doing. A good developer will be happy to share knowledge and enjoy teaching. (Conversely, a bad developer won't share information.) A good developer will also take feedback - whether it's from the testing team or from the client - in a constructive way, understanding that it is a contribution to the process.

So that sense of being a team player also extends out to the people in the company who aren't developers and out to the client too, because any project is a team effort that involves the client. I'm always warmed listening to Meantime developers talking to clients, being friendly and helpful. And that sense of being a team player also manifests itself in making the brews!

Perhaps one of the more specific characteristics that I believe goes to make a good developer is finishing. That sounds a bit odd but you'd be amazed how many developers don't finish. I think this comes sometimes from not being clear about what they're required to do (which is why a good spec is required) or perhaps just because they can't stop tinkering! Over the years I've seen many a developer convince themselves that they have nearly finished a piece of work, only for it to run on and on. And these developers also seem to end up with more bugs being raised against their work. An understanding of what a piece of work consists of is essential to being able to plan it and also to knowing when it's done.

This list may not be exhaustive, but there is only one final pair of characteristics I want to mention: enthusiasm and enjoyment, and I think these are probably two sides of the same coin. I can think of countless times over the years when our technical director Steve has shown me a piece of work that he's pleased with and even this month he has surprised me with a beautiful little piece of a user interface. Simply beautiful. Readers of our newsletter and our followers on Twitter will be aware of Paul's brilliant work in turning a Raspberry Pi into our office Jukebox. You might think that building web pages is just about laying elements out on a page but, in addition to being a great designer, Lou soaks up HTML5, CSS3, W3C compliance and DDA with an appetite that never fails to impress me. The evidence is there in the tens of thousands of lines of code that Danny has written for one of our largest projects and, most rewardingly for me, in the stunning progress that our junior developer, Jack, has made: he's now working on live projects and that's months ahead of what I expected.

There are other people who make a huge contribution to Meantime's success, none of whom I would be without, but this post is about the developers and, as I think you can probably tell, I'm delighted by the team that we have. A bad developer is like a bad builder; they leave you with disappointing results that can cause you problems for a long time after the job should have been finished. It may be obvious to say that to have a successful IT project you need good developers but there is a further point here: you need a good team. This is why I'm strongly against outsourcing and off-shoring because that team should include the client, too. Recently, the sponsors of a project we're doing at Heathrow asked whether the developers on the project would like to come down to visit. More than anything else, that told me that Meantime has great developers who do a lot more for the business than just writing code.

Banking on failure

Over ten years ago I was working for a Major Retail Bank (MRB) and I was responsible for testing their first fully online Internet banking application. I had two teams of around twenty people, one in London for a sister bank and one at head office in what, at times, felt like the Arctic circle.

We had cabinet upon cabinet of manually completed test scripts as well as automated text tools checking the less popular browsers. In each location I had two or three test coordinators running the teams on an operational basis and I had an excellent boss, Cameron Mealyou, supporting me strategically. With all this in place, we delivered very high quality testing and the live launch went without a hitch.

A short time later, a minor amendment was required to the software, effectively a change to some help text. Perhaps on another, lower profiled project I might have agreed to some localised testing but this was an Internet banking system; we couldn't afford a single incident to undermine customer confidence. Thus, I proposed a full regression test, employing the full test team for a week, thereby causing a week's slippage to the delivery of the next release.

This suggestion proved to be unpopular with the programme manager and matters became heated. Having stated my case once I couldn't see the point in labouring the point, so I told the PM he was welcome to over-rule me but that I wouldn't sign off the change as tested. I think it was pretty clear that overruling me would have made my position untenable and he reluctantly agreed to the test.

The testing produced three significant bugs.

When the bugs had been corrected and the release was live, I was in the pub with the development manager, I nice chap called Neil. After a couple a beers, he said to me "You couldn't possibly have known those bugs were there." Which is an odd thing to say, isn't it? We don't test because we know there are bugs, we test in case there are (although that is usually the case).

A few months later I moved on to a new contract. I was told the test teams would be wound down "because we never have any bugs in the live environment." This is like saying "I think I'll stop exercising because I never have any problems with my fitness"!

I've been reminded of this a few times recently when I've encountered problems with my bank's banking software and also because of the high profile issues that have been reported in the press. These problems point - undeniably - to a lack of testing.

And it's not that testing is particularly complicated. It's mostly a combination of common sense, rigour and a conscientious approach (rather well suited to those who are a little OCD). It is, however, pretty expensive: there's a lot of preparation involved and the process itself is time-consuming. On many occasions I saw a project manager attempt to cut testing time in order to hit a deadline and this is a classic reason for bug-ridden live releases.

So, my message to the banks is: stop scrimping on the testing and support your test managers.

Systems analysis: the neglected step in the journey.

When I was first working in IT, I was used to coding from a specification. I was so busy struggling with Cobol, JCL and DL/1 - yes, I'm that old! - that I didn't stop to think about where these specs came from.

A couple of years later I was working for VSEL amending some programs (as we called them in those days) and having been told what we needed to do, we'd look at the existing code and the database and work out what to do, often coding as we went.

It was only on my first contract that I began to see a better way of doing things. There were some people on the development team who didn't write code but whose job was to write these specification documents that I remembered from my first job. We all sat in one open plan office and each developer worked with one systems analyst.

I found this tremendously interesting, especially as I began to get a say in how the programmes might work,  and over the course of my next couple of contracts I made the transition from developer to systems analyst.

At this point, you might well be saying to yourself "this is all very well but what's a systems analyst?"

Good question.

The business analyst collects the business requirements. So, for example, a new system might track books in and out of a library and each card holder is allowed to have three books at any one time for up to a fortnight. That's a nice simple piece of business analysis.

The systems analyst, though, has to design the system, the database and the logic. It's the systems analyst who will typically find the gaps in the business analyst's documentation, sending them scurrying to the client with questions like "but what happens when the card holder has had a book for a fortnight?"

It is this final specification that the developer will code from and, whilst the developer has some leeway in exactly what they build, it is that specification written by the systems analyst that determines what will be tested. The programme should do what the specification says and no more.

Of course, this additional step appears to be very time-consuming and it is but, as is so often the case when a company does things properly, it pays dividends. The approach that simply sets the developer coding with a bunch of requirements often means that the developer will get halfway through before realising that he needs to go back and change something he's already written. It means that the client isn't suddenly presented with quite fundamental questions during the build process, which may be a little unnerving. And, in a constructive way, it presents a contract between the analyst and developer, who have agreed what is being built. If the requirements change and the spec needs amending, the developer can very reasonably ask for more time.

Furthermore, the specification forms an excellent basis for system testing, as it details precisely what the system is supposed to do.

As a business, Meantime prides itself on delivering on time, on budget and to specification. The systems analyst's role is key in helping us to keep this promise to our clients.

The important art of business analysis

"Hello. Is that the garage?"
"Yes, it is. Good morning. How can I help you?"
"I'd like to buy a car, please?"
"Great. We'd certainly be pleased to help you with that!"
"Oh good. Can you tell me how much it will cost?"
"Er..."

Well, OBVIOUSLY, you wouldn't go into buying a car like that (although I have in the past wished that you could!).

Of course, what you would actually do is tell the garage your requirements. Some of those might be quite specific: you might want a diesel engine or a sunroof. You might also provide a bit of background information, such as the fact that you have three children. This will give the salesperson an opportunity to add some value, as he (or she) might ask, for example, whether you want rear doors with childproof locks on them. And, of course, no sale would be complete without an attempt to sell you a few bits and pieces that aren't strictly necessary, like alloy wheels.

I'm mentioning all this because this current instalment in why IT projects fail concerns the Business Analysis stage. Now this isn't strictly sales - that's where my analogy breaks down - but a good business analyst will collect information not only about your specific requirements but also your business.

This enables the analyst to do three things: firstly to contextualise your requirements. Secondly to bring their experience of similar companies and projects to bear and thereby add value. And, thirdly, to ensure that the development fits in with your requirements strategically. After all, there's no point in buying a five-seater if your family is expecting a fourth child!

So, a business analyst needs to be a good listener. They need to ask you about your business, where it's come from, what it's doing now and where it's heading. The analyst needs to understand what systems the company uses now and whether any new software will be required to integrate with them.

Next the business analyst needs to listen to your requirements, using their experience to understand whether what you're asking for matches your stated intentions. Here their experience of other projects and companies will be of value, possibly preventing you from making mistakes and helping you to benefit from the experiences of other people.

The business analyst should also be able to make suggestions about what other options you might want to consider doing that aren't currently part of your plans. The cross-pollination of ideas across sectors is not always obvious but a good analyst will be able to spot them.

Once you have had this meeting - or possibly meetings - the business analyst should provide you with a business requirements document, which should detail the scope of the project and the requirements that you want satisfied, whilst also recording any discussions around future development. The document might include some design work but, really, it should be a summary of your business requirements.

Once you've approved this document, the company for whom the business analyst works should be able to give you a reasonably accurate estimated cost for the work. However, I wouldn't expect them to quote for the project until the more detailed analysis is complete and it wouldn't be unreasonable for their company to expect you to pay for this detailed ("systems") analysis, which will take days or even weeks. Next time I'll write about systems analysis and that stage of the project.

I think it should be fairly clear from what I've written here just what the issues are that might arise if the business analysis is not done properly; a client who ends up with a system that is not right for their business.

Scoping your IT project.

Wow! It's been a while since I was last here. Happy New Year! The last six months have flown by as we've acquired new projects, clients and colleagues. Plus, as readers of our newsletter will know, we've spent the first three months of this year rationalising our servers onto a single cloud-based platform. This has been an enormous undertaking and I'm absolutely delighted by its success, which was managed with absolute minimum disruption to our clients.

But in my last post I was starting a series of posts about why large IT projects fail. I had originally written a list of all the items I want to cover and this had gone missing. After I started sketching out this post I found it again and I was pleased to see I'd been consistent in what I see as the first thing to consider, and that is scope.

When I'm talking about IT or trying to explain it to non-technical folk, I often find that talking about building is a good analogy. So, let's imagine that you're going to build an extension for a new kitchen.

First of all, you need to consider the rest of your house. You might not be doing any work there but there's plumbing and electricity to consider, and the stresses on the existing infrastructure. This, then, is not the time to discuss whether the bathroom needs renovating although if that's being done at the same time, you need to make sure you aren't moving a pipe that you're planning to feed into the kitchen.

Similarly, then, for your new project, before you start talking about what it needs to do, what constraints are there? If it has to exchange information with other systems, how will that work? Have you checked whether those other systems have their own changes planned?

Next, focus on the essentials. What needs to to be done in this initial project? It might be sensible to defer considerations such as floor tiles, painting and decorating, and kitchen furniture. Sure, the kitchen might not be usable until these are in place but putting those to one side, you can focus on a manageable amount of work that is quite different in its nature. Your joiner is unlikely to want to sit in on a conversation about Italian tiles.

So, for your IT project, look at what needs to be achieved. Yes, you might want a letter printing facility but that's academic if your client data isn't right. Of course, you want to know that that will be a requirement at some point - you want to bear these things in mind - but for now you need to focus on the core deliverable. This enables you to keep your team smaller, which facilitates communication and eases change management. It also means you are less vulnerable to changes in requirements - you have a smaller target - and when those do arise, impact analysis is simpler.

Once you have reached this point, you can start getting into the detail of what you're building. Even on a project that has been scoped carefully, it's astounding how much there is to be done once you get into the detail. I think this is where a lot of big projects go wrong: a sensibly scoped project can look a bit unambitious, a bit limited in what it's delivering, so people think they might as well do a bit more while they're at it. Once you get into the detail., it's suddenly unmanageable. In 2004 I was on a project based in New York that was on a three month delivery cycle yet consistently failing to deliver. Really, all I did was cut the scope right back. There was a certain amount of scorn on the project, not least from the development team, who, I seem to remember, thought we could do it all in two weeks. We did it just in time for the next release date. We repeated the process twice more and, when I finished we had a successfully delivering project and a happy user community. It wasn't rocket science.

One final consideration. In our example, we're building a new kitchen but when that's done, we'll need to move all the kitchenware across from the old one. And we need to make sure there's room for that large steam-punk coffee machine. In system terms, I'm talking about data migration. You need to ensure the new system can handle your existing data and have a plan in place for moving it across. And rehearse that process, too. The worst project I ever worked on hadn't rehearsed its data migration. With a new system going live on the Monday, they kicked off the data migration on Friday night. By Sunday afternoon, only half the data had moved across. Rather than aborting, Monday saw this telecommunications company based in Britain with half its accounts on one system and half on the other. It was a disaster, operationally and from a PR perspective.

That's my guide to scoping then. Think about the big picture, don't be over ambitious. Simple, eh?

Why do large IT projects fail?

One way or another, pretty much everything I’ve done and written about for the last few years has been based on a single premise and that is that IT can be done well and that projects can be delivered to specification, on time and on budget.

Delivering websites and IT systems via a small business has only emphasised – quite painfully at times – the thoughts and experience I had gained over the previous fourteen years working freelance on blue chip IT projects.

Broadly speaking, there are two reasons IT projects fail. One of those reasons is the people working on the project and the other is the way in which the project is organised and run. Many of my subsequent posts will be about the latter but, just briefly, I’d like to touch on the former.

I’ve been in IT for twenty-three years now and every successful project I’ve worked on has had a high proportion of The Right People. The most successful project I’ve worked on was exclusively staffed by people of that calibre.

At Meantime, we have struggled with recruitment. This is partly down to where we are based – the one downside of having our office in the Lake District – and partly down to the fact that IT is not a proper profession. There are no widely accepted formal qualifications – particularly around systems development – and so recruitment rests on the shaky platform of CVs and interviews.

Over the years we have always recruited with optimism and looked to bring out the best in people and, at times, we have been badly let down. We’ve now settled on a recruitment formula, which is as follows: I interview the candidate and Steve, our lead developer, gives them a technical interview. (Steve is also a pretty shrewd judge of character.) If we both like them and, crucially, even if they are not technically quite up to scratch, we ask them to carry out an online psychometric questionnaire, which is followed up by an interview with a trained assessor. We then receive a report and, whatever, the outcome, carry out a third interview.

As you can tell, just from that brief description, it’s a laborious and expensive process. However, experience has shown us that it’s far more cost effective to go down this route than to put the wrong person onto a project, given the long term damage this can do.

I’ll illustrate this point with one brief example. Several years ago we did a project that involved classes and terms. The developer in question, let’s call him Paul, was given a data model to work from and was walked through the use of that data model. At the time, he queried the way terms and classes were related and the database structure and process were explained in detail.

In the end, however, and without consulting any of his colleagues, Paul decided to do the work the way he thought best. The project went into user acceptance test and, as we moved towards the first change in term, it became apparent that Paul’s solution wouldn’t work. I don’t know whether Paul had realised this earlier, certainly he handed in his notice around the time the issue became apparent and left his ex-colleagues to put things right.

You can imagine the stress this put on the company. The issue was not the client’s fault, so there was no extra funding, and we had other projects in progress. Being a small business, we didn’t have any spare staff, so Steve, myself and another colleague, Mary, worked extra hours to turn this around.

The issue here was not so much that Paul had coded the solution wrongly, it was that he decided he knew better than the person (me!) who had talked to the client and written the specification. Even then, the problem was not so much that Paul had his own opinion, it was that he didn’t discuss his intention with anyone.

These days we recruit people whom our interviews and the psychometric test identify as team players, people with empathy for our clients, who want to deliver the best solution for them. Following this method, we’ve employed people who didn’t have our skill set or the right experience, who have turned out to make a brilliant contribution to our team. Ultimately, you can teach people skills and give them experience, what you can’t do – at least, not very easily – is change their nature.

OK, so that was a little less brief than I intended and the calibre of the people contributing to projects will certainly crop up again in my following blogs, but the point I’m making is that all of the other things I’m going to write about, those things that contribute to a project’s success, will not work without the right people.

Despite what they say, recruitment agencies don’t filter candidates, except in the very broadest terms. If a candidate’s skillset matches the job requirements, the agency will forward the CV. Many claim to have interviewed clients and given the percentages that agencies demand, one would expect they have spent serious time vetting them. However, in my experience at least, that is simply not the case.

It’s not enough to like someone at interview or to hire them because they pass a technical interview. For a project to succeed you need people who are team players, people who care about a project’s success, people who want to make your clients happy.

Last weekend, we carried out a data migration. Without being asked, the developer involved emailed me to say he’d be available if needed over the weekend and another colleague, who wasn’t directly involved, rang me over the weekend to check everything had gone to plan. When people take this level of interest, when they care about the outcomes, when people like this are working for you, then, with the right process and organisation, you can deliver successful IT projects.

User interface: The 5% that's really 100%

We have a saying in our office, which is that the interface is only 5% of what we do but 100% of what the user sees. To be more accurate, it's usually me who says it, typically to a background chorus of grinding teeth. This is not to say that the rest of the team don't care about the user experience, but when, for example, you've just coded a complex administration function to enable to a client to set up their own algorithms for customer discounts, you're probably expecting a bit of praise and congratulation, and not someone scratching his head and asking whether the submit button shouldn't be a bit further up the screen. (There's a lesson for me, there.)

However, there are two very good reasons for thinking about the user and the interface that they will use.

Firstly, if you've built a system, then you want people to use it and there are four key components to giving them an experience they will be happy to repeat.

1. Visual appeal: People make very rapid, non-intellectual decisions about websites that they are presented with. If the screen is cluttered or badly rendered, the user is already less inclined to engage with it. Screen design is hugely important; it makes the system look like it will work.

2. Guidance: if your user has to study your screen to work out where to start, then you've already failed. It should be clear to the user what they need to do first or what their options are. Positioning the cursor for them, big, clearly labelled buttons, numbering steps: these all go a long way to giving the user the 'no brainer' experience that they want. And a little onscreen text is a simple, cheap way to help the user to understand what's required of them and what's going on.

3. Feedback. Our local tourism board has a purchasing system that it allows some attractions to use. Booking tickets for a show, I selected the number I wanted and clicked add to basket. Nothing happened so I tried again, twice more. Still nothing. So I went to the checkout only to find I had enough tickets in my basket to take most of the people living on my street to the theatre with me. I think the message here is clear; when the user completes an action, let them know it's done!

4. Deference. With software, you can, of course, force users into doing things by preventing them from proceeding if they don't do what they're told. However, this may not give you the results you want. It's all very well collecting, for example, marketing information from your users but if you force them to enter a date of birth, you may find they enter something completely random, thereby skewing your data. In a similar vein, an e-commerce site lost my business this week when they deemed my nine-character-with-a-numeric password to be not strong enough for their standards. Don't throw your weight around: give your users what they want and need, and if you want something from them, ask don't demand.

Secondly, there is a very selfish reason for helping your user to have a good experience with the software you build; fewer support calls. If people need to use the software - let's say it's for a timesheeting system - then if they can't do what they need to do, they're going to call. And, people being people, they probably won't read lengthy help text or instruction guides: they'll give up or pick up the 'phone. One way or another, that will come back to the software provider.

Usability, particularly the second point, can be tested easily during your User Acceptance Testing (UAT). The client knows what they want the system to do, the software provider has built that system. Leaving the client to test the system without initial guidance from the provider puts the client in the same shoes as the user. If the client can't get from A to B or product to checkout without guidance from the software provider, what chance has the user got, when they come to the website or software completely cold?

Usability is about empathy, putting yourself in the user's shoes: put the little bit of effort into giving them some guidance through your design and text, and you'll have happy users and a quiet help desk.

Security: it's not rocket science

This morning the news broke that Sony has announced that hackers have stolen the details of millions of online video gamers. The Telegraph's report can be seen here. The data includes user names, passwords and, possibly, credit card details.

I'm surprised by this for two reasons. Firstly, the fact that Sony were successfully hacked at all. God knows there are some very, very clever (if misguided) people out there involved in hacking. Anecdotally, a couple of times a year we see evidence of people attempting to hack our servers and we work hard to stay on top of our security. But we're not Sony. Surely a company as wealthy as Sony, responsible for the details of millions of people, should be employing the very best people - really: the very best - to safeguard their systems? The fact that they were breached suggests to me that they are not taking their security seriously enough.

However, the greater part of the surprise, for me, is that it seems store their data in an unencrypted state. I've blogged about this before but for all the times that disks go missing in the post, laptops are stolen or security is breached, no spokesman ever says "but it's OK because the data was all encrypted".

For our most secure data we use a combination of the encryption algorithms built into the database software but also some bespoke algorithms of our own. Thus, even someone with open access to our database couldn't interpret the information that is stored. I don't think we've done anything mind-boggling there; I'm sure most IT companies worth their salt would come up with a similar solution given the same requirement for data security, which just makes me wonder why Sony didn't.

Incidentally, if you have data that you want to encrypt, either on your hard drive or portable data device, I highly recommend TrueCrypt. It's very simple to use and very secure.

Working under stress

A couple of years ago, I received a panicky 'phone call from a friend. The company he worked for had been mentioned, along with their website address, on the front page of The Telegraph. The site had started to load more and more slowly, and now it wouldn't load at all. I asked him who'd built the site and where it was hosted. It transpired the site had been built by a man who was away and, consequently, couldn't be contacted. After a little investigation we located the hosting on one of those £50 a year servers. Of course, there was nothing we could do to help and the exposure in The Telegraph was largely wasted.

I was reminded of this by three occurrences in the last month, concerning Twitter, the BBC and Premier Inn. Twitter users will be well accustomed to the application's occasionally flaky service. We don't pay for it, we use it frequently, and we get all sarky when it can't take the very high strain.

On March 29th the BBC website and related services (such as iPlayer) were unavailable. The final explanation given was that there had been a major network problem.

Finally, Premier Inns recently broadcast an email campaign offering their popular rooms for £19 offer. (Popular but elusive; I've never been able to find one.) This was followed days later by another email apologising that the website hadn't been able to cope with all the resulting traffic.

Superficially, these all look like the same issue but, in fact, there are a couple of factors to consider. Firstly, there is normal load. Whether you are talking about a website or an application or any other aspect of your online infrastructure, you need to think about how many users you will have, how often they will use your service and what resources they will use. For example, if you have a popular website that is largely text and pictures, then you simply need a server that is good at spitting out web pages. However, if you are Premier Inn, where your users are accessing a database and using up processing power, then you have more factors to take into consideration.

Secondly, there is the question of 'spikes', i.e. sudden load on your server and infrastructure. These spikes can be quite dramatic compared with normal usage. You might be an online clothes retailer, advertising that your 30% off sale starts at 9am on Monday. Your set up is going to have to cope with something quite different to the normal steady usage of people browsing and purchasing.

Of course, you shouldn't wait until your site is live to consider these issues and you certainly don't want to find out about them on the day of the sale you've spent so much time and effort promoting. But you'd be surprised by how many people don't consider them. I can count on the fingers of one hand the clients who have raised this as a concern with me before I have had a chance to discuss it with them. And that's fair enough. Clients assume that their suppliers are thinking about these things on their behalf.

However, as with so many other topics - like security, DDA, cross-browser testing - the IT industry repeatedly lets its clients down. There are few professional qualifications and anyone with a PC can set themselves up as a web designer or developer. Consequently, it does fall to the client to ask the questions, not to assume that, having paid for the development of their site or application, it will run on machines that are adequate to support its usage.

Lush and PCI Compliancy

"I can't believe that a company of this size can be so naive about website security".

The above quote (from a post by 'symball') is taken from an article in today's Guardian about the hacking of the website belonging to Lush Cosmetics. The company have known since at least Christmas Day that they were being hacked and it has now admitted that the hacking dates back to October last year. Customers are reporting that their cards have been used fraudulently.

The sad truth, though, is that that online security is poorly understood and badly enforced. Whilst any company trading online should be PCI compliant the truth is that many online traders are simply unaware of this requirement and many web development companies, particularly those with a strong design or marketing bias, don't have the technical skills to set up a site that is compliant. Certainly, the company working for Lush should have known better to hold onto card details.

However, the problem here is not just about PCI Compliancy. We have had numerous hacking attempts on our webservers over the years and we have a full time systems administrator who keeps our boxes up to date with the latest security patches precisely to keep hackers out. All too often, though, less technical web development companies rely on their hosting company for their security and this simply isn't good enough.

We have 'inherited' websites in the past and had the difficult job of explaining to the client just how much work needs to be done to their site before we can put it onto one of our live boxes. Similarly, we have in the past, (reluctantly) lost clients who were not interested in the ongoing costs of maintaining the security, both through the necessary hosting charges (to constantly review and maintain server security) and the cost of keeping up with the constant changes to PCI Compliance.

If your business sells online, you need to check with your web developers about your PCI compliance and your server security. If you are unsure, then contact a company such as Security Metrics who can do both PCI checks and 'penetration testing'.

And if you are storing your customers' credit card numbers, I would start worrying about this RIGHT NOW.

Why I walked out.

It's been a busy couple of months. A new project with a client that I can't yet name, which is the hugely satisfying culmination of six years' hard work, not to mention new lessons learned about the need to project manage clients during large scale developments with staggered code deployments. I know I've neglected the blog - just the sort of scenario I warn blogging clients about - but I've had two or three topics I want to blog about knocking around my head and I've been looking forward to having the time to put them into writing.

However, this evening I want to use the blog for a different reason, which is partly by way of explanation of my sudden exit from an event I attended, this evening. The event was called 'Beyond Websites - Using Web Technology Creatively'. I must admit I was slightly dubious about the title, which seemed to offer two different topics but, with the advent of HTML 5, I had little doubt this would be an interesting couple of hours, with a presentation from Keith Mitchell (@specialized), a Research Fellow at Lancaster University, and then a panel discussion.

The presentation was entertaining but a little disappointing, mostly concerned with watching television over the web. There was some talk of community clouds - effectively caching programmes - which I believe will be rapidly superseded by the rollout of more powerful comms and - as the lady from Business Link pointed out - better compression algorithms, anyway, and there was also a demo of some software that would enable the user to watch television whilst viewing a clickable television guide and relevant feeds from Twitter and Facebook, which struck me as reactive rather than innovative development. Certainly I wouldn't have described it as a creative use of web technology.

The panel discussion was a further let down. There was some talk about existing websites, particularly Vimeo, some paranoia about Google claiming copyright to any documents placed on Google Docs (take a *closer* look at the T&Cs) and then some discussion about targeting content, with specific mention of 'Googlezon' from "Epic 2015" (2014, in fact).

So, why the hissy fit, albeit in the relatively middle-class form of walking out?

Well, I won't pretend it was because the session didn't live up to its name (although more on this in a bit). I'm as happy as the next (nerdy) guy to spend an evening talking about the web/Internet and guessing at where it's heading. I would have had no problem with that. There are two overlapping elements to evenings such as this one that really get my goat. The first is a rather smug assumption that we're at the forefront of a cultural movement, i.e. that what we're doing today is what everyone else will be experiencing tomorrow. The second is the weak recycling of common 'wisdom' regarding the web, what's cool and where it's "definitely" going to go wrong.

So, just because we use Twitter and blog, doesn't mean everyone is going to. Indeed, I'd argue that the very fact that we are entrepreneurs working in design, marketing and new media means we are exactly the kind of self-aggrandising/outgoing folk who will engage in these activities. Does it mean other people won't? Of course not. Be just because we *all* do, doesn't mean *everyone* else will.

Similarly, it wasn't true to say that everyone spends more time online than they do watching television. That may be true of teenagers but when I was a teenager I spent more time in my room reading and listening to music than watching TV. Let's not confuse human behaviour with cultural trends. And as for the ridiculous anecdote about the literature professor who can't read War and Peace since he started using the web... That man is in the minority.

I'd recommend these people read Tim Berners-Lee, Clay Shirky and maybe Brian Eno's insightful 1995 essay on targeted marketing.

So, yes, I got impatient and I have a low boredom threshold and I walked out. But what would have made me stay? Two things, I think.

Firstly, we could have enjoyed some talk about how the way in which we use the Internet has changed. The Internet is a load of computers/servers connected together. Over that, the web was laid, pages of content that joined together and, initially, that was how we used the Internet (and for email and IRC, of course). Now we use the Internet to deliver content to the apps on our smartphones or to 'narrowcast' films to our TVs, and the web part of the general connectivity has become a little less important (although it won't go anywhere in the short-term). We could have usefully talked about how users are accessing data and how we adapt what we do to satisfy their demands. And how we keep that fresh, interesting and, yes, creative.

The second thing that could and should have been different this evening was that we should have talked about the Internet as a huge, interconnected resource, to which people contribute. Web 2.0 as it is now called (and was so referenced as at the start of the evening). Instead we talked about the web - but, really, the Internet - as a mechanism that delivered content to us. We talked about how the content presented to us could be better refined, more targeted. But that isn't the point. The original Web 2.0 - as defined by Tim Berners-Lee - sometimes called the semantic web, was about joining up data, in all its forms (including video). One of the panellists did make a good point this evening (and I must apologise that I can't remember who it was), which was that often we start out looking at one thing on the web and, by following links (and, I'd add, our interests), we find our way to all sorts of different sites, pages and information. This is what excites me about the web; the interconnectivity, the wealth of data, the user content, the real-time commentary on life.

The web, the Internet, whatever you want to call it, is - at the risk of sounding clichéd - a fresh, innovative, exciting space. What excites me is not how I might watch TV over the web or how content might be targeted for my consumption. No. I love being in the middle of a strange town with my smartphone telling me where I am and what's around me. I love being able to map the runs I do and share them with my long-suffering friends. I love the fact I can IM my daughter in Berlin *right now* and chat to her. I love the fact that via apps and pages and any and every other means, we can all access and share films and music and data and opinions and all the other things that constitute the culture that we enjoy. That, I think, is worth talking about and, indeed, celebrating.

What yesterday's problems tell us about Twitter's testing

Those of you who keep an eye on the news - and who don't switch off at the mere mention of Twitter - will probably be aware that Twitter had problems yesterday as users (with development skills) were able to include code in their posts leading to the problems described in The Guardian (here) and The Telegraph (here).

Unsurprisingly, the language used to describe the incident is full of the kind of words that IT people use to keep everyone else at a distance and to spray a little nerd glamour on themselves. But for all the talk of malicious code, worms, onmouseover, hacks and loopholes, the truth of the matter is remarkably straightforward.

So, first, a quick description of how browsers work. When you load a web page, your browser requests HTML (the language in which web pages are written) from the web server and as it receives the code, it uses it to build the page, top down. It's a fundamentally simple process and the browser simply processes each line in turn. So, when a browser displays a page of 'Tweets', the messages are simply part of the HTML. If some other code is included in the HTML for that message, then the browser simply interprets it.

I first came across this as an issue ten years ago when I was leading the testing for RBS's Digital Banking software, their first purely web-based Internet Banking service. I discovered during our early testing that on the page where a user would be able to name their accounts, I could enter basic HTML, which would then affect the way the page was subsequently displayed, once it had been saved.

From then on, every entry field in the website had to be coded in such a way that any characters that might be used to insert code were not permitted. And every test script included tests to ensure that if those characters were used, the data would not be saved to the database. We had a few data input boxes and the testing was time consuming but, of course, it was vitally important that no one could introduce code and make the site work in a way that wasn't intended. These scripts were used to test every release of Digital Banking, even if the changes were in a different part of the system from the data entry.

Twitter has one input box. That's it: one. It might be deployed on one or two different pages but it is the same code, the same function.

So, what does this tell us about Twitter's testing. If it tells us one thing, it tells us it isn't as robust as it should be. It doesn't really matter whether the issue is down to a tester who ticked a box without actually doing a test, an automated script that wasn't run, poorly documented test scripts or a missing process that should confirm that all scripts are complete. This was a bad drop by an organisation that has tens of millions of users and a burgeoning usage by business.

For as long as I have been in IT, testing has been the poor cousin to development, and regarded as an unnecessary headache by developers. IT and project managers must never lose sight of the importance of this stage of IT development: customer and client confidence is easily lost and difficult to regain.

Keeping content accessible and other things *you* should do for your site

There's a lot of things you might ask or even demand from the company that builds your web site. Certainly one of those things is that it should comply with the Disability Discrimination Act but you might also ask for, say a news page and a calendar of events.

But whilst it's very easy to have ideas at that point in proceedings, you should think about your ongoing commitment. There's nothing that makes a site look sadder and neglected than a news box on the front page that hasn't been updated for months or a calendar with nothing on it. It's important to ensure that somebody in your company - or perhaps someone outside it: your copywriter or marketing people - takes responsibility for that content and ensures it is updated regularly and with some care.

However, the main reason for this quick blog is to do with your responsibility for accessibility. Today we are sending out our latest newsletter, which is about accessibility and the DDA. In the newsletter we provide a link to a tool for checking accessibility and, of course, it occurred to us that a sharp client or two might use it to check our sites: our own and the ones we've built.

We were more than a little surprised at first to find some of them failing because we always check our sites for both W3C and DDA compliancy once they're finished. However, on closer inspection, we found that it was the user generated content that was causing the problem and not the code we'd written. That was, of course, a relief but then Louise asked whether we had even spoken to our clients about how to keep their content accessible. Well, that did take the smiles off our faces.

So, from next week, we will be briefing our existing clients on how to make sure that the content they put up is accessible and making sure that it's part of the training for our new ones.

Why the government needn't stick with IE6

One of the features of the web that I initially found exciting was the concept of platform independence. One could build a page in HTML and anyone using any browser on any machine running any operating system would be able to see that page and use it just the way its author intended.

I will pause here to allow the hollow laughter of web developers everywhere to fade to an echo and so not interrupt my thoughts.

The truth of the matter is that over the last fifteen or so years we have had a multitude of browsers that work differently on various platforms and that has made both the development and testing of web pages and applications far more time consuming and, therefore, expensive than necessary. At Meantime we develop in whatever we consider to be the most standards compliant browser at the time and test primarily in whatever is the most popular, and both of these are moving targets.

As you would expect, Microsoft have a major role in the history of browsers but it is a surprisingly chequered history. Bill Gates was famously dismissive of the Internet at the outset and, if memory serves me correctly, it was not until IE4 was released that Microsoft really found their feet in the marketplace. Their success lasted 18 months until early 1999 when IE5 was released.

The extent of IE5's problems can be inferred from the fact that, on this one occasion, Microsoft released an interim version of the browser, IE5.5. And when IE6 came out, it was widely agreed that unhappy IE5 users would have been better waiting for that than 'upgrading' to IE5.5. (I remember all this vividly; I was responsible for the team testing the Royal Bank of Scotland's Internet banking software at the time.)

Of course, all of this made life incredibly torrid for those people in organisations who were responsible for the software and applications architecture. It was a period beset with problems and costs, and this was during the period immediately following the nasty surprise cost of the Millennium Bug. But IE6 was stable and remained Microsoft's browser offering for five years.

Despite that long period of stability - or, arguably, because of it - there did not appear to be a strong appetite for change when IE7 came along or, a couple of years further down the line, IE8. And so we find ourselves in 2010 with many large organisations and particularly government departments still using IE6, which is now nine years old.

The problem is that an awful lot has happened in those nine years and right now is a particularly exciting time with the new HTML5 and CSS3 support in the latest browsers: Chrome already has it, as does Firefox 4, which is out in a mature beta, and so will IE9's public beta, which is released in just a couple of weeks' time.

And in the middle of all this excitement, the government has announced that they won't be upgrading from IE6. Such a move, they say, would be "a very large operation" potentially at "significant potential cost to the taxpayer". They say that it will be "more cost-effective in many cases to continue to use IE6 and rely on other measures, such as firewalls and malware-scanning software, to further protect public sector internet users."

This is such a short-sighted option that I don't feel I need spell out the various reasons why it is a bad idea. Indeed, the quote above makes it clear there is an attendant security risk which is a strong argument in itself.

What is perhaps less obvious is that as software is increasingly web-based, software that is used by local authorities, it is not a straightforward transition to move between browsers: there is a lot of regression testing and consequent redevelopment to be done.

But it's not satisfactory for government IT strategists to simply throw their hands up and say it's too difficult or too expensive to change. Yes, I understand this is supposed to be a time of austerity, but that doesn't mean that an economical solution can't be found. In six months' time we will have a clear view of which of the current crop of browsers is the best and, as a first step, this can be deployed across government departments. From there, a two year plan to migrate applications from IE6 to the new browser will get departments to the point where they can look at their next upgrade. Because this is a rolling process and not a one off. Government needs to recognise that fact and start to make the cultural change that will enable them to leverage the benefits of what is still a fast moving (and exciting) technology.

Bespoke software is alive and well.

In a recently posted article on the Business Computing World website, Haseet Sanghrajka of ST Consulting writes under the byline "How Application Platforms Are Killing Bespoke Software'.

Now, I can only assume that the title comes from a bit of over-enthusiasm for his offering because this is certainly not what Mr Sanghrajka succeeds in demonstrating. What he does argue is that application platforms are the best way forward for companies needing software solutions, as opposed to either package or bespoke solutions.

Let's tackle the package argument first, as it is the easiest. I would certainly agree that more complex business software, when taken in package form, is limiting for any business. However, there should be allowance made for packages such as QuickBooks or MS Office: there are times when a package solution is entirely appropriate.

His argument against bespoke software seems to be related to development time, cost and maintenance. So, let's return to those arguments after we've had a look at what Mr Sanghrajka is proposing, which is an 'application platform'. Although this is not particularly well explained in the article, in his terms it consists of some packages - that is, Microsoft Dynamics, Office and Outlook - plus a bespoke development language, .NET. (Packages and bespoke development are, of course, precisely what he is campaigning against.)

Those of you who have any experience of Dynamics will be aware of its eye-watering price tag (although MS have now introduced a cheaper version to try and encourage take up in smaller businesses). Microsoft themselves are pleased to tell their resellers that they can anticipate many times the cost of the package in terms of consultancy fees. Readers of Mr Sanghrajka's article won't be surprised when they reach the end to see that his company sells precisely this type of consultancy.

But back to our argument. Dynamics is more commonly known as Dynamics CRM and it is for this purpose - customer relationship management - that the product is most commonly sold. Extending the product out to cover other functions takes us into the territory of square pegs and round holes, and it is for this reason alone that I struggle to see how this particular application platform can compete with bespoke software.

So, to pursue the argument, perhaps the article is only really supposed to be about CRM. One of the touted benefits of Dynamics is just how powerful, configurable and flexible it is. I don't disagree with that. But you can deduce from those features that it is a complex piece of software, which is why companies such as ST Consulting can make a business out of configuring it.

It is this complexity and the cost of the consultants needed to maintain it that is seeing organisations move away from Dynamics (and SAP, as well) to simpler, bespoke solutions that do exactly what their companies need and nothing more. Certainly any bespoke provider worth their salt can provide a CRM for less than the cost of a configured Dynamics solution.

So, the argument was that bespoke software is too expensive, takes too long to develop and needs maintenance. But Dynamics will frequently be more expensive as a whole, takes time to configure and is too complex for organisations to manage themselves, resulting in ongoing consultancy costs. What's more, working with a good software house - with business and systems analysts, experienced developers, and a strong testing and change management process - will lead to cost-effective software being delivered to spec, on time and on budget.

I'd like you to indulge me in a couple of very specific ripostes, too. Quite apart from the fact that the argument has not been raging for decades (two perhaps, which is technically plural, I suppose), Mr Sanghrajka has it plain wrong when he says "Unlike traditional bespoke development that relies on software coders, application platform technology allows organisations to build on the underlying relational database using point and click development tools. Key concepts such as database fields, data relationships and workflow are automatically handled by the underlying application platform layer." This is disingenuous, at best. Building and maintaining relational databases requires good understanding and experience. Whilst a casual user may be able to add an attribute here and there, by the time they are creating entities and connecting them, they are only a short step from having to call those Dynamics consultants back in to sort out the ensuing problems with performance, reporting and data integrity.

Secondly, Mr Sanghrajka states that "it is estimated that an organisation can create a new solution from scratch in the same time frame it takes to deploy a traditional packaged application." Does this need much more than common sense to disprove it? Unless the new solution is, perhaps, a VAT calculation and the package is, say, Microsoft Dynamics.

My argument here is not with Mr Sanghrajka, who has a business to run and who no doubt has a lot of belief in Dynamics. What I dislike is the false argument. By Mr Sanghrajka's own admission, bespoke is the best solution. However, his arguments against it are flawed and actually apply more acutely to Microsoft Dynamics. Or the 'application platform' if you prefer.

Everybody's talking; why your business can't ignore social media.

Perhaps you remember when you first heard about Facebook and Twitter. Maybe you were one of the people who thought they'd misunderstood when these sites were described to them: "what's all the fuss about..?". You might even have tried Twitter and abandoned it after a few 'tweets' finding it every bit as lame as it sounded when it was described to you.

You would then have been further perplexed when you started to hear people saying how important Facebook and Twitter (and numerous other social sites) were to your business. Did you sit and look at that flyer from Business Link inviting you to a workshop on how social media could benefit you, and wonder just what it was that you'd missed?

Now, I'm not saying they can't or won't benefit you - as it happens, we use both at Meantime - but this blog is not an attempt to convince you of the merits of social media or otherwise. What I do want to write about is the broader phenomenon of social media and what it might mean for your business.

First of all, let me give you a couple of examples of the type of impact I want to talk about. The first one came about last year when a protestor died at the G20 protest in London. At first the police denied that they had anything to do with it, stating this as fact at a news conference. The truth might have come out if enough eye-witnesses had managed to convince a newspaper to run the story and one might have believed it or not depending on one's opinion of the police. However, in this case, footage and first person narrative of the event was promptly posted on websites and picked up by news broadcasters and the police had to confirm that the man had, in fact, been attacked, unprovoked, from behind by an officer.

The second example comes from earlier this week when Wikileaks posted the Afghan war logs. Regardless of the ethics of this action, the bottom line was that once that information was in the public domain, with even a single member of the public, it could be immediately broadcast to the wider population. Whilst one can be impressed with how President Obama rolled with the horrible revelations contained in the logs, the key point here is that he did not try to refute what was published.

So, how do these stories relate to your business, assuming that you are not running either a security firm or a war overseas?

The point I want to make is that the publication of opinion and information is now unfettered to an extent that was unimaginable even ten years ago. Most of you will have used Amazon and seen the review system used there. Some reviews - particularly those for music and books - are obviously partisan and no more than opinion but when you look at product reviews, it becomes a bit more serious. It was one the birthday of one of my daughters recently and she wanted some toys from the Little Cooks range. The reviews on Amazon across a range of their products quickly highlighted the fact that no matter how good they looked on TV, the build quality was poor and they were not a good present.

There are now independent sites - such as the dreadfully named Revoo - that specialise solely in independent reviews, and consumers are becoming more and more sophisticated in analysing and interpreting the reviews, good and bad. A simple example of this would be when I bought some headphones recently. The pair I fancied had over a hundred reviews, the majority of which were very positive. As one does, I read a higher proportion of the bad reviews and satisfied myself that those reviewers had either been unlucky or had unrealistic expectations. So, I bought the headphones.

I think that in the near future we will see similar sites that are based around services, as well as products.

So, what does this mean for your business? Two things, I think. Firstly, there's no point in trying to deny a problem with your product. Apple have kindly illustrated this point for me over the last few weeks with the issues arising with the aerials on the iPhone 4. No amount of denial is going to convince potential customers, who can see reviews and comment from any number of sources that are presenting the actual facts.

The second, more subtle issue, is germane to those who provide services. The issue here is not around people reviewing a product but instead talking about how you do business and what results you achieve. It doesn't matter how good your staff are, how good your planning is and how good your track record; you will have projects from time to time that simply seem to be jinxed. In the past, one might have been pleased to simply get the project completed and the client out of the door and focus on your successes but those days are fast disappearing. Now it is even more important to understand why a project hasn't gone according to plan and to make sure your client understands that, too. You can't simply rely on the good news that is out there about your company already; beware the old adage that bad news travels ten times as fast as good.

In conclusion then, whether you sell a product or a service, the good opinion of your customers and clients is no longer something that it would be nice to have, a secondary consideration: it is now core to your sales and success. More than ever, it is important to have happy clients because, in this age of Facebook and Twitter, everybody is talking.