Stop using e-mail as a collaboration and knowledge management tool

E-mail still has a place in the work environment. E-mail won't go away. But it's amazing how many employees still rely on e-mail for collaboration and knowledge management tasks that would be better suited for even a simple internal wiki Web app.

I'd like to eliminate the overuse by others of writing simple text documents in Microsoft Word or Acrobat (pdf file) and e-mailing them around to each other as e-mail attachments. And I'd like to eliminate their use of printing these simple text documents on paper to read or study later. 

more.

Back in 2000-2002, I tried to get people to use the Plumtree Portal system at work. If it was used, people uploaded .doc and .pdf files. 

In 2001 or 2002, I also installed at work for my own use the Greymatter blogging tool. Greymatter did not use a database. I stored files as plain text files on the file system. And when a new post was created, the HTML was created, and other files were updated. It was simple, easy to use tool. I liked it better for managing notes, task, links, etc. than the portal. This blog tool was my knowledge management tool.

In 2001 or 2002, I wrote message board and blogging gadgets for the Plumtree Portal, but I was the only one who used them. The message board gadget was a community gadget to be used, obviously, by multiple people in that community. The blogging gadget was a personal gadget to be used on a user's personal workspace area.

In my opinion, meeting notes, project ideas, tasks, anything work-related should be stored as plain text markup in a database in a CMS, KMS, or wiki, and displayed as HTML to the user.  Comments and/or annotations on posts/articles can provide collaboration.

Start with the simplest setup to get adoption, and then let engaged users request additional features. Then enable or build those features. 

Don't install a system with gobs of features and complex writing and updating screens that overwhelm users into revolting.

In 2000-2002, most users in the workplace did not write to the public Web. They used e-mail, but most users did not post to message boards or blogs. Maybe they wrote a review at e-Bay or Amazon.

But in 2013 with so many social media sites in existence, more people are creating content for the public Web. It seems that it would be easier today to get employees to post to an internal social media-like knowledge management tool. I would think that employees would be requesting some kind of Web-based internal app to manage company information. But the employees want the writing part of the app to be as simple as posting to Facebook or Twitter.

Complex features can still exist for power users or users who eventually would like more features. But these advanced features are not so obvious that the screens get cluttered, which increases confusion for the users. The advanced features are somewhat hidden. The advanced features exist for the people "in the know" because they read the online documentation.

But for simple content creation, simple features will suffice most of the time. Keep the form elements to the bare minimum. Make the power commands be text-based that are added to the document. Or the power commands screen can be activated by a small, obscure link.

The first goal should be user adoption. Then as users become comfortable with the internal Web-based KM tool, the users seek additional features.

Unlike 10 to 12 years ago, today's internal KM tool should have some social features, such as following users and following tags or topics. I don't think "likes" for pages and comments is necessary. It may not be a good idea to show the number of followers for each user. The focus should be on work and not popularity. For larger companies, following users and topics can be useful for sharing information.

Many companies exist today that create enterprise level social media tools for internal usage that also serve as KM apps. But the resistance to use these tools is still great. Maybe the tools are not simple enough to use at least initially.

The heavy reliance on e-mail and sending attachments of text info and printing these files is still great, amazingly so. It seems like a big waste of time and a great loss of corporate knowledge. 

E-mail is a woefully inefficient way to manage the amount of information bombarding knowledge workers today. Implementing and getting user adoption of an internal wiki-like, social media-like, KM tool could enable employees to work smarter. Workers could be more efficient, getting more work done in less time by finding their answers easier. New employees or employees changing departments could learn quicker and be productive sooner. Accessing the archives of old projects, the good and bad parts, could be helpful for future projects.

Tagging, searching, taxonomy (organizing), and sharing could help the company compete better in its industry. I don't see how it's possible for such a tool to be less productive than the near 100 percent reliance on e-mail.

Oh, prohibit or limit the use of uploading attachments. Prohibiting attachments won't fly with users. The problem is, users could do nothing but upload Word or PDF documents, instead of writing text documents within the Web-based tool. 

What if all the Wikipedia articles consisted of only Word or PDF files? Would users find that more useful than HTML pages?

What if all Twitter and Facebook text posts consisted of only Word or PDF files? Would users find these binary files more useful than reading or typing plain text that gets rendered as HTML in a browser or formatted in a native app on a mobile device? Each Tweet of Facebook status or comment was a Word doc being read on a smartphone. Good?

If I started a small, knowledge-based business, I would not install a printer. If people feel that it's easier to print a text document for reading or marking up with a pen, then that's a software issue. Ask the users, "What would make you read and edit a document on a computer screen or tablet?" Besides not having a printer.

Why is it easier to read a printed document instead of reading it on a screen? What's lacking in the Web-based software that prevents users from marking up the document like users would do with a ballpoint pen or pencil on paper?

People read books on Kindle or other tablets. So why print a document for reading? The information should be easily accessible through a Web browser on the internal network. When away from work, then accessing the Web-based information would be handled by the company's secure access setup, such as  RSA SecurID.

