Monday, May 12, 2008

Group Smart

Reflecting upon James SuroWiecki book on Wisdom of Crowds, it's captivating to see how group can turn out to be smart or dumber. I like this paragraph of his writing especially

"... the truth is that, especially when it comes to problems when there is no right or wrong answer, there's no guarantee that the most-informed speaker will also be the most influential. On juries for instance, two-thirds of all foremen - who lead and structure deliberations - are men, and during deliberations men talk far more than women do, even though no one has ever suggested that men as a gender have better insight into questions of guilt and innocence. In groups where the members know each other, status tends to shape speaking patterns, with higher-status people talking more and more often than lower-status people. Again, this wouldn't matter as much if the authority of higher-status people was derived from their greater knowledge. But oftentimes it doesn't. Even when higher-status people don't really know what they are talking about, they're more likely to speak. A series of experiments with military fliers who were asked to solve a logic problem, for instance, found that pilots were far more likely to speak convincingly in defense of their solutions than navigators were, even when the pilots were wrong and the navigators were right."

Someone is not always smarter than everyone in all instances. When there's a working group or team, allow others to speak at equal levels. While this is almost common practice in our era, group decisions can still go both ways - smarter or dumber.

Generally, groups get dumber in cases of information cascade, whereby ideas, solutions or discussions are built on top of the other in one direction. Some people do this to maintain harmony within the group, give in to higher authority, come to common consensus, achieve group buy-in, or simply because they are short of ideas themselves. While this may be good in certain ways, it sure compromises the quality of the decisions.

A group makes good decisions when it is diverse and its members independent. In simple terms, its best when everyone in the group gathers their own information (either from existing or external) and are allowed to contribute without affecting or being affected by another's information. There are some simple steps to make this happen, I'd like to call this the Group Smart method:

  1. Identify participants who are likely to have individual information or knowledge of the problem. Invite them to a meeting
  2. Allow the participants some time after the problem is presented to gather their own thoughts and information individually. Present the problem before the meeting if it requires significant time to prepare or take it offline if a complex problem is surfaced during a meeting. The idea is to give each member enough time to prepare his information.
  3. A facilitator must be present to ensure that the problem can be further elaborated without allowing participants' thought to affect each other.
  4. After each participant is satisfied with his information, the facilitator can then collect the information from each participant individually.
  5. Upon collecting all information, the facilitator reads out all information in random fashion and allows the group to contest each other. Each participant may attempt to guess who contributed the information, but the luxury of 'supposedly I don't know who it's from' mentality will allow each piece of information to be contested fairly.
  6. While the group is having the discussion, the facilitator needs to ensure that all participants have the chance to speak up. The facilitator also has to pick up constructive comments that would steer the group's judgment.
  7. A summary on the trail of decision-making is presented at the end of the discussion. The facilitator will highlight any information that has not been included in the decision making process.
  8. The group can agree on the outcome of the decision or iterate the process of argument based on new information.
A good decision is one that passes through a good level of constructive arguments and accepted at the end by the group.

Friday, March 7, 2008

The Starfish and the Spider

A simple book to understand, an engaging book to read.

The Starfish and the Spider corresponds to the decentralised and centralised organisation respectively. Why starfish?... Cut a starfish in half, and the 2 parts grow into completely normal starfishes. A starfish is resilient, it's hard to destroy one. Whereas the spider gets destroyed when the head is cut off - in a centralised organisation it means the HQ or a critical function.

Since we are so used to the centralised organisation,
the authors Ori Brafman and Rod A.Beckstorm give more emphasis to the characteristics and makeup of the decentralised organisation. However, I find the book well-balanced - it praises about decentralised organisation but at the same time shares how to cripple one. Towards the end, it advocates that organisations need to take the hybrid approach, i.e. the right balance of centralisation and decentralisation to find the sweet spot.

