Conceptual Modeling for Knowledge Management among The BrainCap Group’s Consultants : A business case study at The BrainCap Group

(1)

Conceptual Modeling for Knowledge Management

among The BrainCap Group’s Consultants

A business case study at The BrainCap Group

Faculty of Science Science Park 904 1098 XH Amsterdam Bachelor Thesis Maurice Stam 10285423

Supervisor: Prof. Dr. H. Afsarmanesh 27/06/2014

(2)

Abstract

Consultancy firms often deal with decentralized knowledge, since consultants work at projects for different clients. Knowledge Management Systems can help to organize knowledge centrally and provide accessibility for all consultants. This research introduces a Knowledge Management System for consultants of The BrainCap Group, designed for reviewing project documents in order to assess the successes and failures of a project and extract lessons learned and best practices. The system is based on the After Action Review process and relies on the Plan Do Check Act methodology. The core features of the system that support the process of continuous improvement are peer reviewing and an incentive support system. The incentive support system is also used for the users to stay motivated to contribute more and deliver better quality. The system database model is developed through requirements analysis by conducting interviews and the model is validated by extensive SQL query examples. User Interface designs are presented to support the database model and are validated with the System Usability Score test.

(3)

1.

2. Introduction

The BrainCap Group is an IT service provider, which provides consultancy services for companies in the Information Technology. The areas on which The BrainCap Group focuses are Governance, Risk and Compliance, Managed Services, Business Intelligence, Software Development, and Application Management and Testing. The BrainCap Group is an overarching company consisting of BrainCap, BrainSquare and BrainCare (see figure 1). They also acquired the IT company Evologics last year and TaskIT (now part of BrainCare) this year. The BrainCap Group has 150 employees and has a variety of clients from various industries.

Figure 1: company structure The BrainCap Group

2.1 Problem Definition

The consultants gain knowledge through doing their tasks at different client sites. In principle, this knowledge, if available, is often very helpful in dealing with the problems faced by other clients, since clients in the same sector (e.g. financial companies) usually have a large number of problems in common. However, due to the lack of a Knowledge Management System, the gained knowledge by employees cannot be shared with/transferred to other employees. This in turn results in loss of time and money as the company has to deal with the same problem over and over again, without reusing the knowledge generated in the company previously. Moreover, when an employee leaves the organization, valuable knowledge for the organization is lost. To overcome these shortcomings, this research aims at designing a Knowledge Management System for The BrainCap Group’s consultants. The designed system enables consultants to store their gained knowledge, and to query the knowledge gained by others in the past. The main goal of the Knowledge Management System is to effectively transfer individual knowledge to organizational knowledge. This knowledge mostly consists of experiences, which is also known as tacit knowledge. Furthermore, to improve the usability of the system, keyword or enterprise search functionalities are considered in designing the system.

The BrainCap Group can gain competitive advantages when they have a central database with knowledge about various successful projects and best practices. However, it is not yet clear how to define whether a project is successful or not or when certain implementations are innovative and renewing. In order to build a Knowledge Management System, the consultants should ideally voluntarily store their implementation descriptions as part of their daily tasks. Theoretically, consultants might see their implementations as knowledge that belongs to themselves and they can be afraid of competitive disadvantages that might arise when they share their knowledge with other consultants within the company.

(6)

The BrainCap Group’s primary business is focused on consultancy services that are delivered on a project basis. Since the different consultants working for The BrainCap Group have different sets of skills and need to work together, the transfer of knowledge between project members is of high importance for the success of the organization. “Knowledge is the most important asset of consultancy organizations, since it is the core of their business” (Hansen et al., 1999, p. 1). Knowledge is a key asset in an organization and should therefore be managed accordingly.

2.2 Research Question

In this research, this thesis proposes a conceptual model for a Knowledge Management System that keeps track of the valuable knowledge assets of the consultants. To summarize, the aim of this research is to answer the following research question:

● How can we design a system that enables knowledge sharing among the consultants?

The research question can further be divided into the following sub-questions:

● How can we identify the requirements for building a Knowledge Management System for consultants?

● How can consultants be motivated to use the Knowledge Management System? ● How can we integrate a solid Knowledge Management System into the already

operating workflows?

● How can we effectively share tacit knowledge within the organization?

2.3 Approach

This research is focused on the design of a model for a Knowledge Management System (KMS) for IT consultants. To get an overview of the research area, we first perform a literature review for defining various knowledge concepts and theories. A theoretical framework is set out to give a clear overview of the concepts on different levels. The following levels are discussed: the knowledge level, the adoption level, the organizational level and the project level. The separated approach of discussing the different levels does not mean that there are no common elements between them. Conversely, the levels are interconnected and share a number of common concepts. After a thorough literary background search of the research area to gather criteria for the system, qualitative research is used to confirm or deny the found criteria in literature research, identify needs and attitudes of the consultants towards a Knowledge Management System, and to identify the Capability Maturity Model Integration level. The literature study and qualitative research are used to extract the requirements for the KMS and determine the different users of the system. We then design the database model, and implement it by MySQL Workbench. Furthermore, we export the implemented data model as a SQL Create script in order to generate the database. We evaluate the database model by example queries of possible complex information needs of the organization. Finally, we design user interfaces to support the database model and evaluate them using the System Usability Scale. The average score of the System Usability Scale is 75 out of 100.

(7)

3. Literature Review

In order to manage knowledge, it is important to have a solid understanding of the definition of “knowledge,” the associated concepts, and the various types of knowledge that are addressed in the literature. The Literature Review Section discusses the background for this research on four levels: the Knowledge Level, the Adoption Level, the Organizational Level and the Project Level.

3.1 Knowledge Level

This section discusses the related literature associated to knowledge definitions and concepts. The knowledge definitions and concepts are the basis of understanding the knowledge

