Striding boldly from the wreckage of voracious consumerist discountlust, I head toward the checkout. Glancing down at the sled, I am satisfied with my impending purchase. It is in a word…solid. I approach the line which seems to disappear over the horizon and while waiting for my turn my mind of course wanders into the geeky land of E2oh…

It occurs to me that my journey to find this sled is not too dissimilar from an almost daily frustration of finding information within corporate and government monoliths. I have harped on this issue before but here is what I go through when asked to “go find something”. For the purposes of the dialog below, consider Longfellow anyone who has created information alone, then it stored it in a traditional document management app in order to “share”. (So…like almost everyone in your organization. )

Longfellow: “Hey Nate…when you are done with your nap can you take a look at the deliverable I prepared? Would love some input.”

Me: “Sure no problem Longfellow. I assume you have put this wonder of consulting somewhere I can find it, right?Oh…and…uh…sweet ascot.”

Longfellow: “Thanks. My father Higginsly bought it for me. Yeah… the deliverable is uploaded to the DocuPointShareFireStormDrain site.”

After an interchange like this, I would search for the link to the aforementioned “place” where hopefully I am met with the delight of reading something worthy of Longfellow’s bill rate. Instead, I am presented with this:

Man...look at all that KNOWLEDGE to manage.

Hmmm. Ok. So now what? Clearly whoever designed this folder structure knew exactly how I would categorize information. So this should be easy, right? I should be able to flawlessly navigate directly to this deliverable and life will be good. And so we begin:

1. Click, click, click…not there….expletive.
2. Click, click, click….not there…expletive, expletive.
3. Click, click, click….not there…expletive, expletive, expletive.
4. Enter presumed keywords into search box. Dizzying list of irrelevant junk. More expletives.
5. HR rep stops by the desk. Still can’t find deliverable but am now up to speed on firm policy for professional behavior.
6. Call Longfellow. He stops by.

Longfellow: “Hey Nate…can’t find the deliverable? Weird. I thought it was pretty apparent where it would be. Maybe you just don’t understand how best to organize information.”

Me: “Hey Longfellow…yeah can’t seem to find it. Why don’t you give it a go? And maybe you just don’t understand that I might hobble you when we are done here.”

Longfellow clicks about 37 times and we are presented with this (his deliverable is highlighted):

Totally my fault.

I am sure you can imagine the rest of our interchange.

Sure, for the sake of argument Longfellow could have sent me a link but quite frankly that rarely happens. People tend to just state that a certain piece of information is “up there” and expect you to find it. Or even more frequent is the self-prompted need to find something. Either way, there are major issues with this approach constituting the reasons why I have abstained as often as possible from using platforms like this as a way to author and collaborate on content.

• We Need a Better Structure – Typically people will point out that the problem with me (or anyone) not being able to find anything is the fact that the structure or hierarchy (taxonomy) is flawed. Unfortunately this is merely a symptom, not the root cause. Hierarchies often break down because either the person/people who created them perceive information categories differently than the people who use them. It becomes an almost intractable problem when the data set you are trying to categorize approaches any decent scale. Your folder structure on your laptop works because you are the only user and your data is the only thing being organized. But then you get asked to create something like the picture above and scratch your head when I can’t find anything. Want a bigger example of this? You use and find things in the largest data set in the world on a pretty frequent basis. But how often do you use a folder structure instead of search? I would guess never. Traditional, single dimension hierarchies just do not work. Not to mention the fact that it is a holdover from organizing physical information in actual file cabinets and folders. Think about my experience shopping for sleds. The hierarchy I was presented with was designed to 1) hold physical goods, 2) keep me in the store as long as possible, and 3) make me walk through other stuff that I might be tempted to buy. Great for a store, but drop dead ridiculous for efficiency in the workplace.  You are not Henry Brown. Don’t try to be.
• The Search Doesn’t Work – This one is a bit more difficult to tackle. I am a big fan of the search not store mantra but with a caveat or two. One of the reasons search works on the WWW is because of links. The links between bits of info help with determining relevancy, popularity, and a few other things I am sure the smart folks at Google could tell you about.  I think that search tends to fall down a bit without links. In other words, almost all of the corporate stuff you produce. Unless you are creating web-based content and proactively linking (as if you were creating content on the WWW), you may find your stuff…well…hard to find. That being said, it isn’t that search doesn’t work…it’s that your content is not really designed to be found.

So next time you find yourself at a SUPERTARGET or authoring some sort of deliverable, think about the full lifecycle of your stuff. Not only does it need to be created, but it needs to be found. Keeping that in mind from the minute you begin spewing brilliance through the keyboard will at least keep me off probation for shouting obscenities at my laptop and at best, get your stuff found by people who actually might need to use it.

