According to CargoWise Global Implementation Manager Stuart Mann, pilot projects make it safer to fail, and easier to succeed. He explains why. The global supply chain has evolved significantly in the last 10 years, creating a challenging environment in which to select and implement software products that will meet historic, current and future business requirements. Many logistics companies are using yesterday’s business practices to address current and future technological needs, and remain dominated by the desire to try to fix scope, time, quality and cost at the start of a project. This approach makes it almost impossible for logistics companies to document a full and meaningful set of requirements. This is because the scoping process itself provides the illusion of control. Describing the project we’d like to complete gives us the impression that we’ve achieved something, when in reality all we’ve done is created a rather complex pipe dream. Even more crucial is that the scoping exercise builds inflexibility into the whole project. It sets out parameters and limits so that the project can't change when it needs to cater for critical items, or because of unforeseen circumstances, and therefore is more likely to fail. Spending a lot of time, money and effort trying to evaluate software in an artificial setting is also a common mistake that many companies continue to make simply because they have never done things any other way. This is why it’s useful to find, and talk to, people who understand software implementations from different sides of the fence. I know because I spent much of my early career working in the technology departments of different logistics companies. It wasn’t until I jumped the fence and went to work for the provider of the software that I discovered how many things were being done really badly, and without anyone realizing it. I learned that very few logistics companies had the experience to ensure that deployments of new technology were executed effectively. I learned that very few had the skills to even select a suitable partner in software. I learned that many software companies had become lazy and dependent on revenue from services that was often many times higher than the revenue from software licenses. Most importantly, I learned that in environments of high change, any attempt to fix all of your requirements at the start of a project was expensive and risky, and would probably result in the replication of your existing processes in new technology. The good news is that over the last decade, there have been significant changes to the way software is delivered; changes which make it possible to roll out and test software in a real, but controlled way. Rather than scoping a project, and wasting time looking to recreate the inefficiencies under which you are already operating, it’s far more effective to take on a piece of software and run a pilot. Being live on a particular piece of software in a controlled way, as quickly as possible, is the cheapest and most effective way to learn about how it works and its implementation, because it offers insight that cannot be gained in a demonstration or other kind of artificial evaluation setting. But this is not the way most companies look at a software pilot. Most think of a pilot as the first phase in a progressive deployment to test all of the expensive upfront analysis work. While it is a helpful learning tool to use before committing to large-scale deployments – it is a first step, not an interim step. Fortunately some companies are realizing that the pilot itself should be seen as the opportunity to learn about software and refine a deployment program, but have shifted away from long and expensive requirements analysis programs to a lighter, less risky and more agile approach to piloting software in a live environment.  The catalyst in many cases has been the realization that technologies such as Cloud Computing have forced a rethinking of all of the traditional processes – processes which needed to be in place at the beginning because many of the services like installation, deployment, training and support have been largely automated. The notion of “fail fast - succeed faster” is enough to strike fear into the hearts of every process-driven, scope-based project manager. But it works, and it works because unlike the more traditional approach, it embraces the current technological environment, and welcomes the future.