management research area and thus for developing a Knowledge Management System for an organization.

3.1.1 Knowledge definition

“Knowledge is the whole body of data and information that people bring to bear to practical use in action, in order to carry out tasks and create new information” (Schreiber et al, 2000, p. 4). Schreiber et al. also emphasize that knowledge has a sense of purpose and a generative capability – the capability to generate new knowledge from the already existing knowledge.

3.1.2 Knowledge types

There are two types of knowledge, explicit knowledge, and tacit knowledge. Explicit knowledge is formal and systematic. This type of knowledge can therefore be easily communicated and shared with others. Tacit knowledge is highly personal and hard to formalize, and thus becomes difficult to communicate (Nonaka, 1991). Tacit knowledge consists of experiences and is formed through learning by doing. There are practical implications when it comes to capturing and storing tacit knowledge. Since tacit knowledge is personal knowledge, it is hard to transfer and convert into organizational knowledge.

(8)

3.1.3 Knowledge creation process

Nonaka and Takeuchi developed the SECI framework (Nonaka and Takeuchi, 1995) in which the knowledge creation process is described in a spiral model. The amount of knowledge that is created increases after each iteration of the spiral. The knowledge creation process consists of four sub-processes: socialization, externalization, combination, and internalization (see figure 2). Socialization means that tacit knowledge is shared through face-to-face communication or shared experiences, from tacit to tacit. The externalization process converts the tacit knowledge into explicit knowledge by using concepts and models, from tacit to explicit. Through combination, pieces of explicit knowledge are combined into new explicit knowledge, explicit to explicit. The last step in the knowledge creation process is internalization, this is where the explicit knowledge is internalized and converted into tacit knowledge again, from explicit to tacit.

Figure 2: SECI framework (Nonaka and Takeuchi, 1995) 3.1.4 Data, information, knowledge, wisdom

A classification can be made from the content of the human mind that consists of Data, Information, Knowledge and Wisdom (Ackoff, 1989), also known as the DIKW hierarchy (Rowley, 2007). Data is uninterpreted, raw and does not have a meaning of itself. Data can become information when it is equipped with meaning (Schreiber et al., 2000). Knowledge differs from information in the sense that the information is formed in such a way that its intent is useful. Through understanding principles knowledge can become wisdom (Bellinger et al., 2004). Wisdom is also the process by which we judge between right and wrong, good and bad. In contrast to data, information and knowledge, wisdom is focused on the future because it incorporates vision and design (Ackoff, 1989). Wisdom however, is out of the scope of this research, since wisdom is managed at the highest levels in the organization and is not applicable to the average consultant.

Most organizations see their knowledge as the most important strategic resource and the capability to create, integrate and apply knowledge is critical to the development of sustainable competitive advantages (Nonaka, 1991; Kogut and Zander, 1992).

(9)

Organizational wisdom is the judgment, selection and use of specific knowledge for a specific context. Wisdom creates the ability to effectively choose and apply the appropriate knowledge in a given situation (Bierly et al., 2000). The benefits that organizations can get from wisdom are judgment and decision making capabilities. Wisdom provides an understanding of the complexities in a certain situation and gives the opportunity to take action based on the gathered knowledge. In order to make these important decisions it is necessary that organizations maximize their knowledge base. This again will lead to sustainable competitive advantages and organizational success (Senge, 1990; Bierly et al., 2000).

3.1.5 Knowledge management

Knowledge management is the capturing of knowledge from inside and outside the organization. The knowledge is transferred or shared through the organization in order to bring innovation (Taskin et al., 2013). Knowledge management has been described by Taskin et al. as follows:

“An organizational capability that allow people in organizations to work as individuals, or in teams to create, capture, share and leverage their collective knowledge to improve the performance of the organization” (p. 1287-1288).

The problem, however, in most organizations that use projects as their primary way of doing business is that knowledge from past projects is accumulated in individuals’ minds i.e. knowledge representations and competences (tacit knowledge) and in artifacts, i.e. documents and repositories. When consultants leave projects, their individual, often tacit experiences and memories are also lost (see figure 3).

Figure 3: individual knowledge during projects (Love et al., 2005)

Individual knowledge can become organizational knowledge when knowledge gained in projects is being transferred to the organization’s memory (Owen, Burnstein and Mitchell, 2004). This again enables the reuse of knowledge in other projects. The SECI model developed by Nonaka and Takeuchi can be a guideline to support this process. The goal for most organizations is that the individual knowledge is transferred to organizational knowledge. Organizational knowledge is the information held in the collective consciousness of the organization, such as organizational practices, documented research, practices, lessons learned, best practices, and other documents (Smith, 2010).

(10)

Another problem for many organizations is the loss of critical knowledge when people leave the organization. The knowledge that is gathered through years of working experience often disappears completeley, because the organization is unable to capture the tacit knowledge and fails to document important procedures (Beazley et al., 2002). Therefore the first step in transferring individual knowledge into organizational knowledge is to document the procedures and processes, because documentation makes knowledge transferable. Aditionally, the continuity and productivity will drop when key people leave the organization with operational and strategic knowledge. The negative impacts that knowledge loss has on organizations are: reduced efficiency, decreased productivity, increased employee frustration, stress and lower revenues. The negative effects damage the profitability, curtail the innovation, impair the responsiveness of the organization and reduce the surviving chance against quicker and more knowledge-savvy competitors (Beazley et al., 2002).

Reusing knowledge efficiently in a consultancy firm is essential because most consultancy firms are dealing with similar problems over and over again. The results of consultancy firms that are effectively reusing knowledge often is that the product is much faster delivered and at a better price because it saves work, reduces communication costs and allows the firm to attract more projects (Hansen et al. 1999). Reusing knowledge of other consultants can only be achieved if knowledge is documented and stored in the first place.

3.1.6 Strategies for storing knowledge