Don't print. Read, edit, annotate, and comment on the screen.


h2. Social Platform

Excerpts from a Sep 17, 2013 Socialtext blog post:
"Share by Default: How to Use Email Effectively with Your Collaboration Platform":http://www.socialtext.com/blog/2013/09/share-by-default-how-to-use-email-effectively-with-your-collaboration-platform/


q.
According to a McKinsey report, the average knowledge worker spends 28% of the work week on reading and responding to emails. That’s crazy! Don’t get me wrong, email has its purpose; it’s flexible, it can be part of your workflow, and it’s not going away. However, email shouldn’t be the all purpose communication tool of the office.

Your collaboration platform should be the central knowledge repository of editable web pages, files, conversations, and essentially anything that could be useful for you, your team, or colleagues you don’t even know yet. Email can help you keep track of which tasks and projects within the knowledge repository need your attention and allow you to alert others if they can help answer questions or need to review a document.

However, if you take a look through your inbox, you’ll probably find never ending threads, many of which you’re unnecessarily included in. When you think of all the useful knowledge trapped inside everyone’s inbox, that is *essentially unsearchable by 99.9% of the rest of the organization,* you realize why it takes so long to figure out who is the expert on a topic or what the answers are to your complex questions. *The bulk of corporate knowledge is invisible and undiscoverable to those who need it.* 

I worked for a manufacturing company that made flavorings and all employees had weekly taste tests. It was estimated that it took about 50,000 emails a year just to coordinate people’s schedules. We implemented Socialtext, set up a single editable web page where employees could sign up for time slots each week, and with that one small change, we essentially eliminated 50,000 emails a year. And making the schedule more transparent actually encouraged people to sign up more often when they saw when their friends were signing up.

*Essentially any process that involves multiple employees editing and revising information can be done faster and more easily with social software.* You don’t have to keep track of multiple copies of documents or versions or figure out how to pull multiple edits into one document; a good social platform does that for you via revision history. If these are repetitive processes (e.g., organizing monthly events, weekly newsletters, etc.), a social platform enables participation from anyone and can make collaboration more efficient.

It takes an intentional individual, team, and organizational effort to migrate your attention away from your inbox, and begin doing most of your work within your collaboration platform. You can work all day sending and responding to emails, and that work will be visible to those you’ve communicated with, but will be invisible to 98% of everyone else. Instead, if you do your work transparently within your social platform, your work is visible to and discoverable by almost everyone. *That makes finding useful knowledge easier.*

Work transparently, not invisibly. *Most communication and knowledge is useful to others.* Share by default; use your social platform.
q..

Since 2002, we have:

* Facebook
* Twitter
* YouTube
* Tumblr
* Many other social media sites
* Massive expansion of Wikipedia
* Many more blogs and blogging tools
* More software as a solution apps, and companies hosting business-related, Web-based tools
* Smaller, more portable laptops
* Kindle and other e-book readers
* Smartphones
* Tablets
* HTML5, CSS3, jQuery (and other client-side JavaScript tools)
* High resolution screens
* Better Web browsers

We spend more time creating and consuming Web-based information on more types of devices in 2013 compared to 10 to 12 years ago. And, of course, we use native apps on mobile devices too.

Because of new browsers and client-side technologies, engaging with the Web is much better today than in 2002. So why do so many people at work today still rely on methods used in the 1990s for collaboration and knowledge management: e-mail, Word and PDF attachments? I would think the 20-something-year-old employees would be confused by these 1990s era methods.


h2. GitHub for Everything

http://wiredcraft.com/posts/2013/09/18/github-for-everything.html
https://news.ycombinator.com/item?id=6404847

From the Wiredcraft post:

q.
While [GitHub] initially mostly replaced our code tracking tool (I believe we were then using Redmine), it now is the single most important platform for our team to collaborate, on all levels, from code to HR.

Our needs changed over the years and we faced a few key junctions when we had to adopt a new tool. This meant convincing the entire team to adopt a new workflow; not something particularly easy to do with a team of technologists mostly focused on shipping stuff.

Our internal wiki, associated to the code of our company site (a Github page by the way) is filled with awesomeness. From the “Getting started” page that walks new employees through our tools and processes, to the tutorials on “Writing issues, comments and milestones”, we’ve captured most of the valuable lessons we’ve learnt along the way.

Our recruitment process is entirely done through the issue queue. 

Day-to-day operations, from buying new snacks for the office to dealing with HR or logistical issues. Need a new SSD for your Macbook? Create an issue on Github. Want to get sponsored to attend a conference in Beijing? Same deal.

Marketing efforts are discussed and led through the Github issue. This very post was discussed, planned and wrote on Github.

We’ve significantly increased participation. 

We’ve drastically raised transparency. Everything is done on Github, available for all to see and comment on. Processes like employee termination or tax payment are in the Wiki, for every new staff to check (and even collaborate to).

Github is where we go for everything we produce (content, design, code), discuss (issues, announcements) and document (guides, processes, documentation).
q..



 #kms - #cms - #wiki - #blogging - #business - #email - #collaboration - #blog_jr