Your corporate environment will dictate the success or otherwise of your wiki implementation.
In many cases, just releasing access to a platform will bring benefits immediately,with staff eager to collaborate and share information. In other cases it will "die on the vine" without a concerted effort to drive usage, and work on the culture within he enterprise.
In any case, some pre-planning, and review of what you expect to achieve would be recommended for any enterprise, once a wiki is up and running, and being used, it can be difficult to make necessary changes along the way.
The technology is readily available from externally hosted SaaS models to in house hosted, or if you have time and money, develop your own! I have used both in house hosted, and external SaaS models, for me they were very similar, the benefit of the external model would be to simplify access for remote employees, rather then have them come back into the corporate firewall. This approach however may have some limitations depending on the data you are storing on the wiki (risk management may need to be involved).
The best approach is to give it a go! With a smallish team, willing to try something new, failure was not a major concern for us. We were willing to give things a go, and see what worked and what did not. Some of our thinking paid off, and some was not quite right, but in the end we are still running the wiki and it is still being used. the best part is, we have all learnt, and, corporate information now has a shared home we can all access.
Random stuff I am thinking about from time to time. Service desk, Enterprise 2.0, customer service, great presentations I come across, anything else that may take my fancy.
Showing posts with label wiki. Show all posts
Showing posts with label wiki. Show all posts
Friday, April 10, 2009
Thursday, April 9, 2009
Implementing a corporate Wiki - Tip 5
Leveraging the value
In tip 3 I spoke about visibility as Begin a driver for using a wiki, and that visibility should help you determine what information should go into a wiki. Taking that once information is starting to flow into the wiki, making it available to everyone is where the value starts to become apparent.
In my situation, getting information out to staff not based in the same city was important, and letting them read, comment, update, and access that information where ever they where, when ever they wanted beneficial. Expand the wiki access beyond your own department within the enterprise, so anyone can get actively involved, really starts to leverage the information you are building.
Any authorised employee should be able to be involved in your wiki, you never know where the next good idea may come from, and to have others reading and being involved in your discussions, bringing a new set of eye or thinking to your problem may be the answer you are looking for.
Expanding the use of the wiki to all enterprise staff also helps in ensuring everyone gets access to the information they deem to be important to them (sorry corporate message people, I find you miss the mark!) Corporate intranets are great for generic message's, but when staff need access to low level detail in order to do their job, or, to add their expertise to a problem outside of their department, a wiki is the answer.
Expand use, open to everyone, and accept their feedback!
There are my 5 high level tips for deploying a wiki into a corporate environment, along with some of my own experiences along the way. One more post to come to wrap it all up and give some ideas about technology
In tip 3 I spoke about visibility as Begin a driver for using a wiki, and that visibility should help you determine what information should go into a wiki. Taking that once information is starting to flow into the wiki, making it available to everyone is where the value starts to become apparent.
In my situation, getting information out to staff not based in the same city was important, and letting them read, comment, update, and access that information where ever they where, when ever they wanted beneficial. Expand the wiki access beyond your own department within the enterprise, so anyone can get actively involved, really starts to leverage the information you are building.
Any authorised employee should be able to be involved in your wiki, you never know where the next good idea may come from, and to have others reading and being involved in your discussions, bringing a new set of eye or thinking to your problem may be the answer you are looking for.
Expanding the use of the wiki to all enterprise staff also helps in ensuring everyone gets access to the information they deem to be important to them (sorry corporate message people, I find you miss the mark!) Corporate intranets are great for generic message's, but when staff need access to low level detail in order to do their job, or, to add their expertise to a problem outside of their department, a wiki is the answer.
Expand use, open to everyone, and accept their feedback!
There are my 5 high level tips for deploying a wiki into a corporate environment, along with some of my own experiences along the way. One more post to come to wrap it all up and give some ideas about technology
Wednesday, April 8, 2009
Implementing a corporate Wiki - Tip 4
Rules of engagement
To recap over previous posts, we have spoken about having the right culture, engaging your staff in wiki use with WIIFM, defining what goes into the wiki and why (visibility, version control, document management). In this post I will look at the rules of engagement.
Even though you may be seeking to develop an open community, every community needs some rules to abide by.
Wikipedia has an excellent etiquette page that any new wiki owner should take a look at. There are a number of rules in there that are worth at least thinking about in the context of your own wiki.
Corporate policies and guidelines also need to be understood and adhered to within the wiki space. If your current corporate policy does not cover the use of wikis it may be time to see if a new policy is required, or, can existing ones be extended.
Ensuring information is shared and the wiki is used as proposed is also important. Use the change agents to help move conversations and decision making processes out of Email and into the wiki. Dont maintain Email and wiki conversations, the rework will only double your work effort, and confuse people as to where to look for answers.
Rules of engagement is something we did not think about until it was really to late, laying out these ground rules early on I think would have helped with my take up rates as staff would have had a clearer understanding of how to use the wiki, not just why.
Next up, maximising wiki value!
To recap over previous posts, we have spoken about having the right culture, engaging your staff in wiki use with WIIFM, defining what goes into the wiki and why (visibility, version control, document management). In this post I will look at the rules of engagement.
Even though you may be seeking to develop an open community, every community needs some rules to abide by.
Wikipedia has an excellent etiquette page that any new wiki owner should take a look at. There are a number of rules in there that are worth at least thinking about in the context of your own wiki.
Corporate policies and guidelines also need to be understood and adhered to within the wiki space. If your current corporate policy does not cover the use of wikis it may be time to see if a new policy is required, or, can existing ones be extended.
Ensuring information is shared and the wiki is used as proposed is also important. Use the change agents to help move conversations and decision making processes out of Email and into the wiki. Dont maintain Email and wiki conversations, the rework will only double your work effort, and confuse people as to where to look for answers.
Rules of engagement is something we did not think about until it was really to late, laying out these ground rules early on I think would have helped with my take up rates as staff would have had a clearer understanding of how to use the wiki, not just why.
Next up, maximising wiki value!
Tuesday, April 7, 2009
Implementing a corporate Wiki - Tip 3
Define use
There certainly can be confusion as to why you are implementing a wiki, what information goes in there, when do we use a wiki over Email?
The best approach is to explain why you are implementing a wiki, and then decide based on that, what information should find its way in there. My approach is that "conversations" need to occur in the wiki, anything where a decision is being sought, or, ideas need to be shared to find an outcome.
So, in defining how you are going to use the wiki, you need to understand why you are using it -
- Visibility, the wiki will allow everyone who has access to the information to be able to see it when they need to. People are not left out of Email lists, and people are not bombarded with Emails that are not relevant to them.
- Version control, the wiki version of a document or conversation is the most recent version. No need to track back through Emails to try and find where something is up to. I often find it difficult to locate the most recent version of a document, or, Email conversation, the wiki removes this issue.
- Everything in one place, supporting documents, attachments, etc can all be attached to the wiki entry. Rather then having this supporting information live on someones local hard drive, or, lost in a corporate server, it is just where it needs to be.
Following these concepts on why you would use a wiki, will assist in defining what you put into the wiki, and this will help everyone in understanding why it is being use, and how they can get value from it.
Next up, the rules of engagement
There certainly can be confusion as to why you are implementing a wiki, what information goes in there, when do we use a wiki over Email?
The best approach is to explain why you are implementing a wiki, and then decide based on that, what information should find its way in there. My approach is that "conversations" need to occur in the wiki, anything where a decision is being sought, or, ideas need to be shared to find an outcome.
So, in defining how you are going to use the wiki, you need to understand why you are using it -
- Visibility, the wiki will allow everyone who has access to the information to be able to see it when they need to. People are not left out of Email lists, and people are not bombarded with Emails that are not relevant to them.
- Version control, the wiki version of a document or conversation is the most recent version. No need to track back through Emails to try and find where something is up to. I often find it difficult to locate the most recent version of a document, or, Email conversation, the wiki removes this issue.
- Everything in one place, supporting documents, attachments, etc can all be attached to the wiki entry. Rather then having this supporting information live on someones local hard drive, or, lost in a corporate server, it is just where it needs to be.
Following these concepts on why you would use a wiki, will assist in defining what you put into the wiki, and this will help everyone in understanding why it is being use, and how they can get value from it.
Next up, the rules of engagement
Monday, April 6, 2009
Implementing a corporate Wiki - Tip 2
WIIF - Whats In It For Me?
Lets assume for arguments sake that a open and sharing culture does not exist in the enterprise. Why would your teams want to contribute to a wiki, whats in it for them?
People wont put in, unless they can get something out. For the team I was working with, the remote staff were used to doing their work without collaboration, and if they did not know the answer to a question they would then either try and find it, or, the customer would just not get that service. Many staff were also not aware that a problem had already been solved, and thus would go about solving it again introducing costly re-work to the process.
So, explaining the virtue's of wiki collaboration to all staff is important, but, framing the "Whats in it for me" message is critical to getting buy in, staff need to get a reward for their effort (and I am not talking about pay increases!).
The problem we all face here is that we will generally start with a blank wiki, so I am putting information in during the early days, but there is little information for me to take out, and thus interest slows very quickly as it is seen only as an administrative waste of time. There are three approaches to this problem -
1. Pre-populate with information already available
2. Identify change agents, and ensure they keep populating and promoting
3. Ensure the use of the wiki is well defined, and that you are not duplicating activity
Point 1 - It would generally not be the case where information could be ported into a blank wiki to get things going. If you can do this, then do, but be sure that you are not importing irrelevant or out of date information. It would be better to leave that behind (refer Tip 3)
Point 2 - Change agents are very important. They can see the goal, and will continue to push on during the tough times. Identify the people who will act as a change agent, and support them in getting information into the wiki, and promoting its use to their colleagues. Over time it will generally become obvious to everyone what you are trying to achieve, and the value you are adding, however it does take time for some people, and I think you need to give them the time to work it out. Your change agents are critical in "keeping the dream alive"
Point 3 - I will elaborate more on this one in my next tip! (tip 3)
Lets assume for arguments sake that a open and sharing culture does not exist in the enterprise. Why would your teams want to contribute to a wiki, whats in it for them?
People wont put in, unless they can get something out. For the team I was working with, the remote staff were used to doing their work without collaboration, and if they did not know the answer to a question they would then either try and find it, or, the customer would just not get that service. Many staff were also not aware that a problem had already been solved, and thus would go about solving it again introducing costly re-work to the process.
So, explaining the virtue's of wiki collaboration to all staff is important, but, framing the "Whats in it for me" message is critical to getting buy in, staff need to get a reward for their effort (and I am not talking about pay increases!).
The problem we all face here is that we will generally start with a blank wiki, so I am putting information in during the early days, but there is little information for me to take out, and thus interest slows very quickly as it is seen only as an administrative waste of time. There are three approaches to this problem -
1. Pre-populate with information already available
2. Identify change agents, and ensure they keep populating and promoting
3. Ensure the use of the wiki is well defined, and that you are not duplicating activity
Point 1 - It would generally not be the case where information could be ported into a blank wiki to get things going. If you can do this, then do, but be sure that you are not importing irrelevant or out of date information. It would be better to leave that behind (refer Tip 3)
Point 2 - Change agents are very important. They can see the goal, and will continue to push on during the tough times. Identify the people who will act as a change agent, and support them in getting information into the wiki, and promoting its use to their colleagues. Over time it will generally become obvious to everyone what you are trying to achieve, and the value you are adding, however it does take time for some people, and I think you need to give them the time to work it out. Your change agents are critical in "keeping the dream alive"
Point 3 - I will elaborate more on this one in my next tip! (tip 3)
Sunday, April 5, 2009
Implementing a corporate Wiki - Tip 1
Corporate Culture
If the nature and culture of your enterprise is not one of openness, sharing and collaboration, then a tool to assist with these things is not going to help or change the way your enterprise operates.
Understand the nature of how people work within your enterprise today, if it is a closed non collaborative environment then that will need to be addressed before any technology is added to the equation (refer some of the up coming tips for helping people to change). Adding technology to a closed environment will fail, the people are just not ready.
If your culture is one of openness and collaboration, then the enterprise should be screaming for a wiki, implementation should be easy.
I faced a bit of a mixed culture, centrally located staff were already sharing and collaborating, and could see the benefit of the wiki from day one. Staff based outside of the head office, more used to working alone, struggled to see what benefit it would add as they were not used to sharing. They would see it more as an administrative overhead, rather then as adding to the value of the team. We struggled to address this cultural gap, and keep working on it today as i will explain in some of the future steps.
If the nature and culture of your enterprise is not one of openness, sharing and collaboration, then a tool to assist with these things is not going to help or change the way your enterprise operates.
Understand the nature of how people work within your enterprise today, if it is a closed non collaborative environment then that will need to be addressed before any technology is added to the equation (refer some of the up coming tips for helping people to change). Adding technology to a closed environment will fail, the people are just not ready.
If your culture is one of openness and collaboration, then the enterprise should be screaming for a wiki, implementation should be easy.
I faced a bit of a mixed culture, centrally located staff were already sharing and collaborating, and could see the benefit of the wiki from day one. Staff based outside of the head office, more used to working alone, struggled to see what benefit it would add as they were not used to sharing. They would see it more as an administrative overhead, rather then as adding to the value of the team. We struggled to address this cultural gap, and keep working on it today as i will explain in some of the future steps.
Saturday, April 4, 2009
Implementing a corportate Wiki
I love the idea of staff collaborating, sharing ideas and knowledge, and assisting each other to find new and better ways of supporting our customers.
The knowledge and experience of the team, far out weighs the knowledge and experience of any one individual within the team.
Given that, late last year I thought it would be a good idea to implement a wiki for my team. I must admit, at the time I was not sure how we would define the value of the wiki, nor how we would know if its use was a success, however it seemed obvious for some reason that this is what we should do. On a side note, read Malcolm Gladwell Blink: the power of thinking without thinking, you will get a better feel for why you should "follow your gut" sometimes.
I also was not sure how the use of the wiki would fit in with the use of Email, instant messages, meetings, etc. What communication would happen where? We jumped in with both feet despite the unknowns, as the only way we would learn was by giving it a go.
Over the next few posts I will go over some of our learning's from our great wiki experiment, in the interest of sharing what we have learnt, but first some quick background information -
- I have a team geographically dispersed around Australia, with the corporate office based in Melbourne.
- Support desk services are based in Melbourne, with business consultants in other Australian capital cities, and, generally out with customers in their offices.
- We need to work in the multiple time zones Australia has to offer
- Staff need to get access to information from all the locations they work, corporate office, customer office, home, and sometimes while mobile.
- Different staff have different skills and experience that I wanted to be able to tap into and leverage across the rest of the team.
Next up, Wes's 5 steps to wiki heaven!
The knowledge and experience of the team, far out weighs the knowledge and experience of any one individual within the team.
Given that, late last year I thought it would be a good idea to implement a wiki for my team. I must admit, at the time I was not sure how we would define the value of the wiki, nor how we would know if its use was a success, however it seemed obvious for some reason that this is what we should do. On a side note, read Malcolm Gladwell Blink: the power of thinking without thinking, you will get a better feel for why you should "follow your gut" sometimes.
I also was not sure how the use of the wiki would fit in with the use of Email, instant messages, meetings, etc. What communication would happen where? We jumped in with both feet despite the unknowns, as the only way we would learn was by giving it a go.
Over the next few posts I will go over some of our learning's from our great wiki experiment, in the interest of sharing what we have learnt, but first some quick background information -
- I have a team geographically dispersed around Australia, with the corporate office based in Melbourne.
- Support desk services are based in Melbourne, with business consultants in other Australian capital cities, and, generally out with customers in their offices.
- We need to work in the multiple time zones Australia has to offer
- Staff need to get access to information from all the locations they work, corporate office, customer office, home, and sometimes while mobile.
- Different staff have different skills and experience that I wanted to be able to tap into and leverage across the rest of the team.
Next up, Wes's 5 steps to wiki heaven!
Subscribe to:
Posts (Atom)