In the field of Knowledge Management, there are two strategies for storing the knowledge: the codification strategy and the personalization strategy (Love et al., 2005). Codification is a technology-oriented process of storing knowledge in databases, whereas personalization is the human-oriented process where knowledge is held close to the individual employee and is shared through direct interactions between persons. The most effective way of using these strategies is to focus on one strategy and use the other in a supporting role, because when trying to excel in both strategies, there is a big risk of failing at both (Hansen et al., 1999).

3.2 Adoption Level

This section has been added to create an understanding on the factors that influence and impact the adoption or the actual usage of a system. We first present the successes of a Knowledge Management System. We then discuss the different user attitudes towards a KMS.

3.2.1 Key successes of a Knowledge Management System

Implementing a knowledge management initiative in an organization requires a good understanding of the way an organization handles knowledge. One can define several factors that influence the success of a knowledge management initiative (Maier, 2007). As Maier describes, an organization needs to have a holistic, integrated and standardized approach, and there should be standardization in knowledge processes and ICT platforms throughout the

(11)

organization. This standardization should also be integrated within the existing business processes. A knowledge-oriented culture is by far the most important factor of success both for effective transfer of knowledge between “temporary organizations,” such as project management teams, and for Knowledge Management initiatives in general (Maier, 2007; Lindner et al., 2011). These cultural elements of the organization need to be supported by communication of success stories and best practices, through the acceptance of errors and through stressing that every employee is responsible for his or her own learning processes. Management support is important for setting strategic knowledge goals, as it is vital in allocating budgets to the initiative and regulating the change of organizational behavior that is needed to improve the handling of knowledge. A knowledge management initiative also needs clear economic benefits before it will be fully adopted by management, and therefore planning and assessment is important on an intellectual level to show that the initiative is worth the investment. Before a knowledge management initiative will work in an organization, all actors that need to interact with it need a clear understanding of the terminology, and they require exact vision and language. There also needs to be an improvement of the existing organizational knowledge base that will give effective aids for motivation. ICT and organizational infrastructure are important success factors for a knowledge management initiative, since they are primary drivers that enable the initiative. Ideally a separate organizational unit or position should support and coordinate the initiative. The knowledge should also be searchable and users should be able to navigate the system to consume and internalize the knowledge. Therefore flexible and stable knowledge structures are needed. Multiple channels should support knowledge sharing and distribution so as to improve the effective and efficient use of the existing channels, and as such there should be redundant channels for knowledge transfer. Continuous participation of employees in allowing employees to generate knowledge management ideas and develop initial solutions will help a knowledge management initiative gain a more accepting reception by other employees.

3.2.2 User attitudes

The formal use of a Knowledge Management System has been characterized by certain levels of user attitudes (Smith, 2010). The following levels are characterized by Smith: voluntary, gossip/infighting, sabotage, foot-dragging, forced, brown-nosing, making-out and withdrawal. These levels are spread out on the spectrum between full compliance and noncompliance when it comes to project management documentation and usage of the Knowledge Management System. The most positive situation would obviously be the voluntary user attitude towards the Knowledge Management System.

The best outcome would be that a greater portion of the contributors would use a system because of an intrinsic motivation. Intrinsic motivation is the self-fulfillment and inherent satisfaction that people get from a certain activity (Lin, 2007; Ryan and Deci, 2000). The intentions of employees to share knowledge are strongly related to the intrinsic motivations for them to share this knowledge. This intrinsic behavior could become a result of the ongoing concern within the company towards collective knowledge management.

(12)

Figure 4: user attitudes within formal KMS use (Smith, 2010)

3.3 Organizational Level

This section reviews the literature on the organizational level. Concepts such as the learning organization, continuous improvement, Plan Do Check Act (PDCA) and capability maturity (CMMI) are discussed.

3.3.1 Learning organization

In order to become a learning organization, organizations should incorporate learning processes in their business. These learning processes should consist of the linking, expanding and improvement of data, information, knowledge and wisdom (Bierly et al., 2000). A learning organization is also described as follows:

“skills at creating, acquiring and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights.” (Garvin, 2000, p. 11).

This learning process also exemplifies the generative capability of knowledge itself, since new knowledge is produced from the already acquired knowledge. So knowledge is not only the source of learning, but also the product. Organizational learning consists of the learning processes of the individual members and is the organization’s memory (Kim, 1998).

3.3.2 Continuous improvement

Plan Do Check Act (PDCA) is a management tool consisting of four iterative steps for the continuous improvement of processes and products (Deming, 1950). The PDCA cycle consists of the four following steps:

(13)

Plan

This is where the planning of objectives and processes takes place that should be delivered to achieve the desired aims of a project conforming the project strategy. Do

The established plan is being implemented and the project team members with the required skill sets execute the processes.

Check

Compare the actual results with the intended results, which are established during the planning process. Also comparisons of project metrics could be made. These project metrics could be formed by balancing between the client needs and the business needs

(Srivannaboon, 2009). Evaluation of the discovered differences is needed in order to

make justified decisions. Root cause analysis can be used to guide this process. Act

Significant differences between actual results and intended results that are identified at the check process are studied and actions are taken upon them.

The Do and the Check process can be iterated as many times as needed before the outcome is carried out in the act process. Improvement only takes place when an iteration leads to a new start of the PDCA cycle where the findings of certain deviations are applied. This process will eventually lead to better quality of products and services and will stimulate the learning process of team members.

A practical approach would be to implement a Lessons Learned activity into each delivery process.

3.3.3 Organizational project management

“Organizational project management is the application of knowledge, skills, tools and techniques to organizational and project activities to achieve the aims of an organization through projects” (PMI, 2005, p. 5).

