Living with Enterprise 2.0

Meeting Agendas

We are a small company. But hey, small companies also have meetings. The meeting agendas are set up in advance, and as Stewart points out the agenda-links were sent out via e-mail. I emphasize the word "were" because we have been living with this way of working for a pretty long period of time. One of the many benefits with the Enterprise 2.0 way of working is that pull-factor. It is now my responsibility to know and change the agenda of the meeting I am attending. Via RSS-monitoring I have an easy way of knowing when interesting information is being changed. Of course we still send internal e-mails, but I strongly believe that reducing the e-mail floods is a good thing. 

We also use the wiki for meeting agendas when we are out seeing clients and when working with business partners. More on this topic below.

Meeting Minutes, and Action Items

When seeing a client they often have some type of questions. In some cases I can answer those and in other cases I cannot. If I directly write these questions down in a wikiarticle our Dev Team will read them and (I hope!) answer them. I can answer the client in a more correct way and I don't have to use the irritating phrase "...come back later".

Internally we love action items, both when for example an event is planned or when a new version of a product is being developed.

Project Management

Stewart Mader writes:

"People are already in the mindset to use the wiki, so assembling the proposal, reviewing and revising it together, and getting approvals can all be done on the wiki, which saves a lot of back-and-forth email, confusion about attachments, and time wasted."

Spot on. The mindset that Stewart mentions is the most important thing. When you have got the mindset in place, everything else will just work.

Gather Input

Sometimes this is better started with an internal blog post than in a wikiarticle. I will state my case/problem and my colleagues will comment on my post. Stewart is talking about access and permissions and in a large organization this is sometimes needed, but why not start with a simple posting on your blog and take it from there? The somewhat tricky question on when to use a blog and when to use a wiki I will save for another post. 

Build Documentation

As Stewart points out, this is a great way for a software company like us to, in an easy way, document our development. I will frankly say that my understanding of the code examples that the Dev Team are "wikiing" is pretty inferior, but they on the other hand don't understand Twitter that well so I guess we are even... ;) 

I do understand that their work environment is being facilitated by the wiki, and when I need some documentation (for example I was asked by one of our web agency partners about a specific version of our software) I just search the keywords and find it. Keep it simple.

Assemble and Reuse Information

When I need a "standard" text for a qoute I am writing, it is now in my mindset to search for specific keywords on our wiki. I know that the texts are edited by the right people, I know that they have successfully been used before and that they will fit in to my quote. I save a lot of time through the wiki when planning events as I reuse information, addresses and contacts. 

Employee Handbook

Our entire handbook is wikified. Everyone can change it. Again, maybe not so suitable for a huge organization but my point is that promoting openness within the organization is a really good thing. We of course have policies and a (in lack of a better word) "gentlemen's agreement" that limits me from changing our vacation period to 20 weeks /year. I can do it, but my name would be all over the change made and thus I stop myself. 

Knowledge Base

Stewart describes the knowledge base as being the first to be externally used. As I mentioned earlier in this post, we use wikis for external meeting agendas and action items as well. But Stewart is certainly right regarding the success in having an online knowledge base for customer support issues. An extensive knowledge base could of course be used internally as well. Just imagine a newly-employed coming to work and having access to several hundred years of collective experience through an Intranet 2.0. This will save huge amounts of time and money in my book.  


Please add your own experiences through the comments.

/Gustav