I spend a non-trivial amount of time most weeks dealing with broken apps–as a user, not as a risk & security person–and from what I can tell, I’m better at working around broken tools than most.

I’m trying to be minimalist here. Simplifying the development of IT Help Desks to only what is too important to jettison. And that is “how much do we suck”?

In other words, while Verizon IT does a good job relative to the industry (*you* try serving 250k users), there’s no way I’m going to call the helpdesk and say “Hey, my phone sucks”. Because they’ll ask “why” and I’ll tell them, and then we’ll spend 3 hours figuring out that it’s just a crappy phone that is operating to specifications. Or my travel app? It’s probably operating to functional and technical requirements. That doesn’t mean it doesn’t unnecessarily cost the company money.

If you follow what I suggest, the user gets to hit an internal website and tell them that my phone sucked again today, or that it took me 30 minutes to enter in 4 receipts. Not only is that “easy” but it’s measuring something that I wouldn’t normally call in about, and something that tangibly costs the company money.

Another example, if you have a Mac and have gone through the learning curve to learn Pages, you might feel, like me, that it’s a much nicer application than other Mac Office Apps. But I would never call into a help desk just to say “Your standard build of Open Office crashed on me again today and wasted 20 minutes of my time”. The help desk would be like “uh, thanks”, or they would take 50 minutes of my life running through a script of “fixes” to my problem.

If you just measure UFH – you might see that while there are few HD calls, this application costs the average user 40 minutes a week in “frustration”. If you want, you can multiply that by a standard “average user cost per hour” and # of users metric.

Maybe I drank too much ITIL Kool-Aid…