The Tipping Point

In any organization, the work gets done through teams — sales teams, project teams etc.. Is their work suited for Wiki? What information within their work would lend itself nicely to wiki?

For example — software projects. Is wiki relevant in execution of software projects? How? what are the challenges? How to overcome those challenges?

Starting with the bread-and-butter documents, documents that need to be maintained within a project anyway are a good means of starting to use wiki. Evolving these documents in a Wiki instead of a word document is a quick win and will show the team the power of Wiki….

Things like project overview, roles & responsibility, infrastructure details, release & build processes, tips & tricks, Faqs, what to when.. etc etc..

There is much talk on Wiki being the next killer app and how it can potentially solve the world hunger problem

I wonder if Wiki is all hype or is there some truth to it? Why would an organization use wiki? or more importantly in what contexts would wiki be useful for an organization? What kind of organizational information lends nicely to be on Wiki?

In my view it depends on what is it that you want there? Could be organizational policies? Maybe NOT May be YES. It depends on how bold the organization is. Theoratically you can have mechanisms that ONLY few people in the oragnizationcan edit and change these policy pages and rest can comment on those. However this is against the fundamental spirit of Wiki and people are smart enough to recognize that fact and may get turned off [Having said that, even this would be a welcome approach if followed by organizations of involving all their employees and such approaches can be implemented though either Wiki or other regular smart web applications/content management systems].

What else could be there from an organizational context?
Processes? Could be a candidate where processes keep evolving — for example in IT industry where processes have to be tailored continuously for various kind of engagements. For example development processes in mainframe or embedded systems have things in common but are yet different at ground level, even within that we could have tailoring of processes for large/small engagements etc… The most suitable people to do this are all the practioners in the organization and what better way of doing it than Wiki?

Yes this is a radical approach — but so is wikipedia! If an organization can’t go the whole hog with allowing ALL practitioners participate in the evolution/tailoring of processes through wiki, the first step can be to have the team that is responsible for processes use wiki and then place stuff from wiki into the actual procceses repository…

Prevalent assumption within the organizations/barriers to Wiki: Wiki asa concept is radically different and contrary to the traditional top down, command & control approach [Which in their belief is tried and tested]. Users want to get the credit for work — in Wiki how do you define credit taking? , users want to control things [with wiki not just one but everyone who participates would get also get credit..] [With wiki, you can't control thoughts/ideas from other people..]

Some examples: journalist/authors use it to do write collaborative papers/articles..

The bigwigs of the Indian IT industry have announced that they will be recruting ‘graduates’ in their organizations. This move stems from the acute shortage of skilled manpower [read engineers] in the booming Indian IT industry.

There could be interesting ramifications to this:

- Consider that a recent report mentioned that only 25% of the hundred of thousands of engineers being churned out by engineering colleges are worthy of employment in a global context.

- Consider that in India, even today, the best brains go to enginnering colleges.

- The ones that are into ‘graduation [BSc, Msc etc..]‘ are NOT into it for the love of it, but are there because they are not cut out for engineering.

- Now if 75% of the so called best brains/enginners are NOT worthy of employment, just imagine what would be ratio of employable graduates.

I believe that this is a short sighted measure by Indian IT industry to cover for the deep ailments of skilled talent shortage. This could also lead to the ‘brahminical’ class culture within organizations — with good enginners being the neo brahimins and the graduates being the other class in the IT industry.

Also it is worth while to find out how many of the NON employable 75% engineers are from the ‘donation/private’ enginnering colleges — where admission is solely based on ‘money’ factor rather than academic factors.

It is really a sad fact that even today in India career decisions are made by parents [sometimes right from early years of a child] and that is what fuels this vicious circle…

Having said the above; there are some good sides to it though.

- This could go a long way in reining in the runaway salary hikes in the Indian IT industry. Companies would certainly be paying less to the graduates and the graduates would be happy to take it.

- IT professionals; who are not upto the mark or doing work that does not require engineering skills would face a reality check in terms of their career growth and salary hikes. Their work could be done by a graduate student.

- It could be a start of a new concept in Indian IT industry: ‘out-skill-sourcing’ . First you had only the computer science enginners/MCA’s as part of the software industry. As the Indian IT industry grew they took on engieenrs from other disciplines — mechanical, electrical, civil…. etc.. to fill in the skilled manpower shortage. Now having exhausted the pool of employable engineers they are looking at the next pool — the graduates. What next? housewives..!!?