Meantime IT - Business systems that work

Why do large IT projects fail?

2011-10-18T09:06:00.000-07:00

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%

2011-07-15T08:00:00.000-07:00

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

2011-04-27T02:30:00.000-07:00

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

2011-04-15T04:07:00.000-07:00

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

2011-01-21T08:50:00.000-08:00

"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.

2010-11-24T13:33:00.000-08:00

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

2010-09-22T03:50:00.000-07:00

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

2010-09-17T04:07:00.000-07:00

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

2010-08-30T07:55:00.000-07:00

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.

2010-08-09T01:18:00.000-07:00

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.

2010-07-29T04:06:00.000-07:00

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.

Paywalls: is this the end of free content on the web?

2010-07-13T06:56:00.000-07:00

As of the 2nd of July, The Times has now placed its content behind a 'paywall'. This term, a derivative of the term firewall, means that you can only access The Times' content if you are willing to pay for it. This is an important step forward in the debate about content on the web, as Rupert Murdoch puts his money, or his readers' money, where his mouth is.

The emergence of the web has had a dramatic impact on newspapers. Most obviously because, by and large, all of their printed content goes onto their websites, which removes the need to buy the printed version. Whilst newspapers and their associated magazines take a lot of money in advertising revenue, the loss of the newspaper's cover price as an income stream is clearly going to hurt. This also has a nasty by-product in that it makes newspapers more reliant on their advertisers' agenda. (This, incidentally, is why there is no editorially independent women's magazine that can criticise the beauty industry.)

Of course, with a reduced income, the newspapers have less money to employ journalists and so, the argument goes, the quality of journalism will decline. And this is the primary argument for charging, that newspapers are providing a service and that has to be paid for by some means.

But is that really the case and what are the alternatives?

Firstly, let's look at the question of the quality of journalism. I can't see that there is much point in pulling the tabloids into this argument - most of their readers know exactly the quality of journalism that they are buying - so let's concentrate on the broadsheets, who are the main players in this debate (after all, Murdoch hasn't put a paywall around The Sun's website).

Erwin Knoll said that "Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge." As it happens, I can vouch for this argument. Earlier this year an incident took place at the school where I am a governor. A young girl from a difficult background brought a small knife to school. She bragged about this on the bus and said she had a list of people to get. Staff at school confiscated the knife and the list without any danger or trouble and then notified the police. Here is that story in the Daily Telegraph: http://www.telegraph.co.uk/news/uknews/crime/7519842/Schoolgirl-found-carrying-a-knife-and-hit-list-of-teachers-and-pupils.html. Quite apart from the obvious discrepancies between the story and what actually happened, it's worth noting the picture of the knife - a library photo, far larger than the knife concerned - and the emphasis on the stab vests, which police actually wear as a matter of course.

If this is the quality of journalism in our broadsheets, what are we in danger of losing? And, whilst anecdotal, the story above is far from an isolated example and there are far more sinister abuses of journalistic power, particularly around elections. (One thinks, of course, of Bush's first election "victory".) Whilst we have a Press Complaints Commission run by the press, specifically newspaper editors, we are not going to see the very improvement in journalistic standards and quality that is required to render newspaper journalism a profession worth protecting.

So, the argument for 'saving' journalism is not black and white. However, we clearly want our news from somewhere, which brings me to my second question, what are the alternatives?

As it happens, there are a lot of people out there commenting on the world around us, people who are free from the constraints of editors and newspaper ideology. For example, in the two years leading up to the credit crunch, a number of financial bloggers, some of whom published books, were accurately predicting what was going to happen and when. (In fact, there is a parallel in the Liberal Democrat Vince Cable who, effectively freed from toeing any party line, was able to air his concerns about the impending financial disaster.)

In his book 'Cognitive Surplus', Clay Shirky rightly points out that as publishing becomes easier, so the average quality declines. This is quite true but, to follow what has happened with printed books as an analogy, the fact there is more content being produced actually leads to a raising of the bar at the top of the quality scale. I believe that what will evolve is ways for people to find that good content and, in the same way that best seller book lists and the community on Amazon help us to find books to read, so we will point one another to the quality blogs and user published content. Indeed, one could well see a future newspaper website being a portal through to that content, some of which may be commissioned through advertising but probably not.

So, is this the end of free content on the web? The answer, simply, is no. I believe Murdoch has made a mistake here and, indeed, overestimated his own ability to impose his worldview on an evolving environment, one that is moving away from the models he desires. I won't pretend that I know exactly what the future looks like but I do know it will be one in which we pull our news from a variety of sources, channelled to us by portals and subscription services.

NI14 - When government has IT spending right

2010-07-10T07:10:00.000-07:00

A long time before this austerity coalition came to power, a policy called NI14 or "avoidable contact" was introduced to local government. Whilst this sounds rather unfriendly - as if our public servants want nothing to do with us - it was, and is, a good policy and one that might be usefully adopted by any company.

By whatever means, it was established that the cost of a face to face meeting between a council employee and a member of the public costs somewhere around £15, a 'phone call perhaps £3 or £4 but a website visit only has an associated cost of a few pence.

Thus, making information available on a website - anything from swimming pool opening times to a PDF of the application form to become a taxi driver - saved the council money and, crucially, freed employees up to do other work.

This was all very sensible and a good example of IT benefiting both an organisation and its clients or customers.

This policy and its aims have necessarily taken on a darker hue in the wake of the cuts that have been announced since the election and the inevitable job losses to follow. But whether you see the swingeing cuts as evidence of an unleashed Tory ideology or the essential measures required to raise the country out of a financial hole, the goal remains the same: don't tie up council employees' time on jobs that can be done by websites or, by extension, applications for mobile 'phones.

So, I was surprised to see this article in The Telegraph - http://www.telegraph.co.uk/technology/news/7874856/Government-iPhone-app-spending-disclosed.html - criticising government spending on iPhone applications.

Firstly, the costs involved - £10k to £40k - are hardly scandalous for IT development, and that's before they are compared with the millions and billions haemorrhaged on the police and hospital systems.

Secondly, in NI14 terms the expenditure makes absolute sense. The jobseekers' app, for example, has been downloaded 50,000 times. That's 50,000 people using an app that has cost the equivalent of perhaps three public sector salaries. The maths is simple and compelling.

I am all for keeping an eye on government spending, particularly around IT, but it seems crazy to me to criticise spending that not only makes demonstrable financial sense but is also a success story within the terms of one of Whitehall's own policies.

And don't worry, the irony of the BBC investigating this story with a view to criticising an organisation for not budgeting carefully around its new media spend really is not lost on me.

Is it time to create a 'top shelf' for the Internet?

2010-07-05T02:52:00.000-07:00

It is an unavoidable ethical complication: sometimes good things come out of bad. Medical research, for example, has been assisted by murdering grave robbers and the horrific experiments of wartime scientists.

And so, on the web, it is undeniable that Internet technology has been pushed ahead by the demands of the pornography industry, which has enthusiastically driven the research and development of commonly accepted and valuable web tools such as video streaming.

Like so many elements of the free market - not to mention the banking sector - those making the money are happy to push ahead, while those with rational reservations make comments from the sideline that are accepted but not acted upon. Thus, we find ourselves with a generation now that has access to pornography that was unthinkable even ten years ago. No one can be sure where this will lead but you will not find many people arguing that it is a good thing.

To be clear, this blog is not about the pros and cons of pornography. However, I think I would be comfortable stating that the industry that promotes and produces it is, by and large, an unpleasant one, driven by high profits and with little regard for the people it uses. And I am consequently comfortable stating that in matters of regulation, I would think twice about consulting them or listening to their arguments about how they keep their content away from young people. (How many 15 year old boys are going to pay heed to a 'gatekeeper question' asking if they are 18?)

I am writing about this because last week, ICAAN, which is the body that manages 'top level domains' such as .co.uk, .com and .ac.uk, has begun the process of introducing a .xxx suffix for use by sites with pornographic content.

This strikes me as a very positive step. In no other area of our lives do we allow hardcore sexual content to be mixed in with the rest of what we see and do. I wouldn't take my children into Waterstones if I thought that Harry Potter would be sat side by side with adult literature. Indeed, I would be far happier with my children having unfettered access to the web if I knew there was a way by which I could simply block all unsuitable content.

More than ten years ago, a friend of mine was thinking of developing a trailer for windsurfing equipment and asked me to see if there was anything equivalent already on the Internet. I naively used AltaVista (ancient but rather good search engine) to search on 'water sports' with results that took me by surprise. More seriously, a friend recently complained to me that his daughter's biology homework had been to use the Internet to research bodily fluids, one of which was 'sperm'. This, at best, was a naive teacher.

Moving all pornographic content to .xxx domains would avoid this kind of accidental contact and also make it easier for the search engines to classify the data they pick up off the web.

There's no denying that the frontier spirit of the Internet has been and remains a great asset in its development. However, this romantic notion of a new wild west should be tempered by these oil barons of cyberspace whose intentions are not to do with creating a brave new world but instead revolve around exploitation and profit.

It is for all the above reasons that I welcome the new .xxx domain and I would support any and all efforts to oblige sites with adult content to move to using them. After all, for anyone who wants to access that content, nothing changes except a few letters in a URL. The advantages though, to those who don't want pornography and especially those who should be protected from it, are immense.

Can you really spend £35 million on a website?

2010-07-02T07:00:00.000-07:00

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

2010-07-01T04:48:00.000-07:00

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

2010-06-21T00:26:00.000-07:00

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"

2010-04-15T09:53:00.000-07:00

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

2010-04-11T07:07:00.000-07:00

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.

2010-04-06T07:47:00.000-07:00

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?

2010-03-09T11:50:00.000-08:00

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.

2009/2010 - what's old and what's new?

2009-12-31T10:17:00.000-08:00

One of the benefits of hindsight is that the dust has had a chance to settle, the echoes of the hype have died away and one can see what actually happened.

So, in retrospect, what has 2009 given us? We have Windows 7 from Microsoft, the increasing ubiquity of the iPhone from Apple, increasing diversification from Google plus the new(ish) kids on the block - Facebook and Twitter - have become firmly entrenched in our lives.

I must say I am surprised at the popularity of Windows 7, not because I don't like it - I do, very much - but because, as a user, I don't see much difference from Vista, and I could never understand why that received such a bad press. But certainly for a lot of companies who have 'rested' on Windows XP, this is an opportunity to upgrade and one that shouldn't be missed; technology is not a one-off investment and needs to be 'topped up'. Hopefully, we will also see local authorities and the rest of the public sector make a long overdue move from Internet Explorer 6. Whether that is a conservative move to Internet Explorer 8 or a bolder move to Chrome of Firefox is less of a concern.

While Microsoft continues to polish its golden eggs, Apple have continued to proceed apace with the iPod/iPhone technology. I have a lot of respect for Apple - although I must confess that I find the blind devotion of many of their aficionados rather off-putting - and their established strategy of tying their software to prescribed hardware continues to pay dividends in driving technology interfaces forwards.

Google's ongoing growth is perhaps easier to define in financial terms than anything else. While the core search engine remains largely unchanged apart from its logo (the subtle '20th Anniversary of the Wallace and Gromit Characters' being my favourite from this year), we have seen a slow take up of Google docs and the guarded release of Google Wave. Whilst I admire Google's drive to diversify rather than resting on its search engine, I can't say that I see Google docs winning a huge take up from business in the short term - it's too unclear who can see what and just where the data is being held - and I've been underwhelmed by the time I've spent evaluating Wave. For business, I think time would be better spent on Microsoft's excellent - but obscure - Groove software, which is excellent for sharing documents and working collaboratively on a shared set of assets.

Facebook and Twitter both became firmly established this last year, thoroughly dividing those with exposure to them when it comes to any discussion about their use and value. Facebook is probably the most expensive diversion ever developed, having taken tens of millions in investment yet reporting a profit for the first time only late in 2009, despite a reported half a billion - one third of web users in the world! - allegedly being signed up. (It's worth remembering that AOL, valued at $162B ten years ago, on the basis of its users, is now worth around $3B.) Twitter's value is even more vague and, with no fees or advertising to support it, was no doubt very relieved by the massive cash injection from Bing and Google a couple of months ago when both search engines bought licences to Twitter's content. I must say that while I can see Facebook generating a medium term profit with better, targeted advertising, I'm still struggling to see where Twitter is heading (and that is speaking as a user).

And if that's what we've had over the last year, what does the next twelve months hold? The industry and the web being what it is, there are no doubt some surprises out there and I'm not going to try and call them. What I would like to do is briefly look at the scheduled releases and try to extrapolate some of the trends that we have seen. From the big players, we have Microsoft's Office 2010, Apple's Tablet, and Google's Chrome operating system to look forward to, as well as the Android OS for 'phones. I think it's also worth considering the influx of 'apps' into our lives and where the so-called Web 2.0 technologies are taking us. Finally, the mysterious 'cloud' that is appearing in the media is worth a word or two.

Office 2010 has been released as a beta test version, which I've been running for a few weeks now. There has been some refinement of the new interface added in Office 2007, which has also been belatedly applied to Outlook, but I must say I've not come across any major improvements. Microsoft Groove, mentioned above, has been rebranded as 'SharePoint WorkSpace' although this is misleading as it provides an alternative to Sharepoint. On the whole, I can't see much incentive for business to upgrade, except for the consideration that this is the software where the most focus will be for security patches and ongoing development.

Probably the most exciting hardware launch of the year, assuming it actually happens, of course, will be Apple's tablet, essentially an iPhone the size of a netbook. The iPod Touch and iPhone have taken the introduction of internet technology into our lives and stepped it up significantly: there has never been so much development - or purchasing - of small applications. The only limitation to these devices so far has been size and the tablet, roughly ten inches long, will get around that. (The fashion industry has been trying to introduce a 'man bag' for years and that may now happen as we need something fashionable in which to carry around our iSlates or whatever they end up being called.)

Less exciting but possibly of equal significance in the long term is Google's Chrome operating system. It was perhaps a bit confusing giving it the same name as their (slightly underwhelming) browser but there is some logic. As I understand it, the Chrome OS will run all the components of a netbook - sound card, monitor etc - but from an application perspective will consist of little more than a browser. If you were a confirmed user of Google docs as well as other online apps such as Spotify, then this will make some kind of sense. Whether people are willing to run everything off the web and keep nothing local is, I think, very doubtful in the short term but Google are in that elite club of companies who can afford to play a very long game, laying foundations now for operating paradigms that may only be widely adopted in a few years' time.

Similarly, while its Android operating system and associated mobile devices (such as the Nexus 1, also due for release in 2010) may seem like a lost cause when placed up against the iPhone, Apple have made notable mistakes and had significant failures in the past - indeed their fortunes were wholly resurrected by the return of Steve Jobs and the development of the iPod - and I think it's safe to assume that Google has its eye on the long game here, too.

Whether users have an iPhone or an Android device, though, they will have one thing in common and that is an increasing appetite for apps to run on those devices. Indeed, as we update our status using the Facebook app and search for items to buy through Amazon's app, it's tempting to think that all these technologies are converging. The truth, though, is more subtle than that. The internet has provided us with a common platform and for the foreseeable future any snapshot of our personal and professional technologies is going to consist of the devices that we use to access the internet and the applications we use to manipulate the data that we store there. And that includes business information, of course.

Any forward looking business will now have a web presence of some description and probably be storing and maintaining data in that environment: we now have an increasing range of options for accessing and using that data. One question that naturally arises from this is how do we anticipate how much space and processing power we will need to support these new ways of working? The answer to this, in theory, is 'the cloud'. At a high level and from a users perspective, this is an environment that 'extends' to meet the demands placed on it. Thus, as you require more space or processing power, the cloud dynamically adapts to give you those extra resources. I'd say it's not where it needs to be yet - not least because it's not PCI compliant - but I would be very surprised if it is not an integral part of the way we use the Internet in the next two years. Certainly at Meantime we will be migrating some simpler sites onto the cloud this coming year.

In conclusion then, there doesn't seem to be any reduction in the onward momentum around every aspect of the IT industry as we see exciting and innovative developments in hardware, operating systems, infrastructure, applications and communications. As ever, the trick for business is to stay aware of these developments, keep a safe distance from the 'bleeding edge' (neither too close nor too far behind) and to be constantly aware of where these changes can benefit the way in which we all work, considering when they can and should be introduced. One thing that I do anticipate this year for our company is the beginning of requests for iPhone applications for our clients, almost certainly the extension of their extranets out onto the iPhone platform as a means of communicating with the staff, suppliers, clients and customers. And I'm very excited about that!

You can have what you want but only if you ask for it.

2009-12-29T10:24:00.000-08:00

Sometimes when I'm about to start writing a post, I think to myself that I can't write about something so obvious but then I usually consider the incident that has prompted the post and realise that, especially when it comes to IT, there's a lot of truth in the old adage that there's nothing common about common sense.

In this particular case, I was talking to an acquaintance who has a friend - let's call her Julie - who works for a well known IT provider. Julie's job is to sort out what this provider is going to deliver after a contract has been signed. In this particular case, the company for whom she works has just signed a huge contract with a well known mobile 'phone company. A project has been determined, a cost agreed, a contract signed and now Julie has to work out what actually will be delivered as part of that deal.

Putting this into a household context highlights the absurdity of the situation. Let's say you decide to have your kitchen refurbished. Uncertain of exactly what it is you're buying, you might decide to engage a large, nationally known company to come and measure up with a view to doing the work. A representative turns up at your house, you say to him "I'd like a new kitchen, please". You'd certainly expect him to take a look at your kitchen and maybe even ask you for a few ideas about what you want.

At that point, would you sign a contract and agree to hand over your money upon completion? Of course not. You'd want to see some designs, talk about materials and colour schemes, perhaps look at the prices the company was going to charge for your appliances.

So why is business so very different? Well, to be fair, it isn't always. We do find that with a lot of SMEs, particularly those owned by one person or a small group of people, a great deal of care is taken to understand where the money will be spent. But as a simple rule of thumb, we find the larger the business, the less detail we are asked to provide.

However, whilst a relaxed attitude such as this might seem like an opportunity to get away with being a little less diligent, we like to be absolutely sure what it is that we are being asked to deliver. There must be a specification of some sort. Even, for a small job, say a text change on a website, where the request might take the form of a 'phone call, we will still follow up with an email to confirm what we are proposing to do. But for a job that is going to cost tens of thousands of pounds surely it makes absolute sense for both sides to have a clear specification?

There are a couple of principle reasons, in my experience, why this doesn't happen. (Three, if you count sheer negligence.)

Firstly, the client doesn't understand what they are buying. This is a very legitimate problem. As I have mentioned before in my postings, people are usually pretty good at buying something they can understand, business cards or brochures, for example. Buying a website and, particularly, software is very different. For example, two years ago we put a site live for a new client. It was a fairly straightforward build job and it had passed through UAT and been signed off by the client without incident. So I was surprised when the client rang with a complaint: they had looked on Google and they couldn't find the site. Now I was able to explain that Google and other search engines don't work instantaneously but there was no reason for the client to know that. This isn't a great example because it would have been hard to trap this expectation at any point in the development but it does highlight the fact that you have to work hard to anticipate and manage your client's expectations.

The other problem is when the client doesn't have the time or inclination to get into the detail of the work. A very good example of this is when a client wants a bespoke e-commerce site. During my initial conversations with them, they will often say something along the lines of "we both know what we're talking about: just an e-commerce site". However, when the site is delivered and suddenly it does get some attention, you can find that what the client was talking about was Amazon.

As a footnote to the examples above, this leaves negligence. There used to be a saying that "no one ever got sacked for buying IBM". The implication there being that if you hire a big 'name' company, no one can blame you if the deliverable isn't up to scratch.

So, the bottom line here is that a decent specification protects both sides in the business relationship. As a provider, we know exactly what we're committed to delivering and the client knows what they are buying. This enables us to quote price and time-scales accurately: in fact, I don't know how we would stick to our promise to deliver on time and on budget if we didn't do this.

For larger jobs, we may even charge for the preparation of the specification. This is not always an easy sell but in addition to protecting both parties once it comes to development, it also means we have the time to do really detailed design and analysis. Furthermore, the client can use the specification as a tender document to get the best price for development. I'm pleased to say that, so far, the development work has always come back to us but with the specification done properly, this is not a done deal.

Your databases are your crown jewels, so treat them with care.

2009-11-29T11:48:00.000-08:00

For what ought to be a fairly precise industry, computing is fairly weak in a few semantic areas and one of those is the term 'database'. A database is, essentially, any store of data: it might be an Excel spreadsheet of customer names or even a Word document of contact addresses.

More properly, we use the term to describe a formally structured or organised datastore of information. These datastores are created, managed and accessed by specific software, the most common example being Microsoft's Access.

The data is stored in different 'tables' and these are linked together using the data items. So, for example, customer names and details might be on one table while the customer addresses are on another. Each address is on a separate row and has a unique reference. This reference is also held on the customer rows to which it applies.

The example above consists of two tables but a small business system will comfortably have ten times that number. Indeed, database design is an art in itself. When we take on a new project and the initial business analysis is complete, we well sketch out a data model - an initial design for the database - to check our understanding and identify areas requiring further analysis. Over the years we have found that once we have the data model right, many aspects of the system we are constructing will fall into place.

As well as being the foundation of a new system, the database remains the most important feature. Screens can be badly designed, load times may be poor, navigation may be unintuitive but these are all faults that can be fixed and, once fixed, there will be no sign they were any different.

Let me break out here and tell you a story from earlier in my career. I was working as a test manager on a migration project for a large financial institution. All of the existing data - clients, accounts, balances etc - was being moved from a system that was twenty years old onto a new one. My job was to make sure that all the data transferred correctly from the old system to the new one.

Everything went well in testing and the time came for us to do a trial migration. As part of the migration process, we generated a lot of reports, so we could tally the number between the original system and the new one: number of clients, number of accounts, total value and so on. We even threw in some logging with no immediate business value - average number of accounts per client, mean total per client - just so we could make sure all the numbers matched.

The testing had been thorough and I was very pleased with what we'd done to date so it's no exaggeration to say that I was horrified when our test run against live data returned results best described as nonsense. I came clean at the project board meeting and assured my colleagues that we'd get to the bottom of the matter.

Two weeks went by and the results against our test data continued to be spot on, as you would expect, but the more we delved into the live data, the more confused we became. Armed with a set of inexplicable examples I returned to the project board and a member of the user group came clean: at some point in the system's history, there was a bug in the code that meant that the relationship between a client and their accounts was not recorded properly. Without these relationships in place, of course, we had no way of doing a meaningful comparison between the old system and the new one. Furthermore, we had to - effectively - build bugs into the new system to accommodate this 'junk' data from the old one.

Quite apart from the importance of testing, this story emphasises the fact that if there is one aspect of an IT system where you cannot afford to make mistakes, it is with your data. Once data is lost or corrupted, there is no easy way of correcting the problem. Indeed, having 'holes' in your data can commit you to a future of weak software, where the processes and validations have to be weakened to compensate for the mistakes that you have made in the past.

When businesses change hands, websites and IT systems are assets of the sale and so, of course, is the data. If you aren't selling your business, then your data remains at the heart of what you do. Either way, it is vital that you take care if the information that is at the heart of what you do. Here are my recommendations for doing just that:

- Make sure that you, your IT department or your IT provider understand your data.
- When building a system, ensure that your data is captured in an appropriate structure.
- Back up all your data daily.
- When you make changes to the system, particularly - but by no means exclusively - to your data model, then insure that you carry out the appropriate amount of regression testing to ensure that your data is not adversely affected.

Prevention is better than cure, but what do you do if you have data that is corrupted? You need to cater for the existing data that is substandard but that is no reason to weaken the processing around your new data. The simplest measure to take is to flag your old data so that validations know when to apply strict rules and when to apply weaker ones. An example would be if you insist that anyone registering with you has a post code but this rule was, at some point, not enforced. By flagging those addresses with no post code as, say, 'weak data', you can ignore the post code validation when processing those addresses, whilst being as rigorous as you like with data that is not affected.

The bottom line here is to appreciate your data. Your understanding of your business almost certainly maps down to the data (whether you are aware of that or not!) and you must make sure that the people who build and manage your systems take the time to listen to you and thus share that understanding. If your data is corrupted or lost, that is equivalent to losing a filing cabinet in a fire, so you need to protect the data you have and treat it with respect. I think I have mentioned before that of the businesses located in the twin towers, a third went under after 9/11 because they had no backups of their business data.

Mind the gap! The Ecommerce Expo 2009.

2009-10-21T03:55:00.000-07:00

A few years ago I set my parents up with a broadband connection via Demon Internet (now Thus plc). As they live in London, they were able to get a fast service - at least for the time - and they never had a problem with it: they went to the PC, the broadband was available and worked without a hitch. About eighteen months ago, however, my father saw an advert for TalkTalk, offering broadband as well as 'phone services for only £6.99 a month, which was a third of what he was paying Demon.

Perhaps I was lazy or perhaps I didn't feel up to trying to argue against TalkTalk's excellent advertising campaign but I rolled over and said it sounded like a good deal, so why not go ahead? As you might have already guessed, there followed weeks of 'phone calls to support numbers, promises to call back that were never fulfilled and a very unhappy father. Even now, over a year later, the service is patchy and more akin to what one might expect in a cottage in Cumbria, five miles from the nearest exchange.

So, having set the example of how the marketing of a product can be very different from the actual delivered goods or services, let me turn my attention to this year's Ecommerce Expo. Yesterday I went down to Earls Court* for the day to catch up with where the sector is regarding Ecommerce and its related industries.

There were certainly some interesting ideas around payment methods, although nothing that struck me as an alternative worth considering to SagePay, which is our preferred solution for ecommerce payments. One apparently global company I spoke to even seemed surprised at the notion of validating cards but not taking payment until shipping. Have they never used Amazon?

My journey down was certainly made worthwhile by the invaluable twenty minutes I had with a technical advisor from Rackspace, who verified some of my concerns about cloud computing and made me think that we'll revisit that next year. The alternative solutions that he offered,though, were sound and intelligent. As a company, they continue to impress me.

Of course, I spent a lot of time visiting the stands of our competitors, most of whom were selling package solutions. (Dydacomp were there touting their MOM product, although they seemed to have less angry customers around their stall than last year, possibly because they have belatedly managed to release a PCI Compliant version.) What was notable about all the stalls - bar one, which I'll come to in a moment - was the fact that they all seemed to be offering the same things - a better customer experience, better sales, email marketing, SEO (of course), more effective order processing and so on - but there was very little in the way of customer testimonial. I must say I was very envious of the brand management company who had a glowing reference from Sainsburys and the PayPal stand predictably had some impressive names and logos on it but they were the exception.

However,I know two or three of these testimonial-free companies by reputation (from their ex-clients), and I know that the service they offer is not always as slick as they would like. And, to be clear, I think that's true for any small business. The problem is, then, this gap between the marketing and the deliverable. Spend enough money with a marketing firm, rent sufficient floor space at the Expo and your company can look like a million dollars. But, if everyone is saying the same thing, what's the point?

What was the one stall that was different? UKFast had by far the largest stand and they had set up a Formula One car with a plasma screen in front of it, so vistors could play a racing game. They backed this up with a bar and half a dozen attractive young women dressed in shorts and high heels. My knee jerk reaction was "how passé" but ultimately if there was a game to be played at the Expo of having the most attractive stand, then rather than big posters with a load of claims they might or might not be able to deliver on, UKFast went straight for the jugular and they "won".

I wouldn't claim to be the first to highlight the gap between the well-functioning marketing department and the product or service being delivered but it did strike me yesterday that this year's Expo was all about saying what your company could do without really backing it up. In a way, this reflects the issue we had with our own website: when there are so many sites out there telling you that their company can build you the best website, ecommerce solution, SEO etc etc, then how do you compete and stand out? Surely the only differentiator is the testimonials page that tells you not what a company says it can do but what it has actually done. Here's ours: www.meantime.co.uk/testimonials.php.

*I really will send a box of chocolates to anyone who can explain the apostrophe anomaly between Earls Court and Earl's Court Road.

31 flavours of testing

2009-09-30T12:32:00.000-07:00

So, as promised, here is the post about the different types of testing. Maybe there aren't thirty-one but there are perhaps more than you might expect, although I think all the ones detailed here will make absolute sense to you.

The first three derive directly from the documentation that is used for large projects but which also has its analogues in some smaller applications. The relevant pieces of documentation are: the business requirements document; the system specification; and the technical specification. I will talk briefly about each of these in turn:

Business requirements document: As its name implies, this document describes the user's requirements. It is a scoping document for the project and describes, at a high level, all of the processing and functionality that is required.

System specification: This describes in more detail how the system will be built, perhaps including screen mock-ups, business rules and a database schema.

Technical specification: This is the document that is used by the developer. It will include specific rules around input validations, how the database should be updated and so forth.

The three main branches of testing - certainly the three that are most commonly used - correspond to each of these three documents. (Sometimes they are shown as a "V model" with the documents on the left arm and the corresponding testing on the right.) These tests are:

Developer testing (sometimes known as 'unit' testing): as its name suggests, this is testing that is carried out by the developer. This is the most basic form of testing yet, in many respects, the most important. Indeed, there is an old IT adage that says that bugs are ten times more expensive to fix for each step down the testing path they remain undetected (not least because of the regression testing involved (see below)).

At this stage the developer should test all the screen validations and business rules relating to the screens on which s/he is working. They should also check that the reads and writes from and to the underlying database are working correctly.

It's worth re-emphasing the point that any issues missed at this stage will slow down later stages when they are discovered, returned to the developer for fixing and then the testing is repeated.

System testing: Once the developer testing is complete, then the entire system can be pulled together for an end to end test. This form of testing is more scenario based and runs along the same journeys that will be used in production. So, for example, testing an e-commerce appliaction, a system tester would add products and prices, then pose as a customer and make purchases and then ensure that the orders are recorded and stock levels are amended correctly.

User acceptance test: I have blogged about this in some detail before, so I will just say that this is the testing where the user can ensure that what has been delivered matches the brief.

So, if those are the most common forms of testing, what other types might you come across? I have described half a dozen others, below:

Implementation testing: moving code and database changes through test environments needs to be a closely managed process but the move into a live environment can be slightly different and therefore needs separate testing. So, for example, in an e-commerce application, the live transactions to the bank will only run once the software is live. This means this part of the process can only be tested in the production environment.

Regression testing: A test cycle - i.e. a series of related tests - is invalidated as soon as any of the components that were tested is changed. Of course, sometimes it is necessary to change components - if a bug has been found or if the user requests a change to the process - and then the affected test cycles need to be re-run and this is called regression testing.

Volume (or 'bulk') testing: As more and more data is added to a system, so performance begins to change: database response times may slow, screen load times can be affected and lists may become unmanageable. Sometimes these issues can be managed as a system grows but if a change is being released to a large, existing customer base, then it is essential to test against high volumes of data.

Load testing: this is related to volume testing (indeed, the two are sometimes combined for operational acceptance testing or OAT). Load testing involves having many, many users accessing the system simultaneously. This can be difficult to simulate and there are specific tools - such as Astra Load Tester - that can be used (at some expense!).

Automated testing: Sometimes the same test cycles need to be repeated over and over again. An example would be testing a web application against many different operating systems and browsers. There is a high overhead to automated testing; test scripts must be changed to mirror any system changes and, of course, the scripts need testing themselves. However, it does have its place.

Using reports for testing: Sometimes a system can, in part, be used to test itself. If a system has a decent reporting function, then that can be used to check that the system is correctly recording its own activity. So, if the testing started off with twenty widgets in stock and seven have been 'sold' in the tests, then the stock report should show thirteen left. If it doesn't, then either the system or the report needs debugging.

Part of the skill of testing is understanding the appropriate tests for an application: a simple testing might not need a separate system test for example. However, two types of testing should always take place before a change is put live: the testing done by the development team and the UAT carried out by the client.

What successful testing looks like.

2009-09-15T13:59:00.000-07:00

If you were feeling reckless (or just had a lot of time to fill) you might ask me where I.T. goes wrong. Amongst the many theories and anecdotes that would ensue, I believe there is one theme that would crop up repeatedly to such an extent that ultimately if someone were, in turn, to ask you for your thoughts on the source of I.T.'s failings, you would say "testing". (Or, perhaps, "would you mind if we talked about something else".)

On Saturday I met up with a man for whom I used to work at the Royal Bank of Scotland Group. We had both been successful test managers - indeed, Cameron still is - but we agreed that ultimately you only need three things to achieve that success: common sense; tenacity; and no desire to be popular.

Testing is a simple science. In my next blog I will talk about the different types of testing but, at a high level, testing is just about making sure that the software works the way it is supposed to. What could be simpler? you might reasonably ask and the answer is not much. Assuming you have good communication with your client or, better yet, a decent system specification document, you will know what you are building and what the system is supposed to do and, therefore, what you need to test.

For a simple website, that will mean making sure that there are no mistakes in the text, that the images all load and that the links work, that your SEO is in place and that your site conforms to standards around accessibility and W3C. For an e-commerce site you will, amongst other things, check the product search, that items can be added to the basket, that VAT is calculated correctly, that your secure certificate is in place and that a customer can actually complete a transaction. And so on.

So if testing is that simple, and it is, how on earth has that ended up being a prominent and consistent a factor in I.T. failures?

Firstly, I think, testing has never been a strong feature in I.T. I was on my fourth I.T. role when I encountered my first colleague whose job was, specifically, testing. He introduced himself as a system tester to universal bemusement. A few years later, in 1995, in fact, I worked with a chap called Graham Bradford who speculated that testing could become big business. I don't think Graham had anticipated the Millennium Bug but he was absolutely right.

By coincidence, I made an uncertain move from systems analysis into testing the following year when IBM interviewed me for the wrong job but gave it to me anyway. In the early days I was delighted to find that I was apparently being paid for old rope - for my common sense, in fact - but I quickly learnt where a test manager proves his worth. Time and again I have seen the time set aside for testing on a project plan effectively viewed as contingency. As development delivery dates slip, the go live date does not and the element that suffers is testing.

And this is where the tenacity comes in: if, as a tester, you are told that you are going to receive the new system for testing two weeks later than planned, then you need to make sure that the live date is pushed back by two weeks, so that you don't lose the time you need. Project managers do not like this. And that's why you need to be prepared to be unpopular.

Furthermore, you need to insist that any change that is applied to a system needs to be tested. A few years ago I was working for a company who wanted to make some "simple changes" to the website. We had a lot of clients using the site for financial transactions and I insisted that any changes needed to be tested. I was told that the changes were not functional and that there was no need for testing. I dug my heels in and told the project manager that whilst I couldn't stop the changes going live, I certainly wouldn't sign them off. Eventually, with an attendant dip in my popularity ratings, the testing was authorised.

Lo and behold, we found some issues. There was no ticker tape parade and no bounce in my popularity, just a few gripes about how I couldn't have known there would be any bugs. Well, of course I couldn't. But at least the next time a "simple change" came along, I had a good argument to fall back on.

So, what does successful testing look like? Well, in detail, it looks like a test strategy and test plans and test scripts and good test data and a strong test team. But most importantly it looks like a decent amount of time allocated to testing and for that time to be guarded jealously and not squandered to compensate for other problems on a project.

In conclusion, then, poorly tested projects result in dissatisfied users and lost customers. They require lots of support once they are live and consequently have a continuous and unpopular ongoing cost. Successful projects stick to their plans, including testing, are candid about their slippage when it occurs and ensure that when the system does 'go live' it works as it was intended to. A poorly tested product offers a constant reminder of the problems with I.T. A successful project invites further development and, as software developers, that is the goal we should be pursuing.

What I Talk About When I Talk About I.T.

2009-08-05T03:40:00.000-07:00

I recently read Haruki Murakami’s book ‘What I Talk About When I Talk About Running’ on the basis that it was recommended to me by a couple of people and also because I am keen, if amateur, runner. However, much as I enjoyed the book, what really grabbed me was the title: I was really set thinking about how the subjects we pick when we talk about a topic can help us to better understand our approach to it, and also help us to think about what we do well. Of course, we can also gain by considering the subjects that we don’t discuss, although it is, of course, always harder to spot things that are missing.

That said, I know that when I talk about I.T., one thing that I don’t talk about – unless asked – is code. Unless they are complete frauds, I would normally work on the assumption that anyone employed as a developer is actually able to read and write code. Furthermore, by and large a good developer can code using different languages on a given platform, as the concepts are the same: it’s just the syntax that is different. What I am saying here is that within I.T. development, the coding should be a given.

What is important is the framework around that code. So, for starters, let’s talk about the people who do the development. I’ve already said that I’m assuming these people can write code, so what makes for good developers? For a start, they need to be effective in a team environment. I cannot emphasise this enough. For example, developers need to be able to participate in a discussion about solutions and accept that, sometimes, their solution won’t be the one that is adopted, yet go away with good grace and cheer and work on the accepted solution. I have any number of anecdotes of where a developer has gone off and done it their way, regardless of what was agreed, and for this to come back and bite the entire project.

Good developers will naturally put comments in their code - describing what they are doing - because it is implicit in their mindset that, later on, someone else will come to look at it. I can clearly remember sitting once at a code handover when a developer was leaving and, in response to a question about how a function worked, could not even find the lines in his own code.

As a team player, a good developer will accept that he is part of a process, a project life-cycle, and that as he may rely on an analyst for a clear, concise specification or a project manager to effect strong change control, so there are other developers and testers who are dependent on the punctual delivery of working code. It follows from this that the developer will focus on what needs to be delivered.

At Meantime, 50% of our resource consists of developers. Around that development function, we have project management that ensures that the user requirements have been established and agreed, and that any changes to those requirements are introduced in a manner that is controlled and avoids confusion. The project manager for a piece of work will identify the resources required and plan their work accordingly. It is this discipline that enables us to deliver our clients’ requirements on time and on budget.

Business analysts spend time with the client, discussing their business and their requirements, making sure that the work has clear – and preferably demonstrable – cost benefit and also that the proposed solution is what the client wants and needs. The results of this work will result in some documentation which comes under the term of a business requirements document. For a small piece of work this may be just an email but, at the other end of the spectrum, I have just completed one that came to over seventy pages.

Once the requirements are signed off, then the business analyst then works closely with a systems analyst who will turn the business requirements into a specification for the developer. Again, the detail in the specification will vary from project to project but it should clearly set out the functionality that must be completed for the work to be considered finished.

I will write in more detail in a future blog about responsibilities for testing and with whom they lie but once the developer has completed his own testing then – for any significant piece of work – the code should go to a system tester. Their job is firstly to ensure that everything in the spec has been delivered and is working correctly and also to test various scenarios.

Once the testing is complete, the application can go to the client for them to test in a dedicated User Acceptance Test (UAT) environment. The user should be checking that everything in the business requirements document has been delivered and also that the system is intuitive and usable from their perspective.

All of the above are things that I discuss with people, mostly client, when I talk about I.T.: the importance of understanding what the user wants, sometimes when they aren’t clear themselves; the amount of work that needs to be done before a single line of code is written; the enormous value in communication with clients (all our developers talk to our clients); the importance of developers who are highly effective team players; the discreet testing function; and the handover to clients and UAT experience before code is made live.

Generally, I define the above as I.T. culture: people, processes and practice. Where I have participated in (or observed) successful projects, the culture has been positive and powerful, celebrating its own successes and understanding where it gets things right. It is a cliché but those projects have a ‘can do’ attitude. There is a prevailing team attitude that doesn’t depend on artificial glue like paint balling or getting drunk together but rather on the brilliant momentum that is gained by working together and doing a job well.

(With thanks to Haruki Murakami and Raymond Carver.)

Why IT projects fail: an anecdote

2009-08-03T07:22:00.000-07:00

A few years ago, in one of my last freelance roles, I was in a test management role for an international investment bank. My project manager reported to a programme manager one of whose other projects was failing. Three times it had missed its implementation date and the test function had been identified as the part of the process that was letting everything else down.

Since the testing for which I was responsible was proceeding well, I was asked whether I would cast an eye over the test plans for this other project and perhaps “sort things out”. Consequently, I met with the two people who were managing the testing and spent a couple of days with them, learning about their project and the testing that they had planned and attempted to carry out.

They were both clearly competent people and they seemed satisfied with the capabilities of the people working for them. Furthermore, they had a good grasp of their project and I couldn’t find much fault with their testing (and people will approach the same task in slightly different ways, anyway). So, at the end of all their explanation, I asked the simple question: so what’s going wrong?

The explanation was straightforward and will be familiar to anyone who has been involved in testing: some dates on the project plan had slipped but the deadline had not been changed and it was the testing that had seen its time budget diminish to make up for the slippage. The testing had not been completed and the implementation had been aborted. A second run, and then a third had been attempted but each time with only a small amount of time for testing. Defects were raised but there was no time to fix them and thus the project had ended up in its current state.

I had this meeting at the end of May and there were nine weeks of testing to be done, according to the test plan. So, I went back to the programme manager and gave him the good news. There was nothing wrong with his test team, they had a good plan and the testing – including time for bug fixing – would be complete by the end of August. I said a September implementation seemed reasonable but that an October live date would probably be prudent, especially when reporting up to the board, since it was realistic and contained the possibility of early delivery.

A couple of weeks later I bumped into one of the test managers and so I naturally asked how the project was progressing. It transpired that the programme manager had announced an *August* live date and that the test team had, once again, been set up to fail.

The moral of the story is, I think, self-evident, yet you will hear similar stories from IT people everywhere. If people are not given the time to do their jobs properly, then your projects will fail and your staff will become de-motivated. People should certainly be held responsible for the timescales and deadlines they give but there is no excuse for ignoring what they say and then holding them to account for dates that are imposed upon them.

Data security

2009-07-19T13:12:00.000-07:00

Last week I was at a meeting in London with a project team from a publicly funded organisation and we were discussing how Meantime (the company I work for) would receive some data required for the initial stages of the project. One of the people 'round the table joked that they would give us the data on a flash drive as long as we promised not to leave it on any public transport.

Over the last few years, of course, there have been a number of incidents where this has happened - laptops and external drives left on buses and trains - sometimes with very sensitive data being lost as a result. Worryingly, I think that most people assume that it will happen again, which is dangerous; the acceptance that such incidents can be classed as just 'one of those things' makes people more careless.

I believe that the fundamental issue is that companies are very good at looking after data when it's where it is supposed to be. The database may be behind a firewall and access to that data may be only via an application that requires a valid user name and password from the user. The problems start when the data is extracted or reported out and stored somewhere else.

Earlier this year I had a meeting with a client who was so cautious about his data - which was, admittedly, of enormous commercial value - that he disabled his (password protected) laptop's wireless functionality before he'd open the spreadsheet containing the core data. I asked him where he backed up his data to and he produced an external drive from his laptop case. Quite apart from the fact that someone stealing his laptop bag would also have his backup, the drive was not protected and the spreadsheet, which was not itself password protected, could easily be accessed.

Similarly, data is downloaded to disks and printed out to paper reports, i.e. taken away from its secure environment, which are then being handled by people who under normal circumstances would not have access to that data.

However, there is a solution and it's one that well established, easy to use and free.

True Crypt is available for download from the web and you can read all about it here: www.truecrypt.com. And if you don't want to read all that - it is rather techie - then let me just say that I've been using True Crypt for a couple of years now and I can't sing its praises highly enough. It is simple to install and to use and means that no one can access the data without a valid password.

Another alternative is to use WinZip (www.winzip.com). While many applications will open a ZIP file, allowing the files to be seen (if not their contents) it is still possible to password protect the files.

For me, the biggest advantage is that True Crypt is able to turn a whole device into an encrypted drive meaning that if, for example, you have a flash drive that contains your business data, it cannot be accessed at all without the True Crypt software and, of course, the password required to access it.

It goes without saying that we live in an increasingly data driven society and the boundaries around our personal data are increasingly blurred. Businesses cannot afford to be anything but strict and diligent about their data protection: slip ups will certainly lead to a massive drop in credibility - either within your organisation or with your clients and customers - and may lead to legal action and a loss of business advantage depending on the data that is leaked.

Policies and procedures are essential but the use of tools like WinZip and True Crypt offer a concrete method of ensuring those practices are enforceable.

Case Study: Coniston Corporate UK

2009-07-01T06:46:00.000-07:00

I decided to choose our work with Coniston Corporate - www.corporate-embroidery.co.uk - as a case study because while the specifics of the projects are, of course, tailored to their business needs, there are some elements of the software that apply to many businesses, especially those that buy in raw materials, add some value and then sell on to other businesses or the general public.

Coniston sell workwear and other clothing, which they embroider for their customers. Driven by a very capable MD, Paul Reilly - from whom I have learnt a thing or two - the company has grown significantly yet maintained its success over the last few years. When I first met Paul, the company had a set of slick paper-based processes in place but as the business grew the overhead of maintaining the paperwork was becoming a serious overhead and also a risk to the business.

Quite apart from the concerns around pieces of paper getting mislaid and related issues around business recovery, there were some other challenges that were not easy to meet with a paper-based system:

- Ensuring that corresponding supplier orders went out to meet the requirements of the customer orders that were being received.
- Ensuring that when supplier orders came in, that the right customer orders were identified and prioritised for production.
- Reporting on margins to make sure that while Coniston offered the best price to their customers, they were making the right profit to sustain and grow their business.
- Keeping on top of their invoicing and statements, especially as customer orders were not always shipped in one delivery.

As is our usual practice, we took the time to listen to Coniston's requirements but also to understand the business context in which those requirements were set. The enabled us not only to devise the most appropriate software solution but also to deliver an application that was designed to develop with their business strategy.

Briefly, the software works like this: when a customer order is received, the items required from a supplier are automatically added to a supplier order (and the system caters for the fact that these items may come from different suppliers.) At the end of each working day, the supplier orders can be printed for faxing or sent by email, depending on the supplier's preference.

When a supplier order is received, the system identifies the customer orders that can now be processed and, when that work is marked as complete, the invoices are generated. The invoices can be printed for posting, sent as a system generated PDF by email or both.

This brings me to an interesting point. When we build systems like this, they naturally and implicitly hold information about the business itself, which is built up through usage. It is very easy for us then to write reports that the client can access whenever they want, such as number of orders this month, total and average values, comparisons with the equivalent period in prior years and so on. This is incredibly valuable business information and it is available easily and on demand without recourse to us.

It is, I think, apparent from the above, that a system that supports a business in this fashion, saves on tiresome - and error prone – administration. Furthermore, the salaries that are saved by not having to employ extra administrative staff can be seen as a method by which the software effectively pays for itself.

Incidentally, once we had the complete working database for Coniston, it also enabled us to build a dedicated site for the workwear - www.coniston-workwear.co.uk - at a relatively low cost, as well as the 'Coniston Shop' function, which gives Paul the facility to set up online shops for his clients: you can see examples here and here. Incidentally, Paul requires no input from us each time he wants to set up a new shop.

Finally, I would just say that even though I picked the above example because it contains elements that apply to many businesses, it is a source of constant interest to me how different companies ask us to implement them in different ways. Over the last five years particularly, it has become obvious to me how few business needs are genuinely met by a package solution.

Search Engine Optimisation (SEO)

2009-06-09T13:06:00.000-07:00

This post is concerned with the phenomenon of Search Engine Optimisation, commonly known as SEO. This is a subject on which I anticipate making a few more posts, so I thought it would be a good idea to start out with a non-technical trip through its meaning, history, practice and, importantly, the way in which it is sold as a service. We can start with an innocent ideal, 'ideal world' view of the topic before we have to incorporate the corrupting influence of the various companies out there selling 'snake oil'.

When search engines were first devised, their purpose was to catalogue all the information on the Internet, in order to help people locate information when they didn't know where to look for it. For the mutual benefit of the search engine, the person posting the information and the person looking for it, the idea of 'meta data' was incorporated into the web pages. This meta data consisted of a description of the page's contents as well as some 'key words' which summarised the pages content. This content enabled the search engine to better understand what the page was about, the searcher to have a better chance of finding what they were looking for and the publisher of having his content found: everybody benefitted.

However, as the web became more commercialised this altruistic element disappeared. Even before the days when the dedicated SEO companies appeared, unscrupulous web designers would aim to outwit the search engines by, for example, repeating the same word again and again in the keywords. The search engines - or, rather, the people building them - got wise to this trick and began to penalise this activity. Since then search engines have had to become far more clever about evaluating a site's content, actually examining the site in detail, rather than simply trusting the meta data. Some people will even tell you that search engines ignore meta data but this isn't true; the description is often used on the search results page and there are many people out there - who know more detail about this subject than I do - who will tell you that keywords are still taken into account, at least by some search engines.

It was as consequence of this that the phrase "content is king" became popular when discussing search engines and it is absolutely, undeniably true that if your site has plenty of relevant content then you have done 80% of the work. The other 20% is in making sure that search engines can find their way around the site in order to process and index this content and this is why elements such as site maps - which simply tell search engines where to find all the pages on your site - are so important.

It is this process of making a website accessible and easily digestible for search engines that I would describe as 'true' search engine optimisation: the site is optimised for search engines. This True SEO also ensures that every aspect of your site is fully indexed and available, via the search engine, to anyone who is looking for it. This means that all your specialisms and unique selling points are made available to your potential clients and customers.

So what's the difference between this True SEO and the snake oil version, which is promoted by these companies that profess to specialise in SEO? Well, the first thing is to look at what these companies offer. One of the first and worst signs is when they "guarantee" to get your site in the top ten on, typically, Google. It stands to reason that this cannot be guaranteed - what if eleven competing businesses hire these services - so read the small print and marvel at the number of ambiguities and get out clauses. The next thing to watch is that they offer to get your site in the top ten for a number of key phrases, perhaps two or three. So, let's say you are selling sports shoes, they might guarantee to have you in the top ten for "athletics shoes", "running shoes" and "sports shoes". If you are reckless enough to sign up, the first thing they will want to do is to remodel your site and its content to reflect these phrases. This gives search engines a skewed view of your site and takes the emphasis away from the finer detail.

A phrase that is coming into use at the moment is 'long tail' SEO and this is the antithesis of the snake oil SEO. Long tail SEO is related to the fact that a significant proportion of, for example, a retailer's sales will not be in his best sellers. (One example of this that I've read about states that less than half of Amazon's sales come from their top 140 thousand products.) This highlights the mistake of emphasising a few key products: long tail SEO is about making sure that all your products (or services) are clearly visible to search engines so they can be indexed and made available to people searching for them.

It's clear, I'm sure, from this posting that I take a dim view of these companies. Quite apart from their dubious ethics, they make our life at Meantime harder. We carry out True SEO and the results from that can sometimes take months to become apparent plus we never guarantee results. Unfortunately, these other companies lead our clients to expect the undeliverable. However, we know that a well constructed site with good content will work well with the search engines and that our clients's will appear - often in the top ten - when people search for their goods and services.

UAT: what is it for and who benefits from it?

2009-05-21T03:47:00.000-07:00

When I was first working in IT in the late eighties, I remember one site where there was a cultural revolution taking place: they were going to start asking the users (or “the business”) what they wanted from IT systems.

Implied in this, of course, is a suggestion that the business took what they were given and that the IT department dictated who could have what. The truth, though, is a bit more subtle than that. Often the business wouldn’t have a clear idea what IT systems could do for them: they had no idea of what was possible and, of the applications that could be delivered, which ones constituted a ‘big ask’ and which ones were straightforward.

Over the last twenty years, the user base in blue chip companies has become increasingly familiar with business systems and it is more common now to see the business working hand in glove with the IT department. Consequently, a way of working has arisen, which includes gathering and documenting the users’ requirements before development starts, and, once development is complete, it is now accepted (and good) practice to give the users a chance to review the new work before it is put into their ‘live’ production environment, where it will be used with their real business data. This practice is called User Acceptance Testing or UAT.

For a completely new system the UAT environment will consist of an environment which is as close as possible to the proposed new live system, so that users can learn to use the new applications. For a change or upgrade to an existing system, the UAT environment should consist of a copy of the existing live system with the new work applied to it. This enables the users to see what has changed and what has stayed the same and also to see how the new processes cope with their existing data.

A word about data: this should, as far as is possible, be a copy of the live data. However, since a company won’t, for example, want its clients and customers receiving email from a test environment, it is necessary to ‘sanitise’ the data to some degree. Similarly, live credit card details should not be moved to UAT nor should the credentials for interacting with the live database or third party systems (such as payment gateways).

UAT provides three main benefits:

Firstly, it enables the users to reconcile what has been delivered against what was in their original requirements. It’s not unusual for there to be a form of ‘Chinese whispers’ as a requirement moves between the users, the business and systems analysts and the developers. The onus, of course, is firmly on the IT people to understand and keep sight of the original requirement and, if that is lost along the way, then the business have every right to refuse to sign off the release when they identify the omission in UAT.

Secondly, it provides an opportunity for ‘scenario based’ testing. A decent IT department will carry out thorough system testing against the functional specification (which is derived from the Business Requirements Document) but it is quite possible for this testing to be carried out properly and to sign the release off as fit for UAT yet for an error to be missed. This is best explained by example: a couple of years ago, we built an e-commerce system and one of the requirements specified that once items were sold, then the quantity should be subtracted from stock. We delivered this requirement, including automatic email notification when stock levels fell below a user defined trigger point. However, it was during UAT that the client pointed out that in order to minimise their costs, they held as little stock as possible, often ordering the required items in only after a customer had ordered them. Consequently, we had to amend the system to allow for negative stock values.

This brings me nicely to the last of these main benefits: less live fixes. If, in the example above, we had not had a user acceptance test, the client's business would have ground to a halt as many items would have not been available to order (as there were zero items in stock). The resolution to this problem was simple enough and took about half a day to apply. That half a day didn’t seem much when the client could be off testing other aspects of the system in UAT but it would have been a very different story if their business had lost half a day’s sales whilst we made the change.

So, who does benefit? As the points above illustrate, I believe the answer is everyone. The users have a huge amount of reassurance that their requirements have been met, without the stress of seeing the work for the first time in a live environment. Where issues do arise, they know they are low impact, affecting only test data and not the live business operation. From IT’s point of view, the department ends up with happier, better serviced users and, crucially, a minimum of high-pressure, risk laden live fixes with the business (understandably) demanding regular updates.

At Meantime, we are often working with users who don’t have blue chip experience but there is no reason why we shouldn’t use our experience and bring the good practice of UAT to our projects. The concept is easy to understand both in terms of execution and benefit, and our clients quickly grasp it. Ultimately, this simple step in the project life-cycle takes away a whole load of the stress and aggravation that is associated with IT delivery.

Case Study: Entrust Social Care

2009-05-03T13:03:00.000-07:00

To make any case study worthwhile, it needs to highlight one or more salient points about the service that it is intended to illuminate. I'm starting with this particular case study because it demonstrates three important characteristics of well built bespoke software:

1. It has a clear cost benefit.
2. It improves the way in which the client's business is run.
3. It provides management information about the processes that it manages.

The client in this case is Entrust Social Care, whose website can be found at www.entrustsocialcare.co.uk. The Company provides temporary Social Workers (Locums) to the Public Sector across the UK, who in turn approach Entrust to satisfy their staffing requirements. One of the most important parts of Entrust's business is making sure that the locums are paid promptly after submitting their timesheets.

The locums are paid for the hours they work (sometimes working for different clients in the same week), for their expenses and they are also awarded bonuses. In addition to this, they might opt to take time off in lieu. Each week, the MD at Entrust, Ian Brindley, would process the timesheets submitted by the locums, using Excel to calculate the payments and track the time worked against bonus goals. It was a time consuming process and it was what Ian spent the Thursday and Friday of each week doing. It was boring work, yet vitally important, which is a poor combination. Furthermore, Ian didn't feel able to delegate the work out to his staff.

Ian and I had worked together at JPMorganChase in 2000, and he approached me to ask whether Meantime could do anything to help ease his situation. He explained that his business was developing well and that he was generally very happy: the only fly in the ointment was this weekly business with the timesheets. We spent some time talking to Ian about his business, the specific issue and about possible solutions.

This done we then designed a database that would store the details of both Ian's clients and the locums who were working through him. Over this we laid an administration system that would enable Ian to add and maintain this data. We then repeated this process, adding the relationships between the locums and the Social Work Teams in which they were placed.

The next step was to provide Ian with an easy to use interface where he could select a locum, choose a location where they were working and then enter the hours worked, expenses et cetera for a given week. Finally, we provided the function to produce a report of all the payments required for each locum.

As a consequence of this work, using the same inputs and providing the same outputs, we reduced the timesheet processing from two days to two hours (which is how long it took to type in the data). Additionally, we were able to provide valuable data from the system, simply because the relevant part of Ian's operational data was being processed by it. At the press of button Ian could access powerful business information regarding the number of contracts he had in place, the number of clients and locums he had on his books, plus vital financial information.

So, to summarise, let's look at those three points again:

1. The system has a clear cost benefit. Timesheet processing was taking up every Thursday and Friday, i.e. 40% of Ian's working time. Whilst I'm not privy to what Ian pays himself, I know that the cost of the software was less than two-fifths of his salary and, furthermore, it was a one-off cost.

2. The system improves the way in which the client's business is run. Once the system was in place, Ian suddenly had an extra two working days available in his week, something that would be hugely attractive to any Managing Director. This gave him more time to grow his business plus the confidence that he could manage the additional workload.

3. The system provides management information about the processes that it manages. Without even consulting Ian, common sense would have enabled us to provide useful reports to Ian. In addition to those mentioned above, we were in a position to answer questions like Who are my best clients? How much have I paid out to locums this quarter? Which care clients appear to be using more or less of my services over time?

All businesses are different and that is why they need bespoke software for their IT solutions. For those solutions to be effective, the businesses need to pick suppliers who are demonstrably strong when it comes to business analysis: there is a lot of work to be done before the first coding keystroke takes place. The Entrust project is a great example of how, by listening to the client and working with him, we were able to provide a solution that exactly matched his requirement.

Why bespoke software? (And how to tell if you need it.)

2009-04-25T14:52:00.000-07:00

As I’ve mentioned previously, the most obvious reason to develop bespoke software is that you have a requirement that isn’t fulfilled by any package that is available. However, there are a couple of subtle refinements to this argument.

Firstly, there may well be software that is available to you but either it doesn’t work in quite the way you want it to or perhaps it is too complex. Last year we took on a client who was paying £14,000 per annum for a package that handled their e-commerce and stock management. They had decided to put a budget of £28,000 towards a bespoke solution on the basis that they would be saving money after two years. When we saw the feature rich package we made it clear that we could not duplicate all the functionality we were seeing for the budget available but the client quickly put us straight: they only wanted about a third of the functionality but they wanted it to work in a way that made sense to them and the way they worked.

And this brings me on to the second refinement. Typically, in any location, there will be many companies operating in the same sector and some of these will be more successful than others. This may be down to crude distinctions such as cost but over time the biggest differentiator will be down to the way in which each company operates and interfaces with its clients/customers and suppliers. For some elements of that business – payroll, for example – the software that is used will make no difference to a third party’s experience with the company. However, the software that is part of the process is a different matter entirely.

Over the next few days I will put up three posts that detail case studies that I believe illuminate the point that I am making here. However, here are a few indicators that will show if you could benefit from bespoke software.

1. You find you are entering the same data in multiple locations. Many mature companies with quite sophisticated processes find themselves using multiple spreadsheets or a number of software packages. This means the same data needs to be entered in multiple locations and if that data should change, then someone needs to know all the places that it needs updating.

2. Your processes are very ‘paper driven’. It repeatedly surprises me just how far companies can get with almost completely paper-based systems. These can work well until a piece of paper is mislaid or, worse, there is an incident such as a fire, which completely destroys the system. Goods and property can be insured but data is irreplaceable if it is not kept safe and backed up. All our software is web-based and all our clients’ data is backed up every day.

3. Your processes rely on your staff knowing them. That might sound obvious – of course your staff need to know what they’re doing - but there is not only a training overhead involved here, it also means your staff are less flexible and less able to cover for one another. A good IT system should reflect the way your business works and so your processes should be implicit in your software. A package will dictate that process and impose it on your business.

4. You want to share data with your clients. But not all your data, of course. Web-based bespoke software enables your clients to log on to your website and see their data: orders, statements et cetera. This cuts down on calls to your staff.

Ultimately, well-written bespoke software should provide huge benefits and give a great boost to your company. Your day to day business should run like clockwork, with happier clients and customers, less stressed and more flexible staff, who will be free to concentrate on their jobs and not administration. What’s more, having all this operational data in once place provides enormous opportunities for extracting highly valuable management information about the way your company is running.

So, what's the point?

2009-04-13T10:23:00.000-07:00

I started a limited company - Meantime IT - in 1991. Initially, it was simply a vehicle for my freelance work with a number of blue chip companies and I was the sole employee. However, in the mid-nineties my brother, Warren, and I became interested in the emerging Internet platform and started developing websites. However, we were both frustrated by the limitations of the medium and continued with our day jobs while working on those sites in our spare time.

As the web became more viable as a platform, we planned to make web development our full time occupation but then Warren went to work for Goldman Sachs and I went on to work for the Royal Bank of Scotland, managing the testing of the first 'thin client' version of their Internet Banking software. In 2004 I finally took the plunge and Meantime IT has been running as a software house, working exclusively on the web since then.

However, there is a major difference between working as a limited company to facilitate freelance IT and running an SME out in the real world: as a freelancer there are plenty of agencies out there, taking requirements from their blue chip clients and matching them up with the CVs they take in from contractors. For an SME, especially in today's economic climate, things are a little different. It's one challenge to put together a company that can successfully deliver working IT systems but we also need to tell people about it. Hence, this blog was suggested as part of our marketing strategy and, after my initial reservations, it occurred to me that this would also be a good place to lay out the conclusions of some of our discussions at Meantime.

So, that's the point of the blog but maybe this inaugural posting would be a good place to also ask what's the point of IT? It is a big question but, for further postings to make sense, I think it's one that needs to be asked up front. To be clear, I want to break IT into two categories. (Like many black and white statements, it won't bear close scrutiny but in such a complex world as IT, I'm going to need to take a few shortcuts.)

Firstly, there are packages. I'm using this term to define any software that is built by a company and then released to a target audience. I'm not suggesting there won't have been market research or that the software won't be configurable. Examples of this would include Microsoft Word, Apple's iTunes, Intuit's Quickbooks and Twitter.

Secondly, there is bespoke software, which is what we build at Meantime. This is software that is built for a client to their specification (and the variability in those specifications will be the topic of a future posting). It is really this second category that earns IT a bad name. People may grumble about new releases of package software - Vista is a good example of this - but, by and large, they will work as the authoring company intended. The failing projects that make the news - e.g. apparently anything that is built for the National Health Service - all involve bespoke solutions.

So, if the package solutions work, what is the point of bespoke software? Package solutions do indeed work perfectly when you have a generic requirement and everyone is happy with the same solution. iTunes and Microsoft Word are both good examples of this, as evidenced by the fact that both have made it across a partisan divide: iTunes onto the PC and Word onto the Mac. Even in the world of business, we see package solutions that work but already there is more variation as people buy solutions that are geared up to their size of business and their sector.

The key here is that if you use a package solution for a particular process then you will be carrying out that process in the same way as everyone else who uses that package. This is fine for, say, your payroll but what about those processes that help distinguish your company from the competition? Or what if you have a requirement that is quite specific and, therefore, the target market is too small to warrant a package, so no one has built one?

The key point here is that there is a strong market for bespoke software: people do want and need it. The problem is that so often what is delivered is often very flawed. Common problems include:

The software that is built does not satisfy the initial requirement
The costs often exceed the allocated budget
What is delivered arrives late and is out of sync with the business

All of these issues are bad enough in themselves but further contribute to a mistrust and dislike of the software.

We have seen four decades of development of IT systems yet these problems have never been resolved. There are many books, seminars and theories all circulated which purport to solve the issues and yet matters never seem to improve. I believe that the underlying contributing problems are simple to understand and over the last five years, Meantime has successfully delivered projects that match our clients' requirements, on time and on budget. That is not to say that we haven't had challenging projects, too, and those occasions have only served to demonstrate that the processes to which we usually adhere are absolutely essential.

There is no secret ingredient, no single process that we have up our sleeves. The methods, processes and procedures we utilise require work that many companies and, crucially, developers do not wish to adopt. I will be outlining all of them in future posts, highlighting the perils of ignoring them with examples from industry and, no doubt, the day's papers.