The importance of culture when implementing new technology

Thanks to Bertrand Duperrin, I found out that only 6 days ago, Peter Evans-Greenwood (Cap Gemini CTO in Australia) posted on his company's very good "CTO blog" his thinking on the importance of organizational culture when implementing new technology and in particular Enterprise 2.0. Do read it. It is totally in line with my last post.

Finding the right person to help with a problem

Here is a basic but hugely rewarding problem to resolve: “Finding and contacting the right person (or group) within an organization to help with a problem”. The problem can be anything that can benefit from the input of someone with a relevant expertise. How do you do this in an Enterprise 1.0 environment (in other words, in most organizations today)? Well, all too often you simply don’t bother trying! Why? Because you know it’s likely to cost you more resources (usually time) than you are prepared to invest, and where there is no certainty to succeed (in finding a useful soul). Furthermore, even if you did take the trouble to search and eventually find someone, there is then no guarantee this person will have the time to help you quickly enough ) or even want to help you!). So it is often easier to instead choose one of the following 3 alternatives:

• Work out the solution to your problem yourself with the people you already know and work with. In other words, you probably will reinvent the wheel.
• Seek external help and usually have to pay for it. Might be faster and more effective than doing it yourself but will probably be more expensive.
• Leave the problem unresolved and maybe find a (less efficient/effective) way around it (trust me, this option is chosen more often than you would think).

Why is it typically so difficult and taking too long to find someone with specific knowledge within an organization? For at least these 5 reasons:

• Knowledge-sharing is not part of the corporate culture, so people are not expected and not expecting to help outside their “normal” job/responsibilities (see my list of traits of a culture not conducive to knowledge-sharing here and here)
• Lack of adapted collaboration tools (Web 2.0)
• Lack of “Who has done what” or “Who knows what” repositories (and not just “who’s who”).
• The larger the company, the more difficult it is.
• The more geographically dispersed the company, the more difficult it is.

Now, this should mean that if you deal with the first 3 points above, you’re on your way to solve the problem. Yes, this is the way forward and this is what Enterprise 2.0 initiatives are supposed to do. HOWEVER, the most important point is undoubltedly the first one. If people don’t want to share/help (for different reasons) it won’t matter what bleading-edge tools you will give them access to, they won’t use them at all or not for the reasons you would like them to (of they use them because they are told to do so, you won’t get the ROI intended).

So I am suggesting that Enterprise 2.0 = Web 2.0 + a cultural change.

Also, I now think this cultural change must be initiated from the grassroots, from the people on the front lines in the organization, and not directed by the top-management. My position on this has somewhat evolved since my first post on PKM . Instead of stating that traditional KM (management-lead) must come first and then allow PKM to support it, I now believe that the opposite has more chance of success. You should encourage PKM (user-lead initiatives) and then formalize at a company level the most popular solutions (my reading of “The Mashup Corporation” book on SOA has something to do with it). This is also Google’s successful business model to focus on satisfying the user, as opposed to Microsoft that focuses on satisfying the Management. In the long run, Google’s model will win it and Microsoft will need to adapt or die.

“Three dozen knowledge sharing/collaboration barriers” compared with my “cultures not conducive to knowledge sharing”

I have recently been made aware (on ActKm listserve) by Shawn Callahan of one of his blog post dated 03/09/06 and titled “Tree dozen knowledge sharing barriers”. Shawn was commenting on an article written by Andreas Riege (with the same name as the post).

I thought that it could be interesting to compare Andreas’ list of barriers with my list of 16 “not conducive to K sharing” cultural traits.

First, I excluded the technological barriers as these are not directly linked the organizational culture.
From the remaining 29 barriers, I manage to make 15 of them correspond to at least one of 12 of my traits. So they were mutually confirming each other.
One barrier can actually be linked to nearly all of my traits: “Existing corporate culture does not provide sufficient support for sharing practices”.

This left the following 4 cultural traits not addressed by Andreas’ list:

2. Focus on short-term objectives: the “no need to share knowledge since once objectives are met, it wont be needed anymore” syndrome.

11. Job Description framing: The 'No-one's paying us to have a wider vision' syndrome.

13. Only money talks: The 'those so-called stakeholders aren't actually funding anything directly, so they're not real customers' syndrome.

