DECEMBER, 2020LOGISTICSTRANSPORTATIONREVIEW9 should pick two). What you want is not the biggest return, but the biggest return per dollar/effort spent.Take this as an example: a project that gets you an extra $200k/ a year in profit and costs $10k and 10 hours to implement might be a better choice than a project that generates $1M/profits but costs $750k and takes 1000 hours to implement. Look for the benefit to cost ratio (B/C Ratio), not just the big benefit. Remember that the larger the project, the higher the risk that it will fail so many times small projects in series can get you where you want to go faster, cheaper, and with less risk than the big projects.Third, go out and talk to a few vendors that could help you achieve those goals. Be specific about the goal, the costs, and what they provide instead of letting them set the standards and metrics. Vendors cannot be accurate as there is always a lot of unknown - but work hard to provide a specific use case and avoid broad generalizations. You are focused on making sure you hit the goal that you set out to achieve.Fourth, work with the vendors and try to get some clear indications of time, money, project scope, risks, etc. If possible, include an upside payment for success that is based on your metric, one that you know is valuable to you and that you are willing to pay for. Too many people fail to define the benefits of monetary or nonmonetary in a proof-of-concept. This is a missed opportunity to align incentives.Fifth, pick just one vendor. This allows you to compare multiple projects and pick the winner using the B/C ratio mentioned above. It is a lot easier to compare projects and pick the one that gets you the biggest bang for your buck.Sixth, when you work with the vendor, try to set a significant amount of their payment based on hitting your metric, so everyone is working towards the same goal. We call this optimizing for operational savings in the spectrum of possible return on innovation metrics vs. focusing on exploration or learning.Seventh, take very short small steps. Milestones are not effective, and long projects have low success rates. Instead, try to implement something very small but useful every 2-4 weeks, so even if the overall project fails, you still have some parts that add value. Avoid milestones based on the success of the overall project; these are worthless. Focus on small useful steps along the way.Eighth, if you find success, don't be afraid to add more resources and double down on your winners. Alternatively, have a "kill switch" every few weeks for projects that are failing. In general, once two steps or deliverables are missed in a row, the chances of project success are very low. Walk away fast, don't wait to kill it.Ninth, if you start to see successful projects, only then begin to train others to also implement innovation. If you are the only one doing it, it makes for slow work.Tenth, enjoy the successes when they come. Even with a good method, a lot of projects will fail, just kill them fast so they don't cost you much, and you will still have time and resources left to others. Don't aim to "fail fast;" fail cheap and fail forward. It is best if you set the goal in relation to the cost/benefit involved to allow it to scale more easily (remember, you or your team might want solutions that are cheap, fast, and good, but you should pick two). What you want is not the biggest return, but the biggest return per dollar/effort spent
< Page 8 | Page 10 >