This book shares many clear and interesting examples. For instance, on how Spain fail to dominate the Apaches because they operate in a decentralised fashion, and how the Apaches
eventually fell because they were given cows. And examples on how low cost companies make use of decentralisation to create network effect to generate million-billion dollar revenues - eBay, IBM, craiglist, and etc... And on the contrary how fully decentralised organisations don't actually profit - AA (Alcoholics support group) and eMule.

What interest me is the leadership qualities and roles that must prevail to sustain a decentralised organisation. It really requires a lot of guts and trusting personality. For example, it cites that Jimmy Wales of Wikipedia believes that people are generally good and that the best people who know are out there, and not just a few known experts. This idealogy is strongly propagated through his company, which made Wikipedia comparable to Britannica.

I would definately recommend this book for people who are looking for ways to create the environment for innovation, improve employee morale and motivation, and build resilience within an organisation.

Friday, February 29, 2008

Wikinomics


Wikinomics exposes the reality of today's collaborative climate. It highlights the competitive challenges faced by traditional, self-sufficient organisation. Organisations should reach out and beyond its organisation boundaries to innovate, produce goods and solve issues.

Wikinomics is based on 4 key principles - Openess, Peering, Sharing and Acting Globally.

Openess means allowing a firm's pertinent information and key assets to be made transparent. Amazon, eBay, Google and flickr open up their applications and business infrastructures to increase the speed, scope and success of innovation.

Peering harnesses human capital brought together by a common interests or motivation that is beyond the organisation. IBM joins the Linux peer producers and pumps in millions of dollars to support its development. Through this, IBM saves on development, gain in selling professional services for Linux-related services and hardware.

Sharing is a prevalent culture with the rise of Web 2.0 public platforms such as Flickr, YouTube and even peer-to-peer platforms such as eMule. Lego shared it's Mindstorm product source code which ultimately enable customers (or prosumers they call it) to innovate new add-ons which eventually help sustained the core Mindstorm product.

Acting Globally is about tapping into the global expertise and partnership to reduce cost, time and risks associated with product and service delivery. Boeing is one such example who has cocreated its 787 aircraft with a network of partners that stretches over 6 countries.

The book has a lot more examples of wikinomics in action and it's definitely a supplement for firms who are looking for innovative and bold ways to be in the forefront.

Sunday, January 20, 2008

Launching the Intranet as a "by-product"

It's been a long and challenging journey to develop and implement an Intranet and it's now ready for launch. A launch celebration or at least a proper communication is a must's must. We start to think about inviting the CEO to give an opening address, conducting briefings to marvel what the new Intranet has and can do. We get a healthy budget to cater food for everybody and maybe throw in several competitions and games to liven the launch event. And at the end of all that celebration, most people are probably going to just leave thinking that the food was good and feel happy with a good break from work.

The important thing here is to acknowledge the Intranet as an enabler, not a driver. We want staff to trust the information on the Intranet so they will seek and use it. To achieve this, we should attempt to make the Intranet as a mere "by-product" during launch.

By-product, what does it mean?
During the launch, the focus can be for the various departments to update staff on the latest policies and work processes, recreation clubs to use the launch event as a recruitment drive, and the latest events and corporate communications to be highlighted. These are some significant matters that staff relate to. What we need is to mandate everyone who is speaking at the launch event to use the Intranet as the only visual communication medium. In this way, staff sub-consciously registers that the information is there on the Intranet and starts to build trust for the information quality on the Intranet. Staff will make repeated visits to the Intranet
when there is trust.

The other good thing this approach does is that it involves various part of the organisation to participate in the launch and not just the project team. After all, the corporate Intranet is a corporate wide asset.


Friday, January 4, 2008

Bottom-up approach to taxonomy development

In my previous post, I brought up a topic on the implementation challenges of taxonomy and suggested a few points on overcoming pitfalls for multi-faceted taxonomy implementation. This time round, my reflection is based on ground 0, where there is no corporate taxonomy design to start with.