The above dictates that the organization has a need for the application of knowledge. That by itself suggests that there is a need for management activities that support this. The OPM3 model described below could be applied to achieve the desired knowledge management results. The Organizational Project Management Maturity Model (OPM3) is a standard for best-practices developed by the Project Management Institute (PMI) to assess and develop project management capabilities by using self-assessment and continuous improvement on the organizational level (PMI, 2005; Smith, 2010). Because the OPM3 cycle is based on the continuous improvement of processes, it is necessary that the organization learns from previous lessons and best practices (Smith, 2010). OPM3 consists of three important interconnected elements: knowledge, assessment and improvement (see figure 7). OPM3 gives an organization the ability to identify where they stand when it comes to organizational project management in relation to the best practices in order to improve their processes.

(14)

3.3.4 CMMI

Capability Maturity Model Integration (CMMI) is focused on software engineering and systems engineering and the associated integration that is needed for building and maintaining a product (Chrissis et al., 2003). CMMI offers best practices about the activities related to development and maintenance and covers the product lifecycle from concept to delivery and maintenance (C.P. Team, 2006).

Figure 5: Capability Maturity Model, levels of maturity

This design is referenced to gauge or model both the methodology and the effort a company is faced with to achieve a desired goal (see figure 5). By internal evaluation the company can estimate the current position, and set a goal for the next desired position.

3.4 Project Level

This section discusses various concepts at the project level, such as the Project Management Body of Knowledge, PRINCE2 and the After Action Review process.

The Project Management Body of Knowledge defines a project as: “A temporary endeavor undertaken to create a unique product, service or result”. The temporary nature of projects indicates that there is a definite beginning and ending of a project (PMI, 2008, p. 5).

The Project Management Body Of Knowledge (PMBOK) provides a set of standard terminology and guidelines for project management. The practices that are described in PMBOK are generally accepted as good practice.

Projects are the foundation of organizational strategy (Cleland, 1999). The project strategy is important to take into account during the management of a project, because it provides guidelines for achieving competitive advantage and results into the best value for a project (Shenhar, 2004). Alignment between project management and business strategy results into organizational success of strategies and performance (Srivannaboon, 2009).

(15)

The project management methodology PRINCE2 is being used by Evologics to keep track of projects. PRINCE2 stands for PRojects IN Controlled Environments version 2 and offers a process-based methodology for the management and control of projects (Hedeman, 2004). PRINCE2 offers standardization of the process, and thus allows for easy transfer of knowledge.

3.4.1 Finding out what and where to improve?

Lessons learned for a consultancy firm are the product of experiences gathered through doing projects. The forming of lessons learned often is a process of collectively sharing, discussing, reflecting, verifying, and integrating experiences by project team members (Maier, 2007). The lessons learned at the end of a project are also called after action reviews (AAR). It evaluates the performed actions during a project and clearly lists improvement points for future actions. AAR is developed and practiced by the U.S. army to reflect on actions and to improve them (TO, 1993; Garvin, 2000). The after action review results in lessons learned and are used to explicitly connect past experiences with future actions. Aside from the U.S. army, other large organizations are also adopting AAR as a business tool to identify best practices and mistakes (Darling et al., 2005). Figure 5 outlines the AAR process that eventually leads to best practices and global standards as described by Darling et al.. The AAR process involves four key questions including: What were the intended results? What were our actual results? What caused the results? What needs to be improved or sustained? This model resembles the PDCA approach in a practical fashion.

Figure 6: AAR to best practices process

By finding the differences between intended results (before starting a project) and actual results (after finishing a project) during the AAR process, successes and mistakes (deficiencies) of a project can be implied. The successes and mistakes preferably need to be categorized by the causes that were responsible for the outcomes, in order to take actions to improve. Root Cause Analysis can be done to further identify what caused these differences.

Root Cause Analysis (RCA) is a part of the AAR process, where successes and mistakes are analyzed for their causes (Darling et al., 2005). “Root Cause Analysis is the process to find out all causes of deviations during the project life cycle” (Dalal and Chhillar, 2013, p. 1). Calleam Consulting has compiled a list of the 101 causes that lead to the failure of IT project and can be used to categorize the found deficiencies for a project (Goatham, 2009).

(16)

3.5 Overview theoretical framework

The theoretical framework of this research is outlined on four levels (see figure 7): the Project Level, the Organizational Level, the Knowledge Level and the Adoption Level. The framework is used to identify the important criteria for developing a Knowledge Management System. The qualitative research presented in Section 4 is used to confirm or deny the found criteria.

Figure 7: theoretical framework of the KMS research area

A Knowledge Management System is powered by knowledge, which today is one of the most valuable assets of an organization (Hansen et al.,1999). An important requirement for a KMS is that explicit knowledge can be stored. The knowledge that consultants gather during projects often is tacit. In order for consultants to store knowledge into the system, the knowledge needs to be transferred to explicit knowledge i.e. individual knowledge to organizational knowledge (Love et al., 2005). The externalization process of the SECI framework (Nonaka and Takeuchi, 1995) along with the codification strategy (Hansen et al., 1999; Love et al., 2005) supports this.

(17)

When knowledge is stored in the database of the organization, the individual knowledge becomes part of the collective consciousness of the organization (Smith 2010).

The internalization process of the SECI framework is also important for the system, because the users have to internalize the knowledge that has already been stored in the system.

Internalization can contribute to the intrinsic motivations of the user, since using the knowledge in practice can cause self-fulfillment of the user (Lin, 2007).

To make the SECI framework more practical for the consultancy firm, the four processes are presented with an example. Socialization in a consultancy firm occurs when consultants interact with clients or fellow consultants. Externalization mainly takes place when projects are

documented and stored in a system i.e. when explicit knowledge is stored. Combination is the process where the explicit knowledge is retrieved and interpreted by the consultant. Finally, internalization takes place when explicit knowledge is used to solve problems. By using the knowledge in practice, the knowledge is internalized and thus converted into tacit knowledge again.

