I am frequently reminded of the story of the building of the railroads of the United States and the first transcontinental railroad originally known as the Pacific Railroad and later as the Overland Route. This amazing feat of engineering was a 3,100km of contiguous railroad line constructed over a period of over 30 years to connect the Pacific Coast from San Francisco with the existing Eastern US Rail network at Council Bluffs, Iowa. 30 years, would we tolerate that today?
If the transcontinental railroad project was going to be a failure, how long would it have taken before the project leaders realized they were going to fail?
Today we won’t tolerate an IT project that takes 30 years to implement. Getting to a failure result faster is a prerequisite in today’s fast paced world. It is what Eddie Obeng refers to as smart failure.
The feat of the transcontinental railroad was amazing not because of its duration but by virtue of the fact that it was undertaken by three companies, the Western Pacific Railway, the Central Pacific Railway and the Union Pacific Railway. They were three independent and autonomous entities. Aside from all the political machinations, the territorial squabbles, the enormity of the costs and the logistics nightmare that the whole endeavor represented in the end the joining of the lines was completed in 1869. A project manager of the day may well have had some choice words to use regarding the journey he took in the project but the project was ostensibly considered a success.
Implementing the railroad brought uniformity, a standard gauge of 1.435m, a standardized telegraph system and standard time. The unification of the railroad actually also facilitated the introduction of standardized time zones so all the railroads could schedule their trains, something that would subsequently be recognized by US Congress.
In the context of a multifaceted SAP facelift or integration project things are not so dissimilar. Converging on that single system of record often targets the elimination of duplicated technologies, effort, system sustainment and support models. Instead of leveraging a multitude of technologies and methods to achieve optimal business efficiency a set of standard practices are adopted and adhered to.
We see a lot of this with Winshuttle customers particularly those who have SAP as a core system of record. They will choose ABAP first and then look to newer approaches second. They do this using largely proven and established tools and technology but perhaps in a different way but a lot hinges on the experience and comptency of the individuals. This is perceived as a relatively low risk approach. New technologies, essentially unproven, carry higher risk, but that’s an assumption that is based on belief not empirical evidence. The conservative sponsor will go for proven technologies; the more liberal sponsor will take a risk on something new and innovative if it holds the promise of aligned benefits.
The conservative sponsor agrees then to engage the services of one or more vendors together along with their own staff to build the solution that holds the promise of improved operational efficiency and process effectiveness but sometimes it fails miserably principally because the technology comes with a number of basic assumptions which are technology constraints and these are misaligned with the business objectives and requirements. The same business sponsor then doesn’t understand why the technology is so inflexible.
You have to consider that it is pretty astonishing that the supposedly standard systems can be implemented today with disparate groups using technology that is hardly innovative and yet still fails to meet the fundamental business expectation. Recent big examples of this include the disastrous MyCalPays implementation and the Australian Northern Territory Government’s asset management system revamp. These were likely considered relatively safe
projects when they were launched. In both projects, the challenges were many, from general questions about SI resource competency, to a lack of requirements and capability understanding, change management issues and probably most significantly, long lead times on deliverables. Changing resources and integrators midstream likely added to the problems.
On the other end, there is the maverick implementation that is tacked in a non-standard way and effectively uses custom solutions or new technologies that are not well understood or internally supported – this puts tremendous project risk into the mix, depending on the maturity of the organization, the age of the core ERP system, the stability of business and the level of in-house technology capability.
When you look back to the transcontinental railroad, it was a shiny new behemoth built by veteran railway men who had seen many challenges in the past, had a legacy of infrastructure and wanted to extend and build something better than what they had. They couldn’t change the entire network, but anything new that they built was built with a vision and with a plan, a lot of what they used in the new venture was new and revolutionary like the new standard in rail width and the use of steel I beam rails sourced domestically. Many things could go wrong and undoubtedly many did, from wrecked shipments from the East coast around the Cape to San Francisco to manpower, geology and funding issues.
Similarly the Shinkansen high speed rail network in Japan required a rethink of the way railways need to be built. Early successes with the Tōkaidō new trunk between Tokyo and Osaka, principally for the 1964 Olympics meant that subsequent network expansions were willingly embraced. But then things went awry and the railroad companies involved effectively became bankrupt. Further extensions were made to Hiroshima and Fukuoka and were completed roughly ten years later all built with revolutionary designs and engineering aspects despite the bankruptcy. The point here would be that early failures would likely have resulted in the projects being scrapped or pivoted. Long implementation projects have to be viewed as a bad thing.
In the context of all this, Winshuttle views itself as a ‘better way’ to integrate ERP and enhance business process standards and a better way to implement business transformation. Winshuttle accepts that you have a legacy of infrastructure, it understands that you’re looking to improve on the status quo and you want to be able to do it quickly and effectively without making too many compromises and without the risk of bankruptcy. The technology being brought to bear is also not so much revolutionary as proven and you get to implement it yourself.
On the integration side, Winshuttle has spent ten years working with more than a thousand SAP customers proving that they can interact more effectively with SAP with the tools that they already have. In the workflow space hundreds of customers can attest to the fact that Winshuttle’s workflow solution quite quickly gets your solution up and running with a minimal amount of effort in the implementation stage. Most important in all this is the ’quickly’ part with both aspects, the integration and the workflow design, development and deployment.
Finally consider that long lead times, facilitate scope creep, lead to missteps on technology choices and often demand compromises on budget and capability. Irrespective of the technology choices you make, ensure that you time to value is within acceptable parameters, that you will know sooner rather than later whether your project will be a success. Take the path to a smart failure if you think you are likely to fail at all.