The DIY Dilemma

- Understand the risks before you attempt to build your own software - By Richard White, Chief Executive Officer of logistics technology solutions provider CargoWise and technology development company WiseTech Global


Logistics service providers (LSPs), have a deep understanding of a particularly complex sector of the economy: logistics. They understand customs and trade routes, and have the interpersonal and intercultural skills to deal with customers and agents all over the world. They must be constantly focused on the immediate needs of their customers so they can best build and evolve efficient business models to stay competitive.


But that doesn’t mean that they are best placed to design the software they need to run their businesses. There are a couple of simple reasons why DIY projects in this, and most other sectors, almost always end in disaster.


The first is that the development and support of excellent software requires people within a very particular culture, who have a set of very sophisticated technical and team skills that require a deep understanding of this deeply complex art and science. Finding these people is challenging for any business; but keeping them is nigh on impossible – especially if you cannot offer them a constant stream of stimulating challenges. The principle reason is that IT developers tend to prefer to work inside technology businesses where they can work within teams that understand the peculiar challenges of software design. The way these companies build their teams and engage their people is manifestly different from the way most companies operate. The focus on creativity makes them culturally unique in the corporate world.


The challenge of attracting and retaining IT people is something LSPs know well. Good developers need to work with the leading edge of technology all the time because they’re naturally curious and professionally want to keep their skills relevant.


Because of the nature of the industry, LSPs need to be focused on shipping goods around the world and keeping their customers happy. The processes they create to run their companies, while perfect for LSPs, can be disastrous, however, when applied to software design.


Although LSPs know their own industry extensively, they necessarily see their challenges from their own unique, but narrow perspective; and as a result, will often commit the mistake of hard coding inefficient practices into in-house software, simply because they don’t have the time or the visibility to do things differently.


To be effective, software design needs to go deep into ‘core problems and opportunities’ and replace existing business practices with better, faster and more efficient ways of doing things. Internal software development projects are usually weighed down as developers are tasked with coding to the level (or slightly better) of pre-existing systems and work practices. Good software design seeks to solve deeper problems and create entirely new, more efficient processes.


LSPs risk spending vast amounts of time and money creating software which is at best “similar to the currently available” and at worst, far behind what is readily and cheaply available.


Software projects can become so vast and complicated that they suck all the oxygen out of the rest of the businesses. We had one customer take it upon themselves 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 dollars to create something they could have bought “off-the-shelf” for approximately $200,000. During this time the business went from being a highly profitable operation to bankruptcy and a forced sale. And this unique scenario is far from unique.


I have personally witnessed more than 20 software development projects by customers and potential customers over the past 10 years – the vast majority of which 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. And, the few that were delivered, failed to compete with software that is already available “off the shelf”.


Software design and manufacturing isn’t easy, and the appalling track record most LSPs have when it comes to delivering internal projects on time and on budget is a clear demonstration of how often in-house development is fraught with challenges.


And even in the rare cases where an internal software development project results in functional software, the rapidly evolving nature of the industry requires that the underlying software is constantly improved and upgraded. New legislation, 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.


Software is not like a fixed asset you can set and forget about. To be effective, software needs constant attention, and upgrades for both technology and compliance standards. This means that your business will not only be distracted for the duration of the software’s initial development and rollout, but you will also need a software development team to constantly engage with the business as challenges and demands continue to evolve.


So next time your IT department comes to you with the idea that they can develop the software you need to get through the next challenge – ask yourself how much you’re willing to risk to create a system which will only ever be one step behind what you can buy?


comments powered by Disqus