The goal of the organization eventually is to become a learning organization, because it enables them to adapt quicker and thereby achieving more strategic advantages (Marquardt, 1996). This can be realized by introducing Plan Do Check Act methodologies (Deming, 1950) and After Action Review processes (Darling et al., 2005) into the organization.

OPM3 is based on three drivers, namely knowledge, assessment, and improvement and connects organizational strategy with successful projects (PMI, 2005). To integrate

organizational strategy with project management, the support of management is needed. To accomplish this, preferably a quality manager should be introduced that will guard the relationship between business objectives and knowledge management goals. The Quality Program Manager is introduced in Section 5.3 to adopt this role and he will be responsible for the oversight of all projects and aligning the KMS objectives with business objectives. Also, he will be responsible for extracting the best practices from the available information.

The knowledge base i.e. stable knowledge structure (Maier, 2007), of an organization can facilitate decision-making for management. The knowledge that facilitates this decision-making, also called organizational wisdom, can provide sustainable competitive advantage for the organization. The decision-making based on the stored knowledge connects the strategic goals of the Knowledge Management System with the business objectives of the organization.

(18)

4. Interviews

Interviews were conducted with consultants of all teams that deliver software services on a project basis (Evolution, Preactor, EXB and Exact). At the end when all the questions were addressed, the interviewees were asked to give an indication of their user attitude towards a Knowledge Management System (see figure 4) and were asked to fill in the CMMI self assessment questionnaire (SmartMatix, 2014) to identify the level of project management Capability Maturity. Moreover the management responsible for the consultancy teams were asked to fill in the CMMI self assessment as benchmark for the organization and to compare with individual consultant assessments. The Smart Matix CMMI quick self-assessment questionnaire was retrieved from the Smart Matix website (SmartMatix, 2014). For the interview questions, see Appendix A.

4.1 Interview Analysis

All interviewees need knowledge in their daily jobs. The consultants of Evolution, Preactor and EXB acknowledged that there is need for a Knowledge Management System. Consultants of Exact, however, confirmed that their project management system is sufficient for knowledge gathering and knowledge discovery. The system AtTask software is being used at Evologics for overall project management purposes, but real project specific knowledge has not been recorded centrally. The Exact consultant also indicated that the software provider has sufficient product specific and technical knowledge, which is centrally available in the Synery software project management system. This knowledge base covers approximately 80 to 90 percent of the needed knowledge. The other 10 to 20 percent of knowledge comes from the organization where it is implemented and from the consultant’s experiences with previous projects. Synery software also provides document storing and searching on content. The system of the Exact consultants is sufficient in their knowledge fulfilling. Therefore, our focus in this research is on the Evologics consultants.

The Evologics consultants gather knowledge during projects, but they usually document it for themselves, and store it locally in Microsoft Word format. Knowledge is only shared when consultants with a problem specifically ask other consultants by mail or phone if they have prior experience with those problems. This process however is not interactive. When a consultant with the need for knowledge thinks that others might have experience with similar problems, he has to specifically ask for it and then the knowledge can be transferred. However, the consultants reported that they need knowledge in their daily jobs. They also reported that the accessibility to instant knowledge is not optimal. Instant access to the needed knowledge can save time and will provide more efficiency.

The greatest shortcoming of the AtTask system is the lack of knowledge-discovery functionalities. Information that is stored in the system can only be searched on filenames and not on their content. Thus, knowledge can hardly be extracted from the stored information.

The Evologics EXB team uses Dropbox, which can be accessed centrally by all team members, to store project related documents. The consultants gather project and client specific knowledge in Dropbox, for example approaches for specific tasks and technical information for server

(19)

settings, IP addresses, DNS data, and database passwords. The information is then categorized in specific folders. The problem however is that searching on content is not provided. Consultants of Evolution only occasionally use additional knowledge-discovery methods. They use a system called Copernic to search on the contents of large sets of documents and emails. The Preactor consultants do not use any additional systems for knowledge gathering and discovery. They consist of a small team of consultants who regularly have meetings to transfer knowledge about projects.

Knowledge gathered in projects mostly is about specific work tasks and describes processes and best practices. At the Evologics Evolution team this knowledge usually is about the application of functionalities and matching modules to requirements of the clients. Most often this is documented in a manual or a Microsoft Word document. At the Evologics EXB team the gathered knowledge during projects is about the project details, planning, client information and task specific procedures.

The consultants indicated that their need in a Knowledge Management System consists of standards for working procedures, best practices for the execution of project related tasks, system settings and general system information that is necessary to perform their daily jobs. They also reported that the knowledge they gather in projects is also used in other projects.

Tacit knowledge should be converted into explicit knowledge by documenting the processes clearly and by identifying the lessons learned. There is always a learning curve present, so doing practical tasks by following manuals is important for the learning process and will eventually be the most valuable.

According to the questioned Evologics consultants, important elements for a Knowledge Management System are searchability, user-friendliness, ease in sharing knowledge, completeness of information, and accessibility. When the Knowledge Management System meets these requirements, the consultants are willing to voluntarily spend time to use and fill the system, with or without encouragement and support of management. The consultants all placed themselves into the ‘voluntary circle’ of the user attitude towards KMS diagram (see figure 4).

According to the Evologics Evolution team there is a strong support for knowledge transferring between colleagues. The project leader is involved and supports the sharing of knowledge. In the Evologics EXB team however, knowledge sharing is less motivated, but small initiatives have been recently deployed, such as Dropbox for storing documents, OneNote to document technical information and Keypass to store passwords. The knowledge support of the Evologics Preactor team consists of meetings on regularly basis.

Cultural elements that are considered as important for knowledge sharing are: generosity, socially competent, team spirit and not being selfish.

(20)

