Posted on Mar 22, 2012 in Technology & Analytics | 0 comments

I recently spoke to several publishers at Publishing Expo in London about their content management systems, and a few gave me the usual sad story about trying to build a newsroom in-house. This is more than a “build vs. buy” issue, especially for newsrooms where the CMS is critical to the entire business operation. Failure in the newsroom is not only expensive, it can spell disaster for the company as a whole.

IT project failure rates are the stuff of legend. The Standish Group, a Boston-based IT consulting firm, is famous for its annual CHAOS Report, documenting IT project failure rates (which hover around a shocking 30% success rate, with over 2/3 of the projects “Failed” or “Challenged” according to the report criteria.

Standish Group Chaos Report

Statistics like these are well known to the IT and bespoke development community in the corporate IT world. But lessons from corporate IT don’t seem to have trickled into the publishing world, so let me offer a few insights into project failure and why you don’t want to build your own newsroom.

First, newsroom systems are complex pieces of software; they are not simple document management systems of the kind a clever IT organization could reasonably be expected to design and build. Today’s newsrooms manage workflow, multimedia management, complex information architectures, analytics, multi-platform delivery, social media integration, and a host of other features that make them pretty complicated machines.

But instead of going into the complexities of these systems, the more important insight is in understanding the difference between software developers and IT staff.

A software developer is an engineer; they are trained to design and build software. IT professionals are trained to install, manage, customize, and integrate software, but they are not trained to conceive, design, and build it. The best analogy is from the automotive industry: software engineers are like automotive engineers, the folks who design cars and motorcycles for manufacturers. IT pros are mechanics, the folks who repair, maintain, and sometimes modify the cars and motorcycles designed by automotive engineers. Software engineers generally go to college to learn engineering or computer science. IT staff may well have engineering degrees, but many are vocationally trained.

Now, before I offend IT professionals any more than I may have already, let me explain a bit more about my experience with IT, and at the end of this post I’ll also explain why I added motorcycle engineers to my analogy.

IT staff are trained professionals. They often get a bad rap because of the high rates of IT project failures, but in my 20 year experience, they are rarely to blame. The real culprit tends to be upper management who, not recognizing the difference between software engineers and IT professionals, place both groups under one “tech geek” umbrella and hand jobs to their IT pros that they are simply not trained to accomplish (like systems design).

Keep in mind that the tech staff at publishing companies are almost always IT staff, they are rarely trained software engineers. The in-house IT folks know a lot about the business, and a lot about systems, and they are often just itching to rise to the challenge. And on occasion, the really talented ones do, sometimes, pull it off.

Software engineering, like any professional discipline, is made up of a number of specialties: user experience design, database architecture and design, back-end systems development, front-end user interface design, information architects, and analysts that model business processes. IT also has their own specialties: systems integration, software installation (including maintenance and customization), database optimization, not to mention networking and security, datacenter and server management, desktop support, and a host of other technical specialties.

One group is not better than the other. They are just very, very different. And it is almost inconceivable that a single person would know all the specialty areas of these professions. Back-end software developers are notoriously bad information architects and user experience designers. Datacenter managers are rarely adept at gathering business case requirements. (Software engineers are usually terrible at gathering business case requirements as well; that’s a job for IT analysts or good software product managers.)

If you can’t reasonably expect someone to master all the specialties of either profession, you certainly can’t expect them to master the complete field of both professions. So even if you have a talented IT team, they aren’t likely to also serve as a software engineering team. Nor are most software engineers particularly good at IT (in fact most are terrible at it).

If you want software that is designed properly, you need to hire a cross-functional team that is actually trained to build software. That’s why you should buy software from reputable software vendors: they employ specialists to do specific jobs, from design to development to QA to installation.

This is the crux of the old “build vs. buy” issue. Do we buy software, or do we have our staff build it? The answer is, do you have software developers on staff? In the news business, most companies hire IT staff, not software developers, simply because they need IT staff and not software developers. Software is about creating something new. Newsrooms don’t generally represent enough product-level innovation to justify hiring software developers.

So for newsrooms, build vs. buy is really not about building a system in-house vs. buying it from an outside vendor. If an organization cannot afford for the project to fail, then the only real option is whether to buy software or have it built by software engineers. If you decide that your specific business requirements are so unique that you must build it yourself, then you have to hire software engineers: either contractors from a professional bespoke development firm, or folks hired onto your own staff.

And what publisher (1) knows how to hire a real software development team or (2) really needs something so unique that they couldn’t buy it? Three years ago professional newsroom systems were hard to find. Today they are not.

Now here’s where the motorcycle engineering analogy comes into play. In 1983 a man named Erik Buell began building racing motorcycles using Harley-Davidson engines. He started out as a mechanic, and worked his way through University of Pittsburgh to become an engineer. Buell became famous for his racing customizations, founding the Buell Motorcycle Company, which built racing bikes using both manufactured parts and Buell’s own chassis and component designs. He started as a “mechanic” but crossed over to become a “design engineer.” Eventually Harley-Davidson bought the Buell Motorcycle Company and brought Buell into the mainline engineering manufacturing side.

Buell crossed over from mechanic to engineer. And IT staff can, and do, cross over to software engineering. Which brings me to the most important point: some of the most talented people I know are those “Erik Buells”: crossover IT staff who became software developers. The best have a rare combination of entrepreneurial vision, IT systems expertise, and the ability to understand how software is made. They are rare. They are the most valuable technical staff any company can have. So if you are lucky enough to have “Buells” on your team, hold on to them; they are gold.