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.

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

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…

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

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? 

Bookmark It

Hide Sites

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

Bookmark It

Hide Sites

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.)

Bookmark It

Hide Sites