How to avoid DIY disasters: Industry expertise won’t automatically translate into software skills

While you’re taking some time out to read this article, across Europe more than 10 million people are working hard to ensure every other business gets access to the goods they need in the fastest, and most cost effective way possible. Transport and logistics companies are so good at what they do that goods and commodities are carried over vast distances, across international borders, and through multiple checkpoints for a tiny cut of the final price. For most consumer goods the cut to the retailer for stocking the shelves is three or four times the cut which goes to the transport companies which got to the goods there in the first place.

And there’s a very good reason why those in logistics sector are so good at what they do: They get a lot of practice. Getting goods from A to B is their core skill, and needs to always be the main focus of their operation.

Success in the transportation and logistics sector requires huge amounts of knowledge about customs and trade routes and the cost and management of transport systems, as well as the interpersonal skills to deal with customers and agents all over the world. To be effective these companies need to be constantly focused on the needs of their customers and know how to build, and constantly evolve, a business model that will help their customers to remain competitive.

Unfortunately many of these same logistics and transport companies assume that because they have such a deep understanding of their own business, they also understand how to codify what they do into software and IT systems.

However, one doesn’t necessarily follow the other. Knowing your industry and processes does not mean you will be able to create effective software. This is because creating excellent software throws up challenges that are totally different to the ones logistics companies encounter. In fact there are few, if any, skills that are directly transferrable from one sector to the other.

Moreover, making a foray into software design and development almost always spells disaster for logistics and transport companies.

The most obvious reason logistics and transport companies struggle with the development and support of excellent software is that software and technology companies require a very particular culture if they are going to succeed. They need to attract and retain people who have a set of very sophisticated technical and interpersonal skills, as well as a deep understanding of software coding which is essentially a complex combination of art and science.

Finding good IT staff is challenging for any business; and keeping them is almost impossible in any other sector outside of software development and technology focussed companies.

Highly skilled programmers tend to be highly intelligent and passionate individuals who require a constant stream of stimulating challenges. And it’s a simple fact that they tend to prefer to work with technology-focussed businesses where they can operate within teams that understand the peculiar challenges of software design.

The way software companies build their teams and engage their people is manifestly different from the way most companies operate. The focus on creativity makes software companies culturally unique in the corporate world. Highly skilled developers invariably tend toward roles where they can work with the leading edge of technology, because working with the latest and greatest software or systems feeds into their natural curiosity and enables them to keep their skills relevant from a professional point of view.

Essentially software developers are most comfortable working alongside other software developers because they all speak the same language.

As a result there isn’t a single industry outside of information technology which doesn’t struggle to recruit and retain IT staff, and the challenge of attracting and retaining IT people is something logistics and transport companies know well.

Logistics and transport companies need to be focused on their core business – shipping goods around the world and keeping their customers happy. The processes they create to run their companies, while perfect for the logistics sector, can be disastrous when applied to software design.

Each and every transport and logistics company sees its challenges from its own unique, but narrow, perspective and internal software projects will often involve hard-coding inefficient practices into software, simply because they don’t have the time to analyse and reinvent these processes.

To be effective, software designers needs to have the opportunity to dive deep into the core problems, and constantly look for ways to replace existing business practices with better, faster and more efficient ways of doing things. Internal software development projects often go off the rails when software developers are tasked with coding pre-existing systems and work practices; they are not allowed to be creative, and as a result often produce a suboptimum result. Good software design, on the other hand, seeks to create entirely new, more efficient, processes and then use these as the basis for their code.

As a result logistics and transport companies spend vast amounts of time and money creating software which is at best a reflection of their current systems, and perhaps the equivalent to the least effective software currently available. In many cases the software written internally is more costly and less effective than readily available software packages.

The real danger however is that software projects can become so vast and complicated that they take all the oxygen out of the rest of the businesses. We had one customer attempt to develop their own cutting-edge web-based order and shipment tracking software. The project got out of control, and sucked resources from the rest of the business to the point where it took years and millions of pounds to create something they could have bought off-the-shelf for approximately £130,000. During this time the business went from being a highly profitable operation to bankruptcy and a forced sale.

And this kind of scenario is far from unique.

I can personally remember more than 20 software development projects by customers and potential customers over the past decade, and the vast majority of these have ended in disaster. Only one such project delivered a viable product, all have taken much longer than anticipated, many were terminated or failed because of cost overruns, and none were brought in on time or on budget. The few that were delivered failed to compete with commercially available software products.

Software design and manufacturing isn’t easy.

The poor track record most logistics service providers have when it comes to delivering internal projects on time and on budget demonstrates just how difficult it can be.

And even in the rare cases where an internal development project results in functional software, the rapidly evolving nature of the industry requires that the underlying software is constantly improved and upgraded. Software is not like a fixed asset you can set and forget about. New legislation and changes in technology (such as new mobile platforms and innovative operational changes) all need to be integrated into underlying software systems if a company is going to keep up with the competition, let alone take the lead.

In order to be effective, software needs constant attention, and upgrades. This means your business needs to be prepared not only to focus much of its energy on software development for the duration of initial project and rollout, but constantly be directing skills and resources to the software as challenges and demands emerge.

If it’s all starting to sound too hard there’s a very good reason – it’s because software development, like logistics, is a highly specialised field, and best handled by specialists.

So before you go to your IT department and ask them to spend vast resources and time developing software which will at best only just keep up with what’s already on the market, seriously ask yourself what impact such a project might have on your business. Because if software isn’t your core business, how willing are you to risk your business in order to complete a project which does not even vaguely fit into your area of expertise?

Some projects simply aren’t worth the risk.