(This post is somewhat related to a post I wrote for Future Changes.)

Nonetheless, I promised some time ago that I would keep you posted on the score with respect to Wiki Part Deux (Electric Boogaloo) . In short – so far, so good. Adoption, usage, and pervasiveness continue to steadily grow regardless of some rather daunting challenges like no SSO, no communication efforts, mandated account requests, and no integration with enterprise search. It’s all viral, all day and frankly it has been working surprisingly well. Like a virus. Errr…a friendly virus. A friendly virus that promotes transparency and recently added some hot new drag and drop capabilities. Yeah. That kind of virus.

As awareness increases, I have been fielding more and more questions on the difference between the wiki and (insert any big name document management platform here). The questions pertain to other internal systems or client systems. I (as well as a bunch of other much smarter people) have said some of this before, but thought it helpful to put it out there again.

Simply put, the wiki is not a new place to put content. It is a new way to create content. Think of the wiki as a replacement for Word or Email. Big name document management systems (in almost every organization I have seen) work like this: Open Word. Write something. Save it on your desktop. Upload it somewhere a few people can see it. Hopefully they find it. Hopefully they are the “right” people. Hopefully they download it. They make comments or changes. Hopefully they reupload. Hopefully you can reconcile the changes with everybody else’s. Rinse and repeat.

The wiki (in my organization) works like this -> Open the wiki. Write something. Save it. Everyone sees it. Some people comment or make changes. Actual (and rapid) collaboration ensues.

In my book the big difference between the two is a process improvement, not a location improvement. I don’t download. I don’t save attachments. I don’t worry about versions. I don’t send emails . I produce actual content.  My team and I are able to produce better content because we can work faster and with more brains at the table. Sure, there are great benefits in the knowledge management game, but at the end of the day it is about $ to me. Efficiency and leverage are the lifeblood of successful projects. Shifting how you think about producing the content, not where you think about putting the content will get you larger gains. It just so happens that the wiki is indeed a “place” of sorts at the end of the day, but the true value is in the process itself. This is why I see so many disappointed wiki users who do nothing but create pages and attach documents to them. There isn’t really a compelling improvement there. But when you change the process…now we’re cooking with gas.

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.

Essentially for Jay and I, the BearingPoint Enterprise Wiki is over. Sure, there may be a next step that looks the same and meets the same ends, but the experience where we cut our Enterprise 2.0 teeth is going the way of the dodo. In realizing this, I wanted to say thanks to some people who helped us along the way.

To the early adopters and long time supporters – For believing that from the moment we got up on the soapbox, we were not just tool jockeying the app du jour, but striving to make our company a better, more transparent place. You had the faith to participate, advise, lobby your own teams, provide top cover when we stepped a bit too far out of line, and pass the hat to fund our early pilots. As the leaderless organization virally grew outward, you were both the messenger and the artist, crafting the theme of transparency into something that met your individual needs. From the early adopter Managing Directors to the core support team that just hung up their admin spurs on Friday, thank you for your support.

To Atlassian, Contegix, and Customware – For believing that while it may take a while, we would turn out to be a decent investment. You always treated us fairly and are shining examples of how proper business should be conducted. We may have been a little late to pay from time to time, but you stuck with us, focused on the longer term relationship. From the support engineers and sales staff to the developers and executives, you were critical to this process and I thank you for your support.

To Kevin King – For being the unsung, high-side hero of the project and believing from the very, very beginning, that this was a good idea. You were untiring in your contribution to the team and put in hours beyond my understanding to make sure the ship kept afloat. Jay and I both know that we couldn’t have done it without you.

While the parties above represent the core of responsibility for the project, there are thousands of individual contributors and champions throughout the firm. They each helped to make the BearingPoint Enterprise Wiki a success, and if it were possible to sum their collective experiences, you would find the elusive and sought after white rhino of Enterprise 2.0 – Return on Investment. I can only tell you for certain, that it has changed my life. I am better at my craft. I produce better content. Conceivably, I am a better consultant. However, most importantly I have the opportunity to thank the people who helped me get here. That…is enough return for me.

UPDATE: We’re Back…

All in all, the event was a bangin’ good time. In addition to my blathering and Jay’s wisdom, Ken Olofsen was on hand from the Atlassian mothership to give product updates, company overview, etc to the attendees consisting of government and private sector types from around the Beltway. Also, shout out to the guys from Blackboard who gave a neato rundown on their Atlassian stack to SilkCentral integration. 

Thanks to everyone at Atlassian (especially Jessie Curtner!) for throwing down a righteous shindig in the District. Well…as righteous of a shindig that can be had with a bunch of geeks like me. Looking forward to doing it faster, better, and with even more consultanese at the Summit.

