If there was ever a better argument for focusing more on the deployment of a technology than on the technology itself it was when Bill Belichick tossed out his tablet and went back to using hard copy pictures. Boy can I relate. I\u2019ve been there myself. I don\u2019t care how good the technology is, if the deployment is bad it doesn\u2019t matter what the hardware is, your experience will suck. While moving back to paper is perhaps a tad extreme, sometimes you just want to slap the related IT folks around but it often isn\u2019t their fault either.\n[ Related: Patriots coach Bill Belichick benches Microsoft's Surface, says it's undependable ]\nIf you read Bill\u2019s comments it appears clear some nimrods (technical term) got involved in the process and damn near destroyed the quality of the effort. If I were him, I\u2019d have either gone back to pictures myself or gone looking for those nimrods and found them new jobs hopefully working for someone I really didn\u2019t like.\nI think there is an excellent lesson here, so let\u2019s explore it.\nDon\u2019t forget the user\nI can\u2019t tell you how often I run into situations where the technology gets tossed under a bus even though the real problem is that, somehow, the needs of the user were forgotten. Bill Belichick is a coach and he is a successful one. Any tool that he uses during a game affects how he and his team performs and, if he loses, even if his technology lets him down, he\u2019ll be blamed for the loss. This means that the technology can\u2019t fail, whatever else needs to be done is secondary to making sure his tablet is at least as reliable as the paper solution he was forced to replace.\nNow let\u2019s stop there for a moment and point out that this solution wasn\u2019t created with Bill in mind, and it is clear he didn\u2019t request it and that this technology was forced on him. Any user you do that to will likely be looking for reasons for it to fail. That raises the risk for the technology provider to make sure that folks like Bill need are sold on the solution or eventually they\u2019ll find a reason to reject it. The goal isn\u2019t to just get Bill to use the technology, but get him to prefer it and, in this instance, that goal not only wasn\u2019t met it isn\u2019t clear that anyone thought it was actually a goal.\nNow I\u2019ve seen tablets deployed by the military in incredibly hostile environments that performed better than this deployment did.\u00a0\u00a0\nPromotional deployments\nI was involved with one of these years ago and I swore I\u2019d never do it again. The problem is that it is easy to lose track of the user because the user isn\u2019t central to the development process, but they are absolutely critical to the result. Given the funding generally comes from the technology company, not the firm deploying it (because it is promotional), the folks driving the result on both sides are more interested in getting it done than in getting it done right.\u00a0\u00a0\nIn my own case, the team supplied by the vendor wasn\u2019t very good, our CEO who apparently didn\u2019t have a clear or stable idea what he wanted drove the specification, and the end result moved from what I\u2019d envisioned as simple and easy to a cluster of ever-changing SFO, CRM, communications, and increasingly insane specifications resulting in a huge mess. The people that were to use the project were outside of the loop and after a massive amount of wasted money we eventually just deployed a generic solution, which the vendor couldn\u2019t effectively market as a success.\n\n\t\n\nIt not only was personally embarrassing, because I\u2019d 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.\nEnderle\u2019s rules for a marketing driven customer deployment\n1. Don\u2019t lose track of why you are doing this.\u00a0\u00a0 This means that the result has to be something both you and the user can be proud of. This isn\u2019t 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\u2019d never done it in the first place. Other customers will conclude that if it doesn\u2019t work when you, as the vendor are paying for it, it sure won\u2019t work if they are paying for it.\n2. If you can\u2019t set a solid specification and control the entire deployment, walk away.\u00a0\u00a0 My experience is that these things typically have too many people that aren\u2019t users defining the solution. Bill\u2019s 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\u2019t a coach and doesn\u2019t 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\u2019t use an adequate wireless component to work reliably where and\/or when it was used in a game.\n3. 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 \u201cown accounts receivable\u201d because, in this case, it is that customer loyalty and advocacy that is your payment for the deployment.\u00a0\u00a0 If this doesn\u2019t result you can\u2019t 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.\nBill\u2019s problem with tablets could have happened to any vendor and, sadly, it isn\u2019t 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.