This idea requires incremental and continuous investment and its not a short project period affair. Like the Chinese saying goes, "Cast a long line to catch a bigger fish".

Step 1 - Implement a simple DMS
If there aren't any Document Management System (DMS) to start with, work with your IT department to invest and setup a really affordable one. There are good open source CMS solutions in the market. Get one that supports tagging and have the ability to export these tags at the document or content chunk level in a standard format such as XML.

Step 2 - Document migration and housekeeping
Get everyone to migrate their folders and document to the DMS and perform housekeeping at the same time. At the department level, tell them to create, organise and label folders as they like. But give these guidelines:

  • each folder should not contain more than 15 sub-folders or documents (human beings are generally comfortable with 8 - 15 items in a cluster)
  • the number of folder levels should not exceed 7 (this prevents document from gaining too much depth making it hard for others to find or discover)
Step 3 - Describe documents
Create 2 manually entered metadata fields - Title (of document) and My tags (comma delimited keywords describing document). New documents or document versions captured in the system must be profiled with these 2 fields. The Title can be defaulted to the filename without the file extension. With My tags, the process of self-describing documents begins. Make the tag clouds of individual contribution available at all times so that they can be mindful to reuse their previous labels. Encourage the tagging of important or useful documents that have been migrated.

Step 4 - Create relationships
If the current CMS doesn't support this step, export the document metadata (including title, my tags and other automatically captured data such as date modified, author and etc). At this point, take each document as a central focus with metadata wrapped around it. Consider 3 documents with the following My tags and title
  1. Title (Lifestyle of a diabetic), My tags (lifestyle, diabetic, diabetes, food, exercise)
  2. Title (Medication for diabetes), My tags(diabetes, medicine, tablets, insulin)
  3. Title (Diabetes resource), My tags (diabetes, blogs, advice)
The common tag of the above example is diabetes. We can now draw relationships using diabetes to make documents on lifestyle, diabetic, food, exercise, medicine, tablets, insulin, blogs and advice to appear upfront. And in this, we are helping the diabetic make discovery of what he may want to know. When we link food to another set of documents with food in My tags, we form another cluster of information around food at the next level (which is now becoming less relevant to diabetes). The title can be split into words and each word to simulate a tag, useful especially for older documents that are not tagged.

These relationships form a dynamic taxonomy with many facets depending on the number of labels that matches your search term(s) (food, diabetes, lifestyle or etc).

Step 5 - Making the search results manageable
We may end up with huge number of document entries for diabetes and the levels below it. This is where the tags and other metadata can be helpful. We can filter the documents by tag labels, author, date modified and etc to find the latest and relevant documents.


Benefits
  • Surfaces information around a topic very early in a tree. Unlike traditional navigation systems that help you find the exact document by traversing trees, all documents relating to the domain of interest is presented upfront and gets less relevant as you traverse down the tree. So you traverse to make sure you don't miss out anything important and you are unlikely to go deep.
  • Less likely to run into the problem of missing a document located in another branch of a conventional taxonomy.
  • More meaning and context to diabetes are added as more documents are tagged with diabetes. Within an organisation, this means the knowledge base around a particular domain.
  • You choose what you want/don't want to know about the topic by filtering, and get exposed to what you didn't thought could be of use in the first place.

Documents are made miscellaneous in this manner and not limited by the conventional view of a taxonomy. The next powerful thing, instead of providing comments and rating after reading a document, social tag it.

Monday, December 17, 2007

Implementation challenges of taxonomies.