In response to an internal communciations query, I was recently asked to take a look at usage stats since GoLive. Initially I was pretty impressed but then it occured to me that I really have no basis by which to judge either way. As such, I thought I would post the facts and see what the prevaling wisdom is. 

Basics:

• GoLive Date = May 5, 2008
• Possible Users = ~16,000 (The wiki is only accessible by employees. This number is roughly current headcount, but people have come and gone over the months.) 

We’ll start with basic wiki pages first:

• Current Wiki Pages = 11,720
• Versions of Current Wiki Pages = 87,280
• Pages with Comments = 2,039
• Number of Comments = 6,661
• Unique Page Authors = 1,858

Secondly, Confluence has built-in blogging capabilties through its News Item feature. Here are the numbers for that:

• Current News Items (Blog Entries) = 1,503
• Versions of Current News Items = 2,991
• Comments on News Items = 1,065
• Unique News Item Authors = 210

Finally, here is some typical web analytics data to round out the picture:

• Visits = 68,168
• Pageviews = 620,329
• Pages/Visit = 9.10
• Bounce Rate = 25.81%
• Average Time on Wiki = 09:59
• Unique Visitors = 15,443
• Originating Countries = 62
• % Traffic from Referring Sites = 43% (mostly from Intranet, the rest is Direct traffic)

So what do you think? How does this compare to other stats you have seen? 

Go check it out and make sure to browse the rest of his great content. Thanks Stewart!

So…sweet. Jay and I have the merit badge. Word of our badge (and sash?) have percolated through the firm and we now get calls to help existing clients with implementing their own wikis and similar enterprise 2.0 technologies. Inevitably, our clients ask for best practices, potential pitfalls, methodology, lessons learned, and (insert typical consulting artifact here). So, in the vein of decaying IP, I thought I would share some high points here:

Pitfalls
Implementing a wiki is the antithesis to traditional enterprise application deployment. Treat it like an HR or Financial system, and you are bound for failure. Typical mistakes include:

• Lack of willingness to move to the read/write web paradigm – It is not a new place to put work, it is a new way to do work.
• Treating your users like kids – Overactive security models, excessive taxonomy, and extreme management oversight will turn your wiki into nothing more than the magnificent, inflexible shell you originally created.
• Treating your users like geniuses – A blank slate with little guidance or seeding will work for only the hyper-creative. We paint lines on roads for a reason.
• Wiki panacea – A wiki will not solve all of your problems. It should not be positioned as all things to all people. Change is slow. Don’t try to eat the elephant.
• Managing to the possibility of failure, not success – If you are more focused on how the wiki will fail, instead of how it will succeed, you have already written your destiny. The cost of failure is relatively low. The value of success is immeasurable. (Really, it is – so don’t try and measure it.)
• Asking for permission – Encourage your users to proceed until apprehended. The best content comes from a user community free to express themselves, without fear of (overwhelming) retribution. Critical mass will be impossible to achieve unless people are willing to step forward on their own.

Best Practices
Begin your day by understanding that a wiki implementation is like surfing. Be prepared to react to the forces of nature, and shift direction easily. These implementations are “quasi-unplannable”. Best practices include:

• Start with a discreet, flexible, and relevant business process – If you do nothing but have meetings, keep the minutes in the wiki. If your do nothing but go to happy hours (please hire me immediately and) post bar reviews in the wiki.
• Identify a participating sponsor – Find a high-level, well-respected leader and implore him/her to begin using the wiki ASAP. Contributions from management will bolster the rank and file to participate.
• Spot pros early and recognize contributions – Keep an eye on updates and learn who is not only active, but qualified. Encourage them off and on line to continue and mentor others.
• Go viral – Adoption of a wiki is best achieved when predicated on a “want”, not a “mandate”. Avoid mass communications and anything that sounds non-exclusive. While this can be a slower method for implementation, the results are a much more entrenched and vibrant community.
• Drink your own kool-aid – If you are advocating use of the wiki for collaboration on a new policy or procedure, and still emailing attachments, you are sending the wrong signal.

These points were developed through a combination of the advice and guidance from Stewart Mader and our own implementation experiences. Stewart was instrumental in helping Jay and I navigate what I now believe are the potentially troubled waters of implementing an enterprise wiki. If you are even thinking about wikis, go buy his book. It might just save your life. Well…not really, but it is a great read nonetheless.

More later on why enterprise wikis are difficult to implement…

(Neither Jay nor I have been compensated in any way for this post.)

]]> http://www.e2oh.com/2008/03/02/a-banana/feed/ 8