It not only was personally embarrassing, because I’d pitched the idea in the first place, it was an incredibly unfortunate learning experience. Let me share with you the three rules I now recommend when doing a deployment like this.
Enderle’s rules for a marketing driven customer deployment
1. Don’t lose track of why you are doing this. This means that the result has to be something both you and the user can be proud of. This isn’t about doing it as cheaply as you can, it is about creating a reference that will stand up to analysts and press asking the users whether they actually like what has resulted. If you end up with a user like Bill Belichick, publically throwing it out, you are worse off than if you’d never done it in the first place. Other customers will conclude that if it doesn’t work when you, as the vendor are paying for it, it sure won’t work if they are paying for it.
2. If you can’t set a solid specification and control the entire deployment, walk away. My experience is that these things typically have too many people that aren’t users defining the solution. Bill’s objections appear largely connected to failures resulting from too little testing before each game and too little use between games. Any enterprise vendor knows better than to allow something like this to occur, suggesting someone in the NFL, who isn’t a coach and doesn’t understand the technology, set a requirement for testing and before-game implementation that was unreasonably short. And, given it was a stadium, which would typically have overloaded wireless networks, didn’t use an adequate wireless component to work reliably where and/or when it was used in a game.
3. Measure and own customer satisfaction and own customer advocacy. This is the payoff for any vendor driven deployment like this one. This is like saying for a typical sale “own accounts receivable” because, in this case, it is that customer loyalty and advocacy that is your payment for the deployment. If this doesn’t result you can’t hire a collection agency to get it, which means this outcome needs to be assured from start to finish and even after the deployment is done because an unhappy reference account can do a ton of damage. In effect these accounts, because they are known to be funded, are far more powerful negatively than positively and it is easy to forget to keep funding them.
Bill’s problem with tablets could have happened to any vendor and, sadly, it isn’t uncommon with vendor-funded deployments. That goes core to my belief that is it is far easier and safer to take an already successful deployment and raise it up than to fund one, because if the customer is funding it there is less chance the user will be forgotten and the self-funding customer is vastly more credible.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.