In a technical project of any size, the sharing and understanding of knowledge is key to the success of the project. The traditional approach in business to solving this problem is to document everything.
However, the problem with this traditional approach is that it implies written and printed paper documentation that not only takes up employees' valuable time, but collects over time and is often never looked at again. As such, and understandably, there is a resistance from staff to undertake this traditional approach. This resistance has become so dominant that I would even go as far as to say that techies, on principle, detest doing written/printed documentation and try to avoid it at all costs.
Enter the light at the end of the tunnel - the fruition of the popular Wikipedia! This emergence has, among other things, brought the ease with which knowledge can be shared to many people's attention. Added to this is the obvious benefit of only having one, always-up-to-date copy of the knowledge, and, more importantly, having it online - making it easy to access anywhere, anytime. Techies are becoming familiar with the benefits of Wikipedias and as such, are beginning to embrace this online free encyclopaedia as a place where they can not only share, but also derive knowledge from.
Consequently, this has resulted in more and more technical projects undertaken nowadays, having a project Wiki, which in essence becomes an interactive Web page that allows the entire project team to constantly view, edit, use, update and comment on the collective knowledge about the project. By nature, the content is fluid, which corresponds to the nature of the underlying domain and ultimately the project, contributing to improved project planning and management.
Quick knowledge-sharing
[A project Wiki] can be maintained from anywhere, immediately, and is visible to everyone who needs access to it.
Cor Winckler is technical director of PBT
In the professional field of business intelligence (BI), the business is constantly changing, which means requirements are constantly altering. A project that has a specific project Wiki set up for it allows for the explanation to the rest of the team of how and why things are done in a particular way.
The great thing about this is that it can be maintained from anywhere, immediately, and is visible to everyone who needs access to it. What's even better is that techies seem to like working with a project Wiki, certainly dissolving initial resistance to the traditional approach.
Possible reasons for this adoption include the following:
* It is easy to use
* It is descriptive
* It is collaborative
* It is alive (as opposed to the project file gathering dust on the shelf)
* It is shared and used by others - people give and take from the Wiki project
* It keeps stats of who contributes most often, which makes for healthy competition in the team
* It is addictive
* It is a technical concept after all - no wonder techies like it
All of the above represent a phenomenon that makes the process of sharing knowledge easier for everyone involved on the technical project. The result, a happier team, as all involved are aware of what is going on and time is saved, allowing the team to focus on other important elements to the project, rather than documentation.
Implementing a project Wiki into a technical assignment is certainly a more modern answer to the problem of knowledge sharing and, as such, I would recommend that techies who have not experimented with a project Wiki download the trial version and try it out today. It is, however, important to fully understand the concept to ensure it is used correctly to gain maximum value for team members working on just about any technical project.
From customised documentation, sharing of knowledge and a little dose of addiction, Wikis are a novel solution to an age-old problem, making the possibilities of BI projects endless.
* Cor Winckler is technical director of PBT
Share