Latin America Trade
View Issue #586 Now!
The DIY Dilemma
By Richard White, Chief Executive Officer of logistics technology solutions provider CargoWise and technology development company WiseTech GlobalLogistics 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 be
American Journal of Transportation
116 Court Street, Suite 5
Plymouth, MA 02360
© Copyright 1999–2014 American Journal of Transportation.All Rights Reserved.