Michael Krigsman, of ZDNet's IT Project Failures blog, points out the recent rapid expansion of flashy technology dashboards, those cool collections of reports and data which appeal to almost every non-tech executive by giving them a feeling of almost god-like insight and control into the most minute dealings of their organization. He notes that despite this proliferation, there is frequently little real utility in all this sizzle and light, and that in fact the dashboards can serve as a distraction from the actual information and issues most important to the organization.

This theme ties in somewhat with my recent yammerings on the dangers of complexity. Dashboards aren't naturally complex, and the idea behind them is sound and worth pursuing. Krigsman's critique is that the dashboard manufacturers rarely understand the information that users' need to do their jobs and therefore present the wrong data or the right data in the wrong format. While this can be an issue, I think it is just as common that users fail to identify this information properly themselves, or become too distracted to look for it in what they are presented.

One of the posts cited by Krigsman (JP Seabury's Great Dashboard Clean-up Project) illustrates this perfectly. "The users asked for more dashboards, more pretty graphs, charts, tables, and I appeased them," Seabury says, but later notes "...none of these dashboards seem to drive any real change in the organization."

This isn't a failure of the vendor or dashboard creator; this is a fascination with toys at the end-user level combined with a failure to envision the potential utility of the tools. CIOs are quite familiar with this user-driven techno-lust, which is just as insidious as the sort which frequently occurs within the IT department itself. Who hasn't spent hundreds of wasted hours battling some rogue user initiative that sounded cool to an executive after his son showed it to him, but which wouldn't fit the company's existing architecture at all and doesn't fill any clear business need?

Worse than any failure of a vendor or programmer to understand the business requirements is when the end-users or executives themselves do not understand them. It's folly to view any technical project as a panacea in and of itself; technology is a tool, not a blueprint. If you don't already have a clear vision of what you need and where you are going, no technology is going to help you and any of them might seem a hindrance to be blamed on its creator or implementer. My advice to executives experiencing these problems, however, would be this: look in the mirror. If you can't articulate what you need to get where you want to go, no systems analyst or vendor is going to be able to give it to you. There's a reason you're making the big bucks... know what you need or you're going to get whatever they have handy.