“Most business information technologies do not deliver great experiences.”

Man. Aint that the truth.

This quote is from a recent blog post by one of my favorite Enterprise 2.0 authors, Paula Thorton.  It literally jumped off of the screen, landed in my mint julep, and was ported directly into the underwhelming organ I refer to as my brain. I can count on one hand (finger?) the number of business applications I consider great experiences. As such, it has been stewing there for the past little bit and I have been trying to figure out why. Not necessarily why it has been stewing (that part is easy – I am simple), but why the statement is true.

I have also been stewing on a rallying cry I continue to hear while waging the undying E2 adoption battle. People seem to be transfixed on the idea that things (technologies) “must be easy to use” in order to opt for a change. I hear this in bunches and have sort of reduced it to ‘a technology must be relatively easier to use in order to induce change”.  For argument’s sake I mean change in the most binary of senses.  As in stop using SharePoint and start using Confluence. Forget all the other stuff like organizational transformation or culture shift or <insert change buzzword here>.

So when these two stews came together, I asked myself the following question:

• Does a great experience with a business application imply that it is easy to use? Moreover, should it be?

In attempting to answer this question I thought about experiences I consider “great”. What are the attributes of an experience, professional or otherwise, that inevitably make it great? After sifting through my collective experience of persistent mediocrity, it boiled down to a couple things. They usually entail some sort of hard work, possibly even pain, and a sense of accomplishment. For example, I hiked up Mount Washington with Brother Nash this past winter. In one day with temperatures well below freezing, we covered 8 miles, gained and lost a mile of altitude, and carried a sweet ice axe. Hard work? Yup. Sense of accomplishment? For sheezy. Great experience? Check. Another example is my obsession with CrossFit. Most weekdays, the fine folks at Primal Fitness DC are kind enough to hand back my ass after a seriously proper kicking up and down New York Avenue.  From Fights Gone Bad to dancing with the clown, there is definitely both pain and a sense of accomplishment. Mark another in the “great” column. Finally, the time I spent working in the Middle East was definitely a great experience. We accomplished many things and well…the reason why life might be a bit hard in Baghdad is pretty self-evident.

So how does this translate to business applications? The only app I really consider a great experience is our wiki. I have never really thought about it until now, but why is that? Why do I think it’s great? For the longest time, I thought it was because it was easy to use. But the more I think about it, while the tool itself may be easy, the experience is anything but. It is hard. It is sometimes painful. And frankly, it should be.

When we write professional content (like deliverables) in wiki form, we are forced to expand our minds beyond typical expectations. We must increase our understanding of context, look for the bigger picture, and understand where the content we are producing fits into it. What does this link to?  Where else are people writing about this? What are they saying? Am I wrong? Are they wrong? What should this link to?

I would posit that none of these questions existed so blatantly until I had a tool that exposed them to me. I worked away in my little silo of knowledge (more of a shed really) and never had to consider the bigger picture. Maybe there was some other eRoom with similar content, but I sure didn’t have access to it. Even if I could link my document to the other, what did that do? It didn’t help the search engine. It didn’t provide trackback for the other author. It would also usually break if either doc was moved or renamed. Now those were the easy days. So why bother?

Well…I didnt. And most people still don’t. Even though there is a clear option to  produce a great experience, people are still slogging through version control nightmares fueled by email attachments and track changes. Why? Because it is easier??? No. Ease of use is often a foil for thought laziness. Email attachments are easy. But they don’t precipitate a great experience. Why bother to expand your perspective when the siren of a paperclip icon (or a folder upload) calls so sweetly? Silo shmilo…I have Facebooking to get to!

My great experiences with business applications (or anything for that matter) always require some level of hard work. Authoring in the wiki provides for a great experience, but when the content is at its most powerful, it is in no way easier to produce. It forces me to think beyond what I usually think about. Isn’t that what organizations want out of their employees? Isn’t that what employees want from their jobs? Challenging assignments? Big thinking? I know it’s what I want.  And yes, it can be hard. But, just like the feeling you get from a correct choice in the Big Mac vs. spaghetti squash conundrum…it is great.