15. Modesty resulting from lack of encouragement: the 'who am I to teach others, of course they know' syndrome.

From the 14 barriers not linked to a cultural trait, I identified only 4 that each warranted a new cultural trait in my list. Here are the 4 new traits with the associated syndromes:

17. Dominance of explicit over tacit knowledge sharing:
The 'we only truly value what is written down and validated' syndrome.

18. Lack of social networks:
The 'only networks supporting business processes are important and encouraged' syndrome.

19. Lack of knowledge management strategy and sharing initiatives into the company’s goals and strategic approach:
The 'Intellectual Property is the only Intellectual Capital that is worth managing strategically' syndrome.

20. High internal competitiveness within business units, functional areas, and subsidiaries:
The 'we only share knowledge within our team since everyone else is potential competition' syndrome.

So that makes now 20 traits of organisational cultures not conducive to knowledge-sharing.

If you identify one missing, please let me know.

I suppose I must thank you all...

Sorry for a bit of self gratification but I had to tell you about this.

I have been approached recently by Colleen Carmean, a PhD candidate at Capella University, researching new tools and practices in informal, just-in-time, self-regulated learning that contributes to organizational knowledge and effective business practices.

Colleen asked if I was interested in contributing to her research. I accepted with pleasure but what I really had to mention here on my blog is the fact that her research started with a selective analysis of Knowledge & Learning related sites (http://cmcarmean.googlepages.com/tappingknowledgeintheblogosphere ).

Colleen explains on her site:

“The study tapped into the Blogosphere's version of both popularity and peer review to determine trusted "experts" who are writing about:

• organizational knowledge
• organizational learning
• just in time learning
• informal learning
• emergent learning. “

Starting with 885 sites, Colleen ended up with a list of the 24 most trusted sites and guess what? This site you are reading now is among them!

So I must thank you all, regular readers of my blog, for your encouraging support.

Colleen then writes to define her objective:

“it is the intention of this study to gather knowledge on effective design and support of environments for shared knowledge via collective inquiry by community-identified and connected experts. How we can best design and support emergent learning in the creation of organizational and shared knowledge?”

I wish Colleen success for her PhD and no doubt I will write again about it.

Peter-Anthony Glick

It was about SOA all along! Chapter 7

[Continuation of my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].

Chapter 7 is about the “typical” barriers to implementing SOA throughout an organization. The authors added this chapter in the 2nd edition following a suggestion by Avrami Tzur (VP of SOA at HP). I will start by saying that I was a bit disappointed with this chapter: it does literally focus on the specific resistance to SOA without considering the probable more generic reasons for this resistance. But maybe it’s me again expecting cultural issues to be mentioned everywhere! At least, this chapter has the merit of existing. I am sure Avrami was far from being the only one noticing the need for addressing this topic after reading the 1st edition of the book.

This chapter deals with the fears and needs of technologists - used to a “develop and control” centralized infrastructure – that are being asked to adapt to SOA and the flexibility, openness and informality that comes with it. These fears and needs would typically raise questions such as:

• How do I know what services are available for me to use?
• How do I know exactly what each service does?
• What happens when a service I am using is changed or upgraded?
• What happens when I have to debug an application based on services?
• How does the new world of services fit and interoperate with existing IT systems? Etc,…

Five rules are then proposed to encourage adoption of SOA:

• Use visibility to reduce fear, build trust
• Put it in writing
• Extend existing management processes to SOA
• Support new pattern of collaboration
• Provide incentives for SOA adoption
  

The authors do introduce these rules as enablers of communication and knowledge sharing. I agree. However, if your organisation has a command and control culture where knowledge sharing is not the norm (I take you back to my 16 traits of such a culture) following these 5 SOA adoption rules won’t be enough. But maybe it could be argued that a “command and control” organisation would not initiate a SOA in the first place (now that could be a topic for a lively debate).

The authors do explain that the << adoption of SOA do reflects an evolution in the skills and systems of a company >> ( I would like to add that it reflects an evolution in the organisational culture as well). This evolution is made of 3 stages: Integration, Architecture and finally Operations. I finally noted that successful SOA adoption will rely on 3 groups of people: the Enterprise Architects or designers, the Providers or builders of services, and the Consumers of these services.