The information stored in the Knowledge Management System should be provided by external sources automatically so that time can be saved with inputting data manually. Also the manual uploading of documents is considered important since the consultants can determine the format themselves.

Current workflow allows for the integration of a knowledge-sharing initiative. If the system is better and not too time consuming, other redundant systems can be replaced. At this time, the documentation of knowledge is initiated by the consultant as an individual. While management does stimulate it knowledge-documentation, they do not preserve sufficient time for it and schedule it in projects as an essential priority.

The CMMI level is identified as level 1 by all the Evologics Evolution, Preactor and EXB consultants. Also the management identified CMMI as level 1, which confirms the validity of the assessment. A full implementation of PRINCE2, however, should place Evologics at Level 2 of CMMI. This means that many improvements can be made in the field of project and knowledge management.

An important conclusion of the conducted interviews is that the knowledge discovery needs of the consultants are quite unstructured (see figure 8). They want to search on content throughout all stored documents to find the knowledge they require. Currently, systems at Evologics do not provide the ability to search on content. Enterprise search technologies, such as Apache Solr (Apache, 2014), provide extensive search capabilities for searching through large amounts of different document types. This attitude differs from a structured knowledge need, like the relational database model, where the need for knowledge should be predefined well before querying on the database to find relevant documents.

Moreover, there are no best practices documents at the various teams, only manuals and normal work processes. Best practices are generated when current workflows are reviewed. Then, lessons learned are extracted and are used in new workflows (see figure 6).

(21)

5. Solution

This section provides the solution for the system. Related research as well as interviews is used to gather the requirements for the system. In this section, first the definitions are described that are important for understanding the background of the system. Finally, the database model along with a use case diagram and use case descriptions are presented in this section. The theoretical foundation of the system is outlined in figure 10. See also figure 6 for the basic structure of the methodology.

5.1 Best Practices Database

A best practice is knowledge in a process-oriented form that describes tasks or workflows that have proven to be valuable or effective within one organization or organizational unit and may have applicability to other organizations (Maier, 2007; O’Dell and Grayson, 1998).

Best practices rely on the capabilities and their associated outcomes, because the goals of best practices are achieved best when their capabilities are constantly measured by their outcomes (PMI, 2005). This means that best practices should be actively used by the organization and measured in order to make improvements to the practices.

The biggest barrier of transferring knowledge and practices is due to ignorance (O’Dell and Grayson, 1998). Often employees are not aware that their knowledge might be valuable for other employees or that other employees might have valuable knowledge for them.

The benchmarking of work procedures and processes results in best practices. The goal of best practices eventually is that knowledge is effectively reused to perform a specific task better and faster. Benchmarking usually is implemented by finding the best practices of an organization in a similar industry and compares the own practices in order to improve quality, reduce costs and save time. In this research the knowledge management initiative should be focused on storing practices of individual consultants and extracting best practices through improvement by lessons learned (see figure 9). The lessons learned in this specific case will be used as a benchmark to improve individual work processes of the consultants. This however, needs a structured approach of formulating the lessons learned as well as the practices during projects to make benchmarking possible. When the benchmarking takes places, the stored practices, which till that moment is still information, will become knowledge since it gets a real purpose of use and it will generate new knowledge.

(22)

In order to design a Knowledge Management System for consultants it is important to define what knowledge exactly is for the organization. Most of the consultants work on projects at the client’s location. There are two main types of knowledge generated at projects, behavioral knowledge and technical knowledge (Reich, 2007). Behavioral knowledge consists of cultural knowledge and institutional knowledge. Technical knowledge consists again of domain knowledge and process knowledge. The behavioral knowledge for consultants is about client specific (organizational) knowledge and the technical knowledge about the implementation specific (software) knowledge. This knowledge is often tacit, mostly consisting of experiences gathered through years of working at projects. The technical knowledge can be documented and codified in the form of work processes.

The best practices system is based on the After Action Review process and relies on the Plan Do Check Act methodology (Darling et al. 2005; Deming, 1950) (see figure 10). The system consists of reviewing intended documents (formed before the start of a project) and actual documents (formed after finishing a project), that will result in a delta review where the successes and mistakes (deficiencies) of a project are documented. The intended and actual documents are based on a predefined set of document types, such as project plans, project initiation documents, action lists, orders, statements of work, acceptance criteria and issue reviews. Also the delta reviews will be categorized by their root causes that are formed through Root Cause Analysis of the successes and mistakes. By reviewing all the delta documents for a project, project leaders can form the lessons learned. These lessons learned can be transformed into best practices for this specific project, but more interesting, for all the project of a complete industry of similar companies. In order for the best practices to be really useful, they should be recommended to consultants when they start new projects or tasks that are similar. A recommendation function is not in the scope of this project, but will however be suggested in the Future Work Section (see Section 7.1).

(23)

Plan Do Check Act is integrated in this model to enable continuous improvement and will be the foundation of the learning organization. Planning takes place in the first phase of the project when the intended document is created. The doing phase is when the consultants are working on a project and perform their planned tasks. This results in the actual document with the outcomes of the project and will be checked in the delta review. When the lessons learned of a project are translated to best practices and are recommended to the user, decisions can be made to act upon it.

The document types are predefined and can be expanded when new document types need to be added. The root cause categories are predefined and separately managed by the background support user. The reason to manage them separately and to use a standardized set of categories is that they can be expanded and can be used as a benchmark to compare with competitors in the same industry.

(24)

5.2 Database Model

Figure 11: Best Practices Database Model

This model (see figure 11) that was designed by using MySQL Workbench describes the core features of the system, namely the reviewing of documents in order to form lessons learned that eventually leads to best practices. The model can be used to build a new system, but also the integration with other systems is possible. The client, project, task, product, and consultant tables could for instance be extracted from the AtTask and Synery software, which are used by The BrainCap Group. The user management (user login) and permission management (access levels of the users) are intentionally left out of this model, because these are not the core features of the system and this information could also come from AtTask software or Synergy software, when integrating with these systems. An overview of all the tables and attributes of the system is presented in Appendix B. The SQL Create script of the database model is presented in Appendix C.