A taxonomy (check out Patrick Lambe's great book) can help make sense and give context to a piece of document. Multi-facetted taxonomies thus provides more ways for sense making a piece of document to support the various mental models of perceiving the document. At a corporate level, it facilitates sharing and collaboration through the common labels we use for the taxonomy categories. So we see the benefits and we go through months of research and design activities to develop the taxonomies.

Then it comes to implementation. The number one issue now is to avoid complex metadata profiling. It is a nightmare for staff to browse the tree of each taxonomy facet to profile a document uploaded. Profile it once, twice and if he is patient enough, he will stop at the third time. And thereafter, you will expect the remainder of the documents to be in his local drive, circulated through emails. How do we avoid this pitfall?

Here are few points for implementation:

Let departments design their own folder structures
When it comes to implementation, we can create physical departmental folder structures that are based on the taxonomy categories from the different facets. Some benefits of this approach

  • Makes the physical structure useful to the department.
  • These physical folders will associate to the various taxonomy facets to allow browse and search for the rest of the organisation.

Use My Tags when profiling
Keywords contributed by document creator to describe the document. Remember how un-managed shared folder structures that are ambiguously named after staff and labels that makes little sense to you? While you are unlikely to visit these folders, the creator of these folders keeps coming back, because it makes sense to him. My Tags gives the document contributor his true own space on how he should call it.

Employ a librarian
A librarian can leverage on My Tags to improve the taxonomy and more importantly for a start - to associate natural language to the corporate taxonomy, thus making the document available to more facets. The librarian just have to manage emerging labels to do this. So the librarian should have to do less over time. So it's very much similar to maintaining synonyms around taxonomy labels (we should use taxonomy labels as authoritative terms)

Expose taxonomy trees of sibling documents
When the taxonomy trees of sibling documents are collectively exposed, it motivates the document contributor to select the ones the are currently applicable. Put simply, when someone go through the effort to select, they want others to be able to find it. So reusing the existing trees increase the chances of others finding their documents. It also makes it much easier compared to browsing taxonomy trees from the top. Furthermore, they get motivated because it is prove that someone else has gone through the same process of selecting taxonomy categories.

Allow browsing from the top too!
There will be times when there are no sibling documents, no appropriate taxonomy trees from the sibling documents or the contributor just wants to profile more. We should thus allow selection from the top of each taxonomy facet. Allow each taxonomy facet to expand. While expanding, simultaneously put a tick beside each taxonomy label to indicate the categories selection. It's fine if the taxonomy tree is expanded half-way (stopping at a branch). We should not mandate the document contributor to expand to the leaf of the tree.

To summarise, sharing is a natural act. We should support the natural way people sense-make information and every individual do it slightly differently. My Tags is natural and encourages personal ownership and interests. When the profiling activity is not so natural, crack your head to make it really easy for document contributors.

Thursday, December 13, 2007

The Information Architect - your partner, not vendor

Information Architect as part of vendor's project team
It seems logical to find a vendor team that is made up of competent people for your web redesign project. Typically, the vendor team will not have an in-house, qualified Information Architect. This means the vendor will most likely source for a short-term Information Architect to be their partner in project.

Sounds good. You have a vendor project manager who is going to coordinate the activities with their partner Information Architect. As customer, you get the end product hassle free.

Not really a good idea, here's why...
The vendor is most likely going to scope the Information Architect's involvement. This means the Information Architect gets paid by the vendor according to the prescribed work. This creates a conflict between the two. A good Information Architect who value adds to the work will mean more work for the vendor to develop, test and implement. The vendor can also discourage the Information Architect by citing excuses such as system limitations and some designs that are good to have and not necessary. Furthermore, the vendor may turn out to hire an a low cost, less experience
Information Architect to reap higher profits. Worst still, the vendor may mandate for all communications to the architect to go through the vendor's project manager and the PM may not be a very good messenger, thus delaying the schedule and causing communication errors.

What should we do?
Having a good Information Architect is more critical than getting a good Intranet system. And it's many times harder to find a good architect than to find a good Intranet system. Put more emphasis on selecting a good architect. Make the architect part of your project team. Let the architect represent your organisation's interest when dealing with the vendor, give him the authority to do so. In this way, this frees him from the otherwise politics, allows for greater creativity and quality work.