Rocket Science - The Problem with in-house corporate web development

• Author: Matthew Jackson
• Comments: No comments

When you’re running a big company it makes an illogical kind of superficial sense to have your website built by your IT department and your digital strategy developed by your marketing team.

After all, IT knows computers and the marketing team should know how to sell.

So, why go through the extended hassle of sourcing a competent digital agency when all of the skills are present in-house?

Well, while IT definitely knows computers they don’t necessarily understand the web. IT is about making Information Technology work – networks, servers; that sort of stuff.

Sure, most IT guys can build a website and do understand the underlying technologies. Unfortunately the difference between a website that works and a website that does what it’s supposed to is more than a hair’s breadth.

You see, building websites is easy. If you take a day or two out of your life to learn some code you should be able to build a site that works. It’ll have a banner, links that go where they’re supposed to, a couple of images and even a contact form if you apply yourself studiously. If you’ve got a little bit of a creative flair you might even be able to make it look half decent too.

Building a website that does what it’s supposed to is a different bunch of bananas – not just any monkey can do it. There’s more to developing a site than simply slapping together some code and hacking in some images and copy.

A good website is designed to be easy to use and to facilitate conversions. This basically means that content, design and code all need to work together seamlessly to give your users what they need and to push your bottom line.

So here’s the major problem with developing corporate websites in-house. The people sitting down and designing the company website are not web people. Think about it: people with a burning passion for web end up working for web companies. They don’t apply for positions at their local corporate entity. Yes, there are the occasional exceptions to this rule, but nine times out of ten it’s bankable.

“But,” you might say, “my IT guys are good at what they do, in fact, they did all of this web stuff in college and they know a hell of a lot more about serious programming than you do. So where do you get off telling me that using them to build my corporate website is a bad idea?”

Well, it’s like this: web design and development is not an exact science. The technologies are constantly shifting, as are the methodologies we use to obtain conversions. What were great ideas three years ago are often fatally flawed today. So, while it’s completely plausible to have your IT team develop your site, there’s an excellent chance that they will not be abreast with current coding methodologies and best practices.

To illustrate the point, I’ll tell you a little about my last corporate client. I was hired to develop content for the company on a freelance basis. Every month I was required to develop copy relevant to their industry for two online magazines. To be honest, it was a fairly good gig. I could choose my topics within reason and the team I was working with was generally quite helpful.

When I accepted the job, I had a look at their offering. The analytics looked promising at a glance and the service they were providing was one was one which is always in high demand. On the surface the project looked like a surefire success, but there were some pretty serious flaws in the strategy.

Let me explain:

The company had decided to target their services to a number of niche markets based on a content model marketing strategy. To service these markets they built one underlying template on a content management system known for its cumbersome, bloated and difficult-to use publishing workflow, then they deployed the system over sixty different domains.

All sixty sites were rolled out at the same time without much difference in their design or offering. Now, while I was working on the project I was writing about twenty-five articles per month to be published on two of the most promising sites. I was the only writer working on the project, so the other fifty-eight sites were left to languish without fresh content for the period of my engagement in the project.

Needless to say, the project started to tank quite quickly. The sites without fresh content experienced abysmal traffic and conversion rates were horrible.

If you’ve ever been involved in a project which was not performing to its true potential, you’ll know how disheartening the experience can be. In an effort to avert the project’s inevitable crash, I sat down with Greg, our developer, and went through the offering’s code, usability and persuasion architecture.

The code was a nightmare. The sites had been developed using archaic coding practices and, when we plugged the sites into the W3C Validator, we encounted over two-hundred errors on the home page alone. When we looked a little deeper we also found flagrant bad-practices on the SEO front, including keyword stuffing and terrible linking practices.

Usability wasn’t much better. Information was fragmented and difficult to access from the primary navigation structure. The project’s primary tools were cumbersome, difficult-to-use and downright frustrating. To make matters worse, the site was targeted at two specific user groups with very different usability requirements. Instead of creating targeted user groups, the company had decided to give all users access to all of the tools which made using the site an incredibly daunting process.

As far as this project was concerned, persuasion architecture was a concept that either didn’t exist or was a tool used by amorous architects.

After our in-depth assessment of the project, I presented our findings to the company. Our suggestions were radical. We wanted the plethora of sites consolidated into one targeted offering. Our rational for this was simple: bring your content requirements down to sustainable levels and reap the SEO benefits of an agile, well thought-out site.

We wanted the code of the site aligned to current standards levels and we wanted the usability issues addressed throughout the offering.

We wanted the publishing process to be streamlined and largely automated.

We also proposed a long-term strategy to develop key differentiators to enable the project to succeed in a highly competitive market.

To say that the meeting was a disaster would be somewhat of an understatement. I ended up having to listen to people justify their poor decisions, strategy and development using arguments which only made sense if you had no understanding of the medium.

In all fairness, I understand their position. They were sitting in a meeting with their boss and some know-it-all-kid who was telling them that they had spent a year developing a turd which would never take a polish.

In a situation like that there’s bound to be a fair amount of arse-covering.

However, when you start to look at in-house the costs involved in a project like this the mind starts to boggle. I have no idea how many people were employed to make the project happen, but I dealt with three individuals on the content side of things. On the marketing side there were another two. I know that there were at least two people involved in the development of the site too. I never met any designers but there must have been at least one. Even if each of these individuals earned an entry level salary of R7000 a month, which I doubt based on the number of iPhones witnessed in each meeting, you’ve got a base operating cost of R56 000.00 per month. That figure doesn’t even consider Freelance rates or any actual marketing or maintenance costs.

When you start to realise that the end result could politely be called a white elephant; that my estimates on running the entire project are on the extremely low side, and that developing the site properly, the first time around, would have cost a fraction of the total running costs for a year, you start to understand why in-house development is a bad idea.

What compounds the problem even more is that the holding company has identified the digital realm as an arena crucial to its continued growth. That means that they are going to have to deploy a strategy and site offering that works in the future. In the interim, they’ve wasted a year and a hefty chunk of change trying to break into a highly competitive market.

We now have to ask ourselves if the people who developed the offerings are the ones to blame for this monstrosity. In my honest opinion, without knowing the full dynamics of the situation, they’re not. Here’s why: The success of any project depends on the skills, competencies and experience of the people involved in the project.

So, in the case of the developers, they could obviously code but were not up to speed on the differences between good web code and bad code. With one experienced web coder on board, the site could have easily been developed according to best-practices. The same thing goes for the niche strategy, if one person on the team knew what constituted an agile and sustainable digital strategy and how the users of a site need to be treated to get them to engage, the project would have had a much higher chance of success.

I guess what I’m trying to say is this: if you want something done properly, hire people who know what they’re doing. If you insist on utilising in-house skills to develop your site, think about hiring a consultant to guide the project instead of expecting your current staff to magically develop skills that take years to cultivate.