Can you really spend £35 million on a website?

Let's suppose I told you I was going to buy myself a new car. If I also told you what I planned to spend, you would naturally make some informed assumptions about just what I was going to buy.

I might say £6,000 and you'd think maybe a second hand car or low spec Skoda. Somewhere between £15,000 and £40,000 and you'd probably assume that I was looking at a new car. And how about if I said £100,000 or £200,000? Then, perhaps, you'd get really interested in what kind of car I was buying (and where I'd got the money from).

But what if I told you I was spending a million pounds? Now you'd be a bit bemused. Can you buy a car for a million pounds? you might ask. What is it, armoured? Jewel encrusted?

Which brings me, perhaps not obviously, to the Business Link website.

Yesterday, the government announced they are scrapping Business Link: http://www.bmmagazine.co.uk/Business-Link-to-be-scrapped-by-Government.870 Now, depending on your experiences with Business Link, you might think that is the loss of a resource that is valuable to small business or you might think it's about time. (Personally, I enjoyed my meetings with my local advisor- he's a nice chap - but I'm not sure I ever got anything out of it apart from a bit of local business gossip).

But one thing in the article really caught my eye: "the total cost of developing the Business Link website is a mind blowing £35 million". Now, I can honestly say, having been in IT for 22 years and in web development since 1997, that I have no idea how they have managed to spend that much money on that website. Certainly at that price - and notwithstanding the fact it is government funded - I would expect it to be compliant with the Disability Discrimination Act (it isn't) and not have obvious bugs (like its CSS errors).

Even a quick scoot round the site - which you can find at http://www.businesslink.gov.uk/ - will demonstrate that it's feature rich and has plenty of useful resources. But you could speak to any number of web development companies of a certain size and find they have developed sites on a similar scale for a fraction of that cost (the exception, of course, being the company that built the Business Link site, who are presumably maintaining it from their summer offices in the south of France).

Of course, this is ultimately about government's widely acknowledged yet never tackled problems around IT procurement. All too often, the tail wags the dog, with government suppliers telling their clients just what they will deliver and at what cost. Yet the solution is simple: start talking to and dealing with smaller suppliers rather than the handful of large companies who have been fleecing the taxpayer for years.

Building in bad practice - another BBC adventure

A few years ago, I was working as a freelance test manager for JPMorganChase in London and at the end of the contract I was invited to work on a problem project in New York. The project in question was having difficulties delivering to an aggressive schedule that required new releases every three months, with each release having a six month life cycle. This meant that at any given time there would be at least two releases in development.

The team on the project were very good, including a project manager, David Hodges, with whom I had worked before and held in high regard. At the first meeting we sat down and had a rather dispiriting couple of hours look at the project's history, where it was now and the future requirements.

Applying a bit of common sense, we decided on an initial release that was limited to correcting some live issues and started a conversation with the business unit to whom we were delivering about what they really needed in the very short term. Understandably, and given the frustrations they had endured, the business team wanted as much as possible in the next release; they had been waiting some time for important functionality.

So, we explained the challenges we had on our side and in the end, with their cooperation, we defined a manageable release. When we sat and looked at it, it didn't look too ambitious and, indeed, it was delivered on time, fully tested and functional. This set the pattern for subsequent releases and, despite their initial misgivings, the business unit ended up very happy with a steady stream of change, delivered every three months as required.

Yesterday my colleague, Steve Parker, sent me the following link: http://www.wired.co.uk/news/archive/2010-06/28/project-canvas-youview

Of course, I was interested in this from a technology point of view and also for the details of the predictable spat over the question of public money distorting the private market for which I have some sympathy (although little for Virgin and BSkyB, specifically). However, what really caught my eye was the following sentence: "If all that's met, and the project doesn't go more than 20 percent over its budget (which has also been prohibited by the BBC Trust), then Project Canvas is expected to launch in the early part of 2011."

This strikes me as symptomatic problems with IT development in the public sector. i.e. the acceptance that IT projects will go over-budget. Whether it is conscious or not, the trust is tacitly approving a budget overrun of 20%. This means those running the project, who should be responsible for the budget, won't begin to worry until that figure of 20% is approached. They certainly won't worry at the point where they are approaching the limit of the official budget.

Furthermore, previous experience tells us that if the budget limit is reached, no one will want to throw away millions of pounds worth of work and more (licence payers') money will be found to shore up the project. We may get the minor satisfaction of seeing a slapped wrist or two.

The point of this blog, as you will probably have guessed by now, is that there is no reason IT can't deliver to a budget, whether it's a financial or, as in the case at JPMorganChase, time limited. If the BBC have a budget for this development, then their suppliers, whether they are in-house or external, should learn to work to that budget. To deliver a successful IT project, it is important to be realistic, not ambitious. Software development is both technical and creative and consequently there is plenty of scope for issues to arise and cause slippage. Furthermore, technology is a moving target and their is no doubt that the environment around this development will evolve as it progresses. The BBC should set their project milestones now, so that this project can be cancelled early if it is not going to deliver to the proper budget and they should remove the 20% safety net immediately.

Now that's 21st Century customer service

One of the reasons this blog has been neglected for the past few weeks has been the fact that we've just been flat out with work and, whilst there are a few matters that I want to write about, I had an experience yesterday that has jumped to the head of the queue.

I'm in London today for the 'more exciting than it sounds' Automated Transfers to Local Authorities workshop, which has already scored its programme initiation goal of having a Greek acronym in ATLAS (although Midas remains the IT industry favourite in my experience).

As it's a fairly early start in London, I caught the train down yesterday afternoon. We left in good time for the station and I went to pick up my tickets from the machine at the station, having ordered them online from The Train Line. I popped in my card and I was prompted for my booking reference, which caught me off guard, as it normally just spews the tickets out.

The Train Line website has a nifty feature which enables you to SMS your journey details to your 'phone, so fortunately I had them to hand but the reference wasn't recognised. After two more attempts I gave up and bought fresh tickets from the booking office, just as the train rolled in. It was a mad rush to kiss my wife goodbye and jump on the train with my laptop, suit and overnight bag but I made it to a table and made to stow my luggage, at which point I realised I was still holding the car keys.

In a most un-English way I shouted for someone to hold the door, thus paralysing everyone else on the carriage at a stroke but I made it in time to hand the keys to my wife who was determindly striding the length of the train looking for me (and probably considering the eight mile walk home with two small children).

Eventually, then I was sat at my seat, luggage put away, book, laptop and iPod out, and I decided to Tweet my success against the odds: "Heading down to London for the DWP meeting, despite TheTrainLine's ticket pickup process letting me down #moredismalsoftware".

Less than thirty seconds later I had a reply from @thetrainline "@fennerpearson Hello, anything I can help you with? Dave"

Needless to say, my irritation with The Train Line flip-flopped in an instant and, fond of the website as I have been in the past, now I was in love. Before the train was at the next station, David Wilkins, the man at the end of the Twitter line, had sorted out my problem and given me instructions to obtain a refund.

There is a huge amount of suspicion and even distain when it comes to social media and I'm not saying I don't have doubts about it myself from time to time but here is a brilliant example of a company making full use of the tools at its disposal to give a personalised service in a transaction environment that - arguably as one of its benefits - has almost no contact between business and customer.

So, hats off to The Train Line for imaginative use of technology and thereby turning a very disgruntled customer into one who is now delighted to have had a stressful start to his journey, just so he could experience their use of Twitter. As anyone runnng a business knows, it's easy when everything's going right. It's how you deal with situations when they go wrong that sorts out the average companies from the excellent ones.

Computing article: "Calls for more transparency in ICT procurement"

Subsequent to my post on April 11th, an article appeared in Computing entitled "Calls for more transparency in ICT procurement", which you can read in its entirety here.

The article reports on a 'roundtable' debate chaired by Janet Grossman (the ex-chief operating officer for the Department of Work and Pensions) makes the point that, in order for government IT projects to succeed, projects do need to be smaller, which was one of the points in my posting.

As an additional point of interest, the article also makes reference to the fact that government procurement is tied up by a small number of large companies.

It's interesting that both the problems arising from and the solutions to government's IT problems can be expressed in common sense terms, easily understandable by the layman.

Why I believe the government has it wrong on IT

In recent weeks, as the main parties look for somewhere concrete to cut costs in order to locate the billions they need to save, they have alighted on IT as as a strong contender for saving money. And who can blame them?

Government's track record on IT is appalling. Huge overspends on systems that fail to deliver, with just a handful of large suppliers carefully tying up the market to their benefit, and decidedly NOT to the advantage of both government and tax payer.

The Child Support Agency's CS2 system, for example, is riddled with "insurmountable bugs" that mean many cases have to be handled manually: 19,000 in 2006 rising steadily to 75,000 by September 2009.

The problem, here, I believe, is how government buys its IT. It appears to completely lack the expertise to make procurement decisions that will deliver the required outcome. I have met a lot of intelligent people in local government who are quite incredibly committed to delivering good service. They know what they want from IT but seem quite unable to get it from the handful of providers who have found seats on this particular gravy train.

Recently we tendered for some work from a local authority, which had talked about developing an open source system that could be shared with other councils. Yet, when we received the paperwork, it was clear that the current provider had the authority locked into its own CRM solution. Elsewhere, when we have tendered successfully, we have delivered working solutions at a fraction of the price the larger software houses have quoted, in once case coming in at less than a sixth of the cost.

So, as I said, I can see why government has had enough of IT, spending billions on projects that are either abandoned or, once delivered, don't meet the requirements. However, I think it would be a serious mistake to abandon IT solutions. Going back to the CSA for a moment, the National Audit Office has calculated that when a case can be processed through the system, the cost to the tax payer is £312. When processed manually, the cost trebles to £967. The 75,000 cases being processed manually last September were costing seventy-two and a half million pounds, instead of twenty-three and a half million, if CS2 had been able to handle them, a difference of nearly £50M.

I believe, then, that the government does need IT. Furthermore, if civil service numbers are going to be allowed to decline by 40,000 jobs (and probable a lot more), then I would argue that government needs IT more than ever. Civil servants need to be freed up from manual processes and administration, to focus on serving the public. (See my blog earlier this month, "Good business systems are about liberating your staff, not getting rid of them.")

However, the solution to the government's problem is not so difficult. Let's look at the issues for a moment, which primarily arise from the simple fact that large projects are notoriously difficult to handle.
The longer the project, the more legislative changes it will suffer over its development cycle.
Big projects are hard to manage, where large teams and deliverables need to be coordinated.
The huge amount of analysis that is necessary means that detail is skipped, so requirements are misinterpreted or lost and parts of the solution don't integrate.
Vague specifications lead to inaccurate costs, so the supplier ups the price to protect themselves. (And add to this the fact that large companies have high salary overheads, so they want as many of their consultants as possible on any project.)

Projects away from the public sector are far less likely to be run this way, with the client wanting far more clarity about precisely what will be delivered, as well as how and when, before committing any money to the project. Government should learn from this, commissioning comprehensive, precise specifications as a separate part of the project and hiring third party companies to evaluate them. Projects should be broken down into manageable releases, such that everyone involved has a clear grasp of what is going to be delivered, and on what date and at what cost. What I am saying, in effect, is that the solution is to turn these large projects into a number of smaller projects.

You might, quite reasonably, argue that as someone who runs a software house, I have a vested interest in this argument and that may be true, but I believe the figures speak for themselves. Time and again, I have seen software benefiting my clients' companies, including some local authorities. Government must not turn its back on IT; it will be more vital than ever over the next few years. What it does need to do is to learn how to buy IT, including being a bit more discerning about those suppliers from whom it buys.

Good business systems are about liberating your staff, not getting rid of them.

As you might suppose, I’m a big advocate of computers and computer systems. I think the right bespoke software can make the difference between a company being good and great, especially in the eyes of their clients.

However, I would not for a moment suggest that computers are better than humans. Sure, there are some jobs that a computer can do faster, more accurately and more effectively but, in business, an awful lot of the time those jobs are the ones that humans don't want to do. Repetitive, predictable, frequent, labour intensive tasks.

And, really, no business wants to take people on to do those tasks. Businesses like people who contribute to the company’s success because of the skills and talents for which they were hired. They don't want to take people on whose sole role is to chase around bits of paper, add columns of numbers or keep track of where items are kept in the warehouse.

Most small businesses, as they grow, develop processes. A lot of the small, successful businesses that I go to see have very evolved processes, often involving spreadsheets and order forms and bits of paper being moved from one tray to another one. And I’m not being damning there: these are often very good systems that have helped the company to make its presence felt in its marketplace.

But, as these companies grow, so these systems start to creak. Bits of paper go missing, the person who understands how the formulae in the spreadsheet work is off sick, an order gets lost. The people who have other, important jobs to do, like making sales or sending out invoices are distracted by the work required to keep the system turning over. At this stage, a small business might start to consider hiring people just to administer that process. And just how do you go about recruiting someone to do a really dull job?

You don't need to have pre-cognitive powers to spot that I would suggest that at this point you get my company in to build you a bespoke software system to replace that process, or rather to emulate it on an application to let your company run the same way, only better. However, that is not the point of this post. What I want to say is that by introducing a bespoke system to replace the process, you not only save yourself the difficulty of recruiting those lovers of mundane tasks but, crucially, you liberate your staff. You are not replacing anyone, you are benefiting them and your business.

Those people who were beginning to flag, who were complaining that they didn't have time to do their job properly, who had stopped thriving in the workplace, suddenly find that those dull aspects of their job, tasks that, in fact, weren’t really part of their job have gone. They have hours in the day to do the role they were hired to do. Rather than looking over their shoulders for yesterday’s missing order form, they have time to look ahead and think what they could be doing to improve the way they work and the company’s prospects.

Bespoke systems will save you money, not least in saving you from hiring staff who do nothing but administer your business. But they won't replace your staff, rather they will help you to get the best from them.

PCI Compliance: What? Why? Where? When? Who? And how?

Welcome to my first post of 2010. We've been busy - really busy - since the start of December and I've not had time to get my thoughts in order let alone down on the blog. However, since part of the reason we are so busy is that we are in the process of working on two large e-commerce sites, my thoughts have been concerned with the issues around selling goods on line and that topic will be the subject of the first three posts (unless anything else crops up, of course).

The first topic to discuss is PCI compliancy, not least because so few people whom I meet who are trading online, particularly in small and medium-sized companies, seem to understand its implications.

So, the logical first questions is "what is PCI compliance?"
The term refers to the Data Security Standard set by the Payment Card Industry. The details can be found here but, in précis, the standard is concerned with ensuring that customer data - particularly credit card data - is held securely. In fact, the standard is so strict that, in fact, the solution is to completely avoid holding credit card details. Fortunately, many of the better payment gateways have made this a viable option for e-commerce, if not for telesales.

A reasonable question following from this, then is why is the standard so strict? Well, whatever my minor gripes about the standard (see below), there is no question that there were an increasing amount of e-commerce sites around that were not built to any given security standard and many of these were - and still are - holding unencrypted credit card details. Of course, these same sub-optimal sites were also the ones most vulnerable to hackers. Thus, it is understandable that the payment card industry decided to set a standard.

As far as the where question is concerned, PCI applies wherever you are trading.

So, if you are processing credit cards online, a good question is "when do I have to become PCI compliant?" The answer is that you already should be. Although it appears to be relatively easy to trade online without being PCI compliant and, if you are 'caught', you will usually receive a reasonable period in which to achieve compliancy, matters become far more serious if your security is breached and credit card details are stolen. The fines are punitive and your company will then be under constant scrutiny, with expensive top level compliance required.

The who, as you will have gathered by now, is anyone trading online. The banks have written to their merchant clients telling them of the need to be compliant, so I anticipate that there can only be a relatively small percentage of online traders who are genuinely unaware of the requirements around compliancy.

The $64 question, then, is how to achieve compliancy. If you are holding credit card details and intend to carry on doing so, then there are some big hurdles to jump. Just download the certification documentation from the PCI site and you will see just how extensive the requirements are. If, however, you use one of the better payment gateways, such as SagePay, there are ways around holding credit card details, even in complex situations involving delayed charging (such as when an order is shipped in multiple parts). Not holding card details makes achieving compliance a lot easier.

It seems to me that advertising relating the standard would be a good way forward. Educating customers to stop them using sites that don't demonstrate certification would encourage e-commerce sites to adopt a proper level of security. It would also avoid naive companies - who, perhaps, have not been properly advised by their web provider - incurring large, unexpected fines when their sites are hacked.

There's little doubt in my mind that the standard is flawed and the fact that the banks appear to have followed the PCI slavishly hasn't helped. Although we, Meantime, do not trade online, we have taken the trouble to achieve PCI compliancy as a company, as well as building e-commerce sites that are compliant. This was very difficult, unnecessarily so, and, in places, the requirements were illogical. However, PCI is the standard and that is what we have had to follow. All e-commerce companies need to follow suit.