Knowledge Conversion Processes

Knowledge conversion processes relate to presenting existing knowledge in a useful format to promote access, structure and distribution. This also involves the mechanisms to identify, integrate and transform tacit knowledge through routines and group interaction (Gold et al., 2001).

The need to perform these knowledge conversion activities in the gathering and piecing of information from a variety of sources provides an example of epistemological bricolage and is illustrated by respondent #2:

‘there are a lot of really good manuals that you can read, and learn fundamentals about it, plus, then play around with the system, you can then ask the people around you… lots of the documents were on the intranet and also our department …have some central servers and repository where we can get those documents.’

‘…looking at documentation, then later we obtained a demo site from Microsoft to play with… some free courses…play around… surfing the web…ask people… ask external party, Microsoft email… student interns…’

The need to draw knowledge from different sources and the need to resort to internal and informal contacts matches with the research of Lundmark and Klofsten (2014) who identified that, from an individual basis, knowledge sources within the organisation were more important than external knowledge sources. Further to this, Lundmark and Klofsten (2014, p. 78) also determined that ‘time to reflect and think, time to experiment/trial and error, and intranet/internal documentation are regarded as the most important knowledge sources’ for project individuals. This research corroborated this statement.

Another tactic explained by respondent #7 was that

‘We just have to mix some more “tricks”...Typically what do we do, we are a participant in the change. We will build a temporary solution to accommodate the change. Even manual solution to route the data into our system, so that we will buy our time, buy time to do the longer term fix.’

Practitioner #17 spoke about extensive interviews in order to ‘piece together’ information and experiences in order to determine the best solution:

‘I was given some names and basically interviewed lots of people, I basically gathered a lot of information that had already been drawn up, by different individuals within the bank…some individuals in London, for example, who had done very extensive papers, white papers, on the subject, and some in the States and the UK. Then pulling something together that was relevant for Hong Kong.’

The ‘piecing’ of information and utilising their resources drawn from experiences prior to joining the bank was described by respondent #5:

‘I came from the business analyst background, I’ve seen many migrations happening…so I had that experience that helped me grasp things quickly and I could understand the problems, because I’ve already seen some different angles especially from business analyst angle as well as from the project management experiences.’

‘If you have domain knowledge, then you will know exactly the issues that are at hand, and what needs to be done. And whether the proposals, or the changes that we want to do. Whether they will be feasible or not, ok. Then you need to have the knowledge of the system that is being used.’

Respondent #7 described how

‘The business sometimes come in to present a much higher view. So the goal is that it try to help everybody in the bank have a better picture what we are up to… it’s very good, because it’s very high level, it doesn’t take too much time.’

But the use of network bricolage helps to gain more detailed knowledge:

‘You can grasp the sense of what this is about. But when it comes to detailed knowledge, honestly, we don’t really have time to read all the requirements…If you want to know more, you can always talk to people.’

This supports the claim from Thomas and Mengel (2008) that there should be less emphasis on the traditional tools and control techniques and more emphasis on ‘[m]aking sense, generating meaning, and learning’ (p. 308).

Respondent #9 raised the topic of collaboration:

‘In this bank, it seems, quite collaborative. You need to have people to help you, support you, and collaborate. Each issue you need multiple people to be involved. So I think it’s kind of culture… you need to have the level of networking, you need to have people influencing skills…I think it more facilitative skill or collaboration skill people are looking for…’

The need to collaborate with other stakeholders was also mentioned by respondent #19:

‘We have sort of good collaboration with the business as well…walkthroughs with the business… there’s walkthroughs with the testers as well…with engineers as well, to ensure that it’s up to their UI (user interface) style standards as well’.

Collaboration also facilitated learning; this involved participating with other team members as well as vendor relations. Respondent #5 concurred with the importance of collaboration:

‘We had to…because of the complexity, the involvement of many systems and so we had to get in touch with many teams. I think you are right, we had to double up consciously and unconsciously, so information is built up.’

Respondent #10 talked about how ‘I learnt this through discussions with my peers...So I started talking to people, looking at industry standards, looking at what best suited us…’

Working with external vendors was also a valuable learning resource as illustrated by several respondents. ‘With ongoing conversation with the vendor, I was learning as we were going along…I had to look after myself, or sometimes the vendor helped’ (#3).

Respondent #20 discussed making do with the knowledge dependency on external vendors despite limitations:

‘…because they are the specialist on this…we need to communicate, work closely with our external vendor…But for this innovative project, I think the vendor; they are eager to work, make a contract with our bank, so that means they are quite helpful and deliver the knowledge…But honestly, are their system provided perfect? Actually no, but I think it’s a continuous improvement.’