At this week’s Gov 2.0 Summit, the feds seemed to have a coming out party of sorts for their new approach to IT in government – do it faster, lighter and be more transparent. Kundra & Chopra spoke about how open standards and building platforms for citizens to expound on government data should be major parts of new federal IT spending. The agenda was filled with sermons on the virtue of transparency and the wisdom of open source. Watching these things be taken so seriously warms my heart. But, the question remains – does the government have the will to execute? More importantly, do their contractors?

This is key. While the drive to do IT differently, more cheaply and more transparently is clearly emanating from the folks now holding the reigns of the government, this notion easily be lost somewhere deep in the opaque depths of the IT procurement process. If there is one thing that some government technology contractors have come to appreciate, it’s that building a system that is expensive, difficult to retire, and complicated can often serve to lock in years of future revenue. As one presenter put it, some companies consider building bad enterprise software “a competitive advantage”. In some cases, this has become the only way they know how to operate. Think of the billions in contracting vehicles now rendered useless by a government who only wants to buy lightweight, open source software built on flexible data exchange standards – software that many of its legacy contracts aren’t able to provide.

Some will adapt. Some won’t. But, this opens a tremendous opportunity for smaller, more agile firms that have concepts like OSS, sound UX design, and web services built into their DNA. At Government 2.0, people like Peter Corbett of iStrategyLabs showed the feds that massive, data-intensive websites can be built quickly, and even crowd sourced to citizens who feel engaged by this approach. His Apps for Democracy project exemplifies this (in fact, Vivek Kundra sponsored this project when he was DC’s CIO). I’m confident that we’ll see the new administration work with IT vendors that can deliver projects that follow this model, big or small.

The restaurant was bustling with activity around an oversized circular table at a moderately trendy steak house in downtown Boston. Dressed in my best “I don’t care what I am wearing, but I care what you think” outfit, I was out to dinner with various characters from the enterprise wiki postercompany, Atlassian. Both Jay and I were rotund with transparent geekery and well cooked bovine. Neither of which seemed to stop us from having a glass (bottle? ) of wine too many as we discussed our Confluence implementation with president of the firm – Jeffrey Walker. I think that for Jeffrey and the rest of the Atlassian team in attendance, it was just another night, in another town, with a couple of zealous wiki fans, drunk on the Confluence kool-aid. For us, however, it was a unique chance to both thank and appreciate some of the people who believed in us from the very beginning.

While my interactions with Jeffrey were relatively limited from there on out, he was unwavering in his support and advocacy.  No matter how long it had been since a sale or a marketing event, he was gracious, appreciative, and genuinely interested in our continuing slog through the E2 adoption quagmire. In light of his tragic passing yesterday, we wanted to express our condolences and gratitude to his personal and professional family at home and Atlassian HQ.

Jeffrey, you will be sorely missed. We would not be where we are today without you and the dedicated people at Atlassian.

Thank you.

For those (5) of you keeping score at home, I feel it necessary to inform you of a recent mark in the W column for the half tactless (me), half talented (Jay), full-tilt team of trans-national transparency here at E2oh. Fire up your boombox and rifle rack because ladies and gents, rising like a $12,000 enterprise-wide, web-based phoenix from the ashes of acquisition, the Wiki is back!

Needless to say, I am stoked. After 3 months of a painful regression through file uploads, track changes, and hourly knowledge assassinations from email, I could not be happier to again, author content in Confluence. I mean really though…how do people do it? I haven’t been removed from that world for decades but Jesus Murphy…I almost missed my handball game with Gordon due to the total time suck of outdated and inefficient tools and methods.

So…I have been a thinkin’. Thinkin ’bout 2.0 and what not. Know how people say ‘If I had to do it all over again…”, and then ramble off a litany of mistakes from their latest project? (Or complete life in my case). Sometimes they even go so far as to turn these pricey little gems of consulting pontification into deliverables we call “Lessons Learned”. Strangely, for as introspective and growth-oriented as this process appears, I always get the sense no one actually “learns the lessons”. They are more just an embarrassing admission of failure recurrence when “learned” again on the next project.

So with that, I figured I would put down on paper (monitor?) a few lessons we learned from our multiple 2.0 implementations over the years. We are essentially starting over in the adoption marathon at our new company, and maybe, just maybe we won’t have to learn these lessons again.

• Lesson 1 – Completely disregard anything said by anyone referring to themselves as a social media expert, selling only a social media strategy, or claiming that it’s not about the technology. The real “experts” out there are the employees with their heads down, screaming like a banshee for a better way to work. They don’t need a strategy.  They need permission and a tool that will enable them to serve as a vanguard for the organizationally elite .  They will guide the rest of the herd, knowingly or not. And don’t call them early adopters. Call everyone else late.
• Lesson 2 – Realize you probably know way less about “how your organization works” than you think. “Culture” can be a tricky devil in the world of limited choice. Maybe your organization hoards information because they have never been given an option otherwise. Don’t presuppose any of the actions of the crowd. Go into projects with a focus on flexibility and agile adaptation to the movements of the masses. This is social software after all, and I know I am not nearly smart enough to accurately predict anything a society might do.
• Lesson 3 – Convince yourself you are never informed enough to always be right. You are only informed enough to sometimes be present. If you ask more questions than you answer, you reduce the risk of looking like a complete knucklehead and increase your chances of getting a second date. Wait…that’s not a lesson I learned at work…definitely learned that in Adams Morgan. Seems to sort of work both places though.
• Lesson 4 – Start a blog and make fun of yourself for being a 2.0 zealot. I mean…we are kind of nutty, right? And just like Dairy Queen, everyone loves a little substance dipped in crunchy self deprecation.

I can say with absolute certainty that I have committed the mistakes driving these “lessons” dozens of times. Hell, I might be committing one of them by writing this post.  As we move ahead with Wiki Part Deux, we’ll keep the scoreboard updated on how we are doing.  Put on your rally caps though, because if my writing is any indication of my ability, I am coming from down a ton and need all the help I can get.

The hype surrounding Cloud Computing in government has risen to a deafening level as government IT leaders and eager contractors try to find relevance for the technology within the federal enterprise. To make Cloud Computing work for government, it helps to take a step back and understand why the technology has been so successful elsewhere. Cloud Computing isn’t just a way to cut costs and drive efficiency; it also brings technology closer to business users. With cloud infrastructure, users are able to quickly spin up tools that they want use, but aren’t necessarily the choice of their organization’s technology gatekeepers. Cloud platforms let users quickly develop and implement applications in a way that short-circuits typical development lifecycles. This closes the gap between business users and technology. Increasing the alignment between business users and the software and hardware that supports them is perhaps the most important (and often unstated) benefit of Cloud Computing in the enterprise. It’s the reason that Cloud infrastructure and platforms have allowed for the creation of scores of startups, and helped to fuel the rise of Web 2.0 tools behind the firewall. But, does this free wheeling attitude towards the implementation of IT tools resonate behind the doors of government agencies?

It can, and agencies are starting to show how. NASA’s Nebula enables project teams to develop and deploy software to meet their needs, and can take advantage of the scalability Cloud platforms can provide. The GSA’s planned “app store” would allow government users to quickly purchase applications and infrastructure, have them delivered through the Cloud, and pay via a credit card. Agencies that want to make their internal Cloud platforms successful should keep the notion of customer centricity in mind; to be successful they’ll need to keep their private Cloud simple, and accessible to end users. Looking at Cloud computing solely from the lens of an IT director or CFO won’t make Cloud computing anything more significant than the infrastructure technologies that preceded it. By bringing users a step closer to the technology that can help solve their problems, Cloud Computing can be as transformative in government as it has been in the private sector.