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’ve been there myself. I don’t care how good the technology is, if the deployment is bad it doesn’t 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’t their fault either.

If you read Bill’s 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’d 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’t like.

I think there is an excellent lesson here, so let’s explore it.

Don’t forget the user

I can’t 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’ll be blamed for the loss. This means that the technology can’t 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.

Now let’s stop there for a moment and point out that this solution wasn’t created with Bill in mind, and it is clear he didn’t 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’ll find a reason to reject it. The goal isn’t to just get Bill to use the technology, but get him to prefer it and, in this instance, that goal not only wasn’t met it isn’t clear that anyone thought it was actually a goal.

Now I’ve seen tablets deployed by the military in incredibly hostile environments that performed better than this deployment did.

Promotional deployments

I was involved with one of these years ago and I swore I’d never do it again. The problem is that it is easy to lose track of the user because the user isn’t 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.

In my own case, the team supplied by the vendor wasn’t very good, our CEO who apparently didn’t have a clear or stable idea what he wanted drove the specification, and the end result moved from what I’d 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’t effectively market as a success.