(25)

Since ‘intended’ and ‘actual’ documents are modeled in the database design with a connection to a list of document types that can be expanded, it ensures that the system is flexible for defining new document types.

The Success_or_Mistake table defines if projects failed or succeeded and connects the delta reviews with specific root-cause categories. It is important that a standardized set of categories is used to eventually compare and benchmark with other companies in the same industry. A list of success categories for projects is presented in the work of Alexandrova and Ivanova (Alexandrova and Ivanova, 2012) and a list of 101 categories for failures of IT projects are presented in (Goatham, 2009).

Information of clients, projects, tasks, products and consultants that are stored in the AtTask or Synery databases can be retrieved by this system through connecting with the API’s of AtTask software and Synergy. The attributes of these tables are gathered from the AtTask system in the requirement analysis process, although some attributes like the request_for_change and the customer_satisfaction_rate attributes in the project table and the skills, contribution_points attribute in the user table are added in order to provide more interesting project metrics. When implementing the system into the AtTask software or Synergy, these attributes should ideally be added into the database model of these systems. The contribution_points attribute is also used in the incentive system and its function is described below.

5.2.1 Incentive System

An incentive system is proposed to incentivize the user to use the system frequently. The suggested mechanism is intended to induce intrinsic motivations of the user. The system will have a scoreboard as an additional feature to encourage the user to contribute more to the system. Users that are listed as the least contributors could have a reason to contribute more in order to rise in the list, creating a competitive edge to the system. The incentive mechanism is intended to build-in two of the success factors of Maier, the effective aids for motivation and the continuous participation of employees (Maier, 2007).

The Points_per_Document_List table consists of a predefined set of contribution points that belong to specific document types (intended, actual, delta, lessons learned and best practices) and will function as a rule table. As the documents differ in knowledge value, the points for these documents increase when the knowledge value is higher. For example a delta document is worth more points than an intended document. The contribution points can only be compared within a specific user role, because consultants for instance cannot upload best practices documents. Competition therefore will arise within a user type (see Section 5.3 for the different user types and their functionalities).

Another system is added for voting on the content of the documents. By judging the work of others, users get motivated to deliver and maintain quality standards and provide credibility, this process is also known as peer reviewing. Other users can view available documents and they

(26)

can upvote (useful) or downvote (not useful) the content of the document. The contribution points of the user are computed by multiplying the number of documents that are uploaded and the standard points that are dedicated to a specific document type. The contribution points are normalized by the value of the content (upvoting or downvoting) and this manipulates the total number of points.

A history table can be made for the assignment of points to documents because the date of the creation of a document by a user is stored in the system. This provides a way to show a history of how the accumulated points are build up. Furthermore, by storing the input_date of all points in the predefined Points_per_Document_List table, it enables the system to compute new values for the points when changes are made to the list, as is done after a re-evaluation of the points distribution system, without losing the computed scores of previously rated documents. This is done by comparing the creation date of a document and the points of that document with the date of input of the points. This implies that the point system table should also be fitted with a date to enable and thus form a history table on itself.

(27)

5.3 Database User Types

Four different user types are identified as users of the system. The user types with employee function and their associated functionalities for using the system are described below. The consultant and project leader users are already-existing functions within The BrainCap Group. The quality program manager should be a new role in the organization that manages the knowledge and takes care of quality improvements. The application support is also a new role and should be taken by general project support.

1) User: Consultant

● Upload intended document. ● Upload actual document.

● Compare intended with actual document, write review and store as delta document. ● View all documents of a project (intended, actual, delta, lessons learned and best

practices).

● Rate documents of other users.

2) Expert User: Project Leader

● Categorize the delta documents.

● Select all information (documents and project metrics).

● Analyze all delta documents (including all mistakes and successes of a project). ● Report the lessons learned for a project.

● View all documents of a project (intended, actual, delta, lessons learned and best practices).

3) Super Expert User: Quality Program Manager

● Check all lessons learned (e.g. for all projects of a specific industry).

● Report best practices from reviewing the lessons learned (e.g. for a specific industry). ● View all documents of a project (intended, actual, delta, lessons learned and best

practices).

4) Background User: Application Support

● Establish predefined domain for the document types (type list).

● Establish predefined domain for the delta review categories (category list). ● Take care of user permissions and general database maintenance.

(28)

5.4 Use Case Diagram

Figure 12 shows the use case diagram of our system. The background user’s function is to once store and periodically check and update the predefined types and categories. Application support exists not only of maintaining the document types and categories, but also general database maintenance and user and permission management. User and permission management, however, are left out of the use case diagram to focus only at the key features of the system. The other users are performing the steps described in this use case diagram at least once for each project.

(29)

5.5 Use Case Descriptions

This section describes the use case diagram by presenting the use case descriptions of the various use cases. Besides the description, also the actor, precondition, normal flow and alternative flow are described for each use case.

1) Store predefined document types

Description

A list of document types need to be stored in the database in order to let the consultant upload different types of intended and actual documents. This list is predefined in the beginning, but it can be expanded when there is a need for new types of documents. This need could arise by the management of the organization when new requirements are added to the project management. Also, the consultants, project leaders and quality program managers can suggest new document types when they experience that the already existing types are not sufficient.

Actor

The Background User will take care of the initial list of types that will be stored in the database. Also when new document types need to be stored, the background user has the ability to add new types.

Precondition

A first set of document types needs to be provided by the organization.

Normal flow

1. The user logs in to the admin panel of the system. 2. The user navigates to the document types tab.

2. The user clicks on the ‘add new document type’ button. 3. The user enters the name field of the new document type.

Alternative flow

-

2) Store predefined categories for delta documents

Description

A list of categories needs to be stored in the database to let the project leader categorize the delta documents that are stored by consultants. This list will consist of a predefined set of categories that are standardized for a specific field of expertise and specify the categories for causes of certain problems. This can be for instance a list of the causes for problems in IT project management. A standardized list is used for eventually comparing with other companies in the same industry.

Actor

The Background User will take care of the initial list of categories that will be stored in the database. Also when new categories need to be stored, the background user has the ability to add new categories.

(30)

Precondition

A standardized set of categories for IT project management failure causes needs to be provided.

Normal flow

1. The user logs in to the admin panel of the system. 2. The user navigates to the categories tab.

3. The user clicks on the ‘add new category’ button. 4. The user enters the category name field

5. The user enters the category group field.

-

3) Upload intended document

Description

Intended documents are documents that are provided at the start of a project. This could for instance be a project plan, with all the tasks listed that need to be carried out during a project.

Actor

The User will make and upload an ‘intended document’ for each project.

Precondition

The project is defined and accessible by navigating or searching the system.

Normal flow

1. The user logs in to the system.

2. The user navigates to the tab for intended documents. 3. The user clicks on the ‘add new intended document’ button.

4. The user provides document meta-data (subject, description, project, contributor, etc.) 5. The user types text in the editor.

6. The user clicks on the ‘save file’ button.

2. The user navigates to the project dashboard. 5. The user attaches a Word or PDF file.

4) Upload actual document

Description

Actual documents are documents that are provided at the end of a project. This could potentially be a list of actions, with all the tasks that are carried out during a project. These documents are stored in order to compare them with the intended documents.

Actor

The User will make and upload an ‘actual document‘ for each project.

Precondition

The project is defined and accessible by navigating or searching the system. Also an intended document is already uploaded for the project.

(31)

Normal flow

2. The user navigates to the tab for actual documents. 3. The user selects a project.

4. The user clicks on the ‘add new actual document’ button.

5. The user provides document meta-data (subject, description, project, contributor, etc.) 6. The user types text in the editor.

2. The user navigates to the project dashboard. 6. The user attaches a Word or PDF file.

5) Write delta review for intended and actual documents

Description

Delta reviews are the differences between intended and actual documents by analysis of the consultant.

Actor

The User compares the intended document with the actual document, reviews them and stores the successes and mistakes of a project.

Precondition

Intended and actual documents need to be stored in the database by the consultants.

Normal flow

2. The user navigates to the project dashboard.

3. The user selects a project where both intended and actual documents are already uploaded.

4. The user clicks on the ‘add delta review’ button.

5. The user enters text in the editor below the intended and actual documents, to review the successes and mistakes of the project.

6. The user saves the delta review document.

2. The user searches by entering a query in the search box. 5. The user attaches a Word or PDF file.

6) Categorize delta documents

Description

Delta documents need to be categorized in order to tag the document with the cause of the success or failure. When this is done the documents can more easily be reviewed for lessons learned by the quality program manager and they can be searched in the system. The project leader is responsible for doing this, since he or she has a better overview of the project he can find the causes better and faster.

(32)

Actor

The Expert User categorizes the delta documents by selecting a cause from the predefined category list and relates it to a delta document.

Precondition

Delta documents need to be stored in the database by consultants, even as the list of predefined categories.

Normal flow

2. The user navigates to the tab for all delta documents. 3. The user selects a project.

4. The user clicks on the category button of a delta review. 5. The user chooses a category from the list.

6. The user saves the selection.

7) Select all information about projects

Description

A selection is being made from all relevant information that is needed to base conclusions on and eventually write the lessons learned review. The information selection consists of the relevant set of delta documents for a project and the project metrics. Project metrics can be used to infer what caused certain mistakes. Project leaders can view all failed projects by consultant. By further exploring the project metrics, there could for example be found that a project failed because it run 50% over time. Then the project leader can also look at other projects where the same consultant was involved and based on these findings action can be taken for improvement. The delta documents can also be viewed by category of cause.

Actor

The Expert User will select all project metrics and relevant documents.

Precondition

Project metrics and relevant documents need to be stored in the database.

Normal flow

2. The user navigates to the project dashboard for exploring and searching the data

set.

3. The user enters a search query.

4. The user filters the information.

5. The user selects the needed information.

6. The user views the metrics and statistics.

3. The user searches through navigating the categories. 7. The user exports the report.

(33)

8) Write review for lessons learned Description

The lessons learned review is based on the findings and root cause analysis of the mistakes and successes of the delta documents for a specific project. The project leader is responsible for deriving lessons learned of project processes. The project leader will get an overview of the important information through the information selection process and uses this to form his conclusions on in the lessons learned review.

Actor

The Expert User will write a lessons learned report based on a selection of information.

Precondition

Delta documents need to be stored in the database for a project as well as the related project metrics.

Normal flow

3. The user selects the project that needs to be reviewed and where delta documents

are already provided.

4. The user clicks on the ‘add new lessons learned document’ button. 5. The user fills in the text field.

2. The user searches for a project by entering a query in the search box. 5. The user attaches a Word or PDF file.

9) View document

Description

The consultants, project leaders and quality program managers should be able to view intended, actual, delta, lessons learned and best practices documents. These users should have access to these documents in order to write reviews and rate the work of each other.

Actor

The User, Expert User and Super Expert User, need to be able to view different documents that are created and stored in the system for a specific project.

Precondition

Intended, actual, delta, lessons learned and best practices documents that need to be viewed are stored in the system.

Normal flow

2. The user navigates to the documents tab. 3. The user selects a project.

4. The user clicks on the icon of the needed document. 5. The user views the document.

Conceptual Modeling for Knowledge Management among The BrainCap Group’s Consultants : A business case study at The BrainCap Group