Applying a Template for Best Practice Documentation

Abstract

Knowledge Management has become a key instrument for creating, identifying and sharing knowledge assets in organizations. Best Practice (BP) is a useful means for organizations to improve knowledge sharing. However, low quality of BP documentations can hinder a successful implementation of BPs, since practitioners may not be able to correctly and efficiently use them, or even trust them. In this paper, a BP Document Template (BPDT) for high quality documentation is presented. The final BPDT is a result of the combination of two templates, the first one created based on interviews with knowledge management experts and the second one based on a literature review using grounded theory. The final BPDT has been applied in three real-life organizations for demonstrating its benefits, drawbacks, completeness, ease of use, and whether it also supports both the design of BPs and the evaluation of already designed BPs. The demonstration showed promising results but also some drawbacks. The identified drawbacks can be used as input for future research.

Full text

Procedia Computer Science 72 ( 2015 ) 252 – 260
1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of organizing committee of Information Systems International Conference (ISICO2015)
doi: 10.1016/j.procs.2015.12.138
ScienceDirect
Available online at www.sciencedirect.com
The Third Information Systems International Conference
Applying a Template for Best Practice Do
c
um
e
n
tati
on
Meshari Alwazaea, Erik Perjonsa, Paul Johannessona
aDepartment of Computer and System Sciences, Stockholm University, Stockholm 16407,
Sweden
Abstract
Knowledge Management has become a key instrument for creating, identifying and sharing knowledge assets
in organizations. Best Practice (BP) is a useful means for organizations to improve knowledge sharing.
However, low quality of
BP
documentations can hinder a successful implementation of BPs, since
practitioners may not be able to correctly and efficiently use them, or even trust them. In this paper, a BP
Document Template (BPDT) for high quality documentation is presented. The final BPDT is a result of the
combination of two templates, the first one created based on interviews with knowledge management experts
and the second one based on a literature review using grounded theory. The final BPDT has been applied in
three real-life organizations for demonstrating its benefits, drawbacks, completeness, ease of use, and whether
it also supports both the design of BPs and the evaluation of already designed BPs. The demonstration showed
promising results but also some drawbacks. The identified drawbacks can be used as input for future research.
© 2015 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of the scientific
committee of The Third Information Systems International Conference (ISICO 2015)
Keywords: Knowledge sharing; Best practice; Best practice documentation; BP document template
1. Introduction
Knowledge sharing between employees and within and across teams is fundamental for successful
Knowledge Management (KM) and innovation [1]. According to Wang and Noe, research has “shown that
knowledge sharing and combination is positively related to reductions in production costs, faster
completion of new product development projects, team performance, firm innovation capabilities, and
firm performance including sales growth and revenue from new products and services” [2]. Jashapara also
emphasize the importance of knowledge sharing in his definition of KM: KM is “the effective learning
process associated with exploration, exploitation and sharing of human knowledge (tacit and explicit) that
use appropriate technology and cultural environments to enhance an organization’s intellectual capital and
performance” [3].
Knowledge sharing is the activity where knowledge is made available to others within an
organization in order to make the organization more effective and efficient [2]. Knowledge sharing
© 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of organizing committee of Information Systems International Conference (ISICO2015)

253
Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
may happen via face-to-face interactions, through apprenticeship, via written correspondence or
documents, by carrying out organizational routines and processes or by applying technologies in which
knowledge is embedded [4]. One of the most widely used means to share knowledge is via Best
Practice (BP). A BP can be defined as “the most efficient (least amount of effort) and effective (best
results) way of accomplishing a task, based on repeatable procedures that have proven themselves over
time for large numbers of people”, cited from Wikipedia in Graupner et al. [5]. For the past two
decades, the use of BP to share knowledge has been a popular means to move organizations towards
higher performance [6, 7, 8, 9, 10, 11].
There are a number of challenges for the successful application of BPs addressed in BP literature.
For example, difficulties in creating and identifying BPs [12, 13], difficulties in finding and selecting
appropriate BPs [14, 15], and difficulties in maintaining the content of the BPs properly [16, 17]. In
this paper, the focus is on another challenge, the low quality of best practice documents (BPDs).
The practical problem addressed in this paper is that low quality of BPD impedes the use of BPs.
Some underlying causes for the low quality of BPD are incomplete, non-clear, redundant, incorrect,
inconsistent, or irrelevant content. This paper focuses on one aspect of low quality, that is,
incompleteness. Low quality BPD in the form of incomplete descriptions hinders the success of BP
application [12, 15, 18, 19]. Examples of such incomplete documentation are lack of descriptions of the
purpose of the BPs and how to measure the value of knowledge within them [20, 21, 22], lack of
descriptions of how BPs actually work in organizations [23] and lack of description of how to
implement BPs [12]. However, how a BP should be documented has not been examined extensively in
the literature, see Dani et al. [12].
The goal of this paper is to design and demonstrate a Best Practice Document Template (BPDT) for
supporting the creation, use and evaluation of BPDs. The BPDT is a structure for describing BPs in a
detailed and systematic way. The structure is a set of pre-specified attributes or fields that create
guidance when creating the BPD. The template can help knowledge engineers to develop high quality
BPDs before disseminating them. The template can also be used to assess existing BPDs in order to
enhance them. Furthermore, the template is applicable to any BP documents within all types of
organizations, therefore, practitioners can apply the template properly in all types of organizations (within
different business domains, IT- as well as non-IT-related organizations).
The paper is structured as follows. Section 2 presents the research methodology followed, in section
3, by a description of how the BPDT was designed and developed. The demonstration of the BPDT is
presented in section 4, followed by conclusions in section 5.
2. Research Methodology
The overall research approach used in this research is design science. According to Hevner et al. [24],
design science creates new artifacts for solving practical problems. Moreover, design science is
characterized by the design of artifacts, such as methods, models, constructs, frameworks, prototypes or IT
systems, which will be “introduced into the world to make it different, to make it better” [25].
The design science research process carried out in this research included five research activities as
defined by the design science method framework of Johannesson and Perjons [25]. These activities and
their application are presented below.
2.1. Explicate problem.
This first activity in the design science method is to explicate a practical problem that justifies why
an artifact was designed and developed, in our case, why the artifact BPDT was designed and developed.

254 Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
The practical problem encountered was that low quality of BPD impedes the use of BPs. This problem
was taken from literature, see for example, [12, 20, 21, 22, 23, 26].
2.2. Define requirements
This second activity is to define requirements on the artifact, in our case, th e requirements on the
BPDT. These requirements can be seen as a transformation of the problem into demands on the
proposed artifact. We have identified some standard requirements on documentation attributes from
[24, 25, 26]. These have been the base to define the requirements on the BPDT.
x
x
Requirement 1
The BPDT shall consist of a complete set of BP attributes to achieve its defined goal, that is, the BPDT
shall include all possible BP attributes that are needed to achieve its defined goal. According to research
literature, the successful application of BPs depends on their complete documentation [15, 18].
x
Requirement 2
The BPDT shall be easy to use for practitioners in achieving their goals, that is, users should be able to
use the artifact to achieve a particular goal easily. According to research literature, a clear documentation
structure will distill information about a BP into a BPD that is easy to use [13, 18].
x
Requirement 3
The BPDT shall support both the design of high quality BPs and the evaluation of already designed
BPs. This means that the BPDT shall be possible to use when documenting new BPs as well as increase
the documentation quality of already existing BPs. Researchers have emphasized the need of a structure
for BPD that facilitates design but can also be used to evaluate already designed BPD [3, 18].
2.3. Design and Develop Artifact
This third activity is to design and develop an artifact that addresses the explicated problem and
fulfills the defined requirements, in this case design and develop the BPDT. The design and development of
the final BPDT is described in section 3.
2.4. Demonstration
This fourth activity is to use the designed and developed artifact in an illustrative or real-life case,
sometimes called a “proof of concept”, thereby proving the feasibility of the artifact. The BPDT has
been applied in three real-life cases. The demonstration and its result are presented in section 4.
2.5. Evaluation
This fifth activity is to assess how well the BPDT solves the practical problem while taking into
account the three previously identified requirements. We have evaluated the final BPDT by conducting
semi-structured interview with 16 practitioners. However, the result of the evaluation is analyzed in
Alwazae et al. [26], and, therefore not presented in this paper.
3. Design of the BPDT
The third activity in the design science method used is, as mentioned in Section 2, to design and develop
the artifact. The BPDT was developed by means of two complementary processes, each one resulting in a
tentative BPDT. These two tentative templates were then merged into the Final BPDT. The research
steps are described briefly b elow.

255
Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
3.1. Designing a first tentative BPDT
A first tentative BPDT was created by first collecting a number of attributes from a basic
literature review and from our own experience in knowledge management (KM) and enterprise
modelling. This resulted in a first draft of a BPDT including attributes and categories. The categories
are called components in the BPDT. Then the first draft of the BPDT was evaluated and refined in five
refinement phases. In each phase, one or two practitioners or academic experts were asked to evaluate
and refine the template, and based on their input, attributes were added, deleted or refined. In total,
interviews were carried out with seven practitioners and academic experts in the area of BP. Purposive
sampling was applied to select the participants. The research process for the first tentative BPDT is
described in Alwazae et al. [27].
3.2. Designing a second tentative BPDT
A second tentative BPDT was created based on a literature review, applying grounded theory. The
research process followed a grounded theory process in five steps described by Wolfswinkel et al.
[28]. First, articles needed for the grounded theory analysis were gathered in a number of steps. This
resulted in 31 final articles. In the next step, 272 excerpts from these articles were identified based on the
research question at hand. These excerpts were used for open axial and selective coding. Using open
coding, we identified and defined 24 concepts with their supporting excerpts, and with axial coding, we
grouped the concept into 9 sub-categories. We also defined the concepts and sub-categories. For
example, the concept adaptability was defined as the degree to which a BP can be easily modified and
adapted to other situations. The coding revealed that adaptability was found in seventeen articles,
including [12, 13].
3.3. Combining the first and second tentative BPDT
We merged the first tentative BPDT and the second tentative BPDT from the literature study. As
part of this activity, we identified similar attributes in the first and second tentative BPDT and deleted
such overlapping attributes. The final BPDT is described in Table 1.
Table 1. The final BPDT
Component
BP Attributes
Summary of BP
1.
Title: An identifying name for the BPD
2.
Summary: A short description of the contents of the BPD
BP
3.
Pattern Attributes: Contains problem, solution and context
Representation
4.
Author Contact Information: Information about the authors of the BPD, including, name, address
and e-mail
5.
Revision Information: Information about all previous versions of the BPD
6.
Reviews Information: Information about reviews of the BPD with URLs or other pointers
Requirements
7.
Goal: The intended effect of applying the BP
for Applying
8.
Means: The means that are needed for applying the BP, including people and technology
BP
9.
Skills: The skills and competence required of the end-user for applying the BP
10.
Cost: An estimation of the costs for applying the BP
11.
Barriers: Obstacles or problems that may occur before, during, and after applying the BP
12.
Barrier Management: Procedures to follow if certain obstacles or problems are encountered

256 Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
BP Actor
13.
Community of Practice: Community of practice that may be interested in using the BP
14.
Champion: The need and role of a champion for the BP
15.
Owner: The BP owner or responsible who might be an individual, role, department or organization
16.
Training Needs: The degree to which a person has to be trained in order to use the BP
17.
Acceptability: Th e degree of BP acceptance by domain experts - in general and/or in the
organization - for resolving the problem addressed by the BP
BP Properties
18.
Usability: The degree to which the BP is easy to use
19.
Comprehensiveness: The degree to which the BP offers a comprehensive and complete view
of the problem and solution under consideration
20.
Relevance: The degree to which the problem addressed by the BP is experienced as
significant by practitioners
21.
Justification: The degree to which evidence shows that the BP solves the problem
22.
Prescriptiveness: The degree to which the BP offers a concrete proposal for solving the problem
23.
Coherence: The degree to which the BP constitutes a coherent unit, i.e., all parts are clearly related
24.
Consistency: The degree to which the BP is consistent with existing knowledge and vocabulary
used in the target industry sector or knowledge domain
25.
Granularity: The degree to which the BPD is appropriately detailed
26.
Adaptability: The degree to which the BP can be easily modified and adapted to other situations
27.
Activity: The tasks to be carried out in the BP
28.
Integration: The degree to which the BP is integrated with other BPs and KM components
BP
29.
Demonstration of Success: A case where the BP is successfully demonstrated
Implementation
30.
Installation Time: The time it takes to introduce and implement the BP in an organization
31.
Application Time: The time it takes to apply the BP in an organization
32.
Experiences and feedback: Users’ opinions, advices and experiences of the BP
33.
Measurement: Indicators for measuring the quality and performance of the BP
4. Demonstration of the BPDT
In this section, the demonstration of the BPDT is presented. The demonstration was carried out as
three real-life cases in three real-life organizations. The aim of the demonstration was to show the
feasibility of the artifact.
4.1. Research approach for demonstration
The BPDT was presented to experts in three organizations. One expert from each organization was
asked to apply the BPDT on two or more BPDs from his/her organization. Then, a semi-structured
interview was conducted with each of the experts. In the beginning of each interview, the practical
problem that the BPDT was intended to address was presented. The experts were then asked a number
of semi-structured questions about the BPDT. Questions were asked about which attributes were not used
in the organizations’ existing BPDs; which attributes were difficult to apply on existing BPDs and
why; which attribute were not given any data/value during demonstration and why. Moreover, questions
were asked about the fulfillments of the requirements; overall opinions and obstacles of applying the
BPDT; and whether the experts had any improvements of the BPDT to suggest.
4.2. Description of real-life cases
In this section, the three real-life cases are described.

257
Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
x
x
First real-life case
In the first real-life case, two BPDs from an organization were used to demonstrate the BPDT. The
organization was a global organization within the oil domain. The organization has more than 10 000
employees, operating in 37 countries. The researchers conducted an interview with a KM consultant within
the organization that applied the BPDT. The KM consultant was responsible for developing the KM
strategy and KM solutions. Knowledge sharing in the organization was done through BPs and learning
sessions.
x
Second real-life case
In the second real-life case, three BPDs from an organization were used to demonstrate the BPDT.
The organization was a global organization within the IT domain with more than 1 000 employees
operating mainly in Europe and Asia. The researchers conducted an interview with a KM consultant
within the organization that applied the BPDT. The KM consultant was responsible for improving the
way people communicate, directly or through information technology, and for using BPs for Business
Process Management.
x
Third real-life case
In the third real-life case, three BPDs from an organization were used to demonstrate the BPDT. The
organization was an organization within the IT industry with more than 500 employee operating nationally.
The researchers conducted an interview with a KM manager within the organization that applied the
BPDT. The KM manager has expertise in innovation, change management, strategy development,
business processes improvement and IT consulting.
4.3. Result of the application
In this section, the overall result of the demonstration is presented. It is structured according to the
BPDT requirements presented in section 2.
x
Requirement 1
The first requirement is that the BPDT shall consist of a complete set of BP attributes to achieve
its defined goal. Two experts (i.e., real-life cases 2 and 3) confirmed that the BPDT covers all of the
attributes in their BPDs, and one of them (i.e., real-life case 3) stated “I suppose your template is quit
full. I think it is the most full template I have seen in my practice”. In real-life case 1, the expert
added the following attributes to the BPDT from organization’s own BPDs in order to make the BPDT
more suitable for the organization’s BPDs: project number and name, keywords, effective date, next review
date, accountable function, accountable discipline, functional areas, sub-functional areas, technology
platform, research and development platform, applicable process, co-authors and co-contributors. Note
that all these attributes, which are more concrete and detailed then the ones in BPDT, could be covered
by other more generic attributes in the BPDT.
x
Requirement 2
The second requirement is that the BPDT shall be easy to use for practitioners in achieving their
goals. Two experts (i.e., real-life cases 1 and 3) stated that the description of the attributes is clear and
straight- forward, and there is no need for reformulation. In real-life case 2, the expert suggested the
reformulation of the description of the attributes, usability and comprehensiveness, as the reader might not
see intuitively how to apply them and the user who should document the BP might not be able to
estimate the comprehensiveness and easiness of use. The three experts were asked to identify which
attributes from the BPDT were not filled in when applying it to the BPD from their organizations. The
three experts found, in general, that the unfilled attributes were due to the incomplete and unstructured
descriptions in their own BPDs.

258 Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
The demonstration showed that all three experts from the three real-life cases manage to apply 14
attributes in all of their BPDs. These attributes were: title, summary, pattern attributes, revision
information, author contact information, reviews information, barrier management, owner, justification,
prescriptiveness, coherence, consistency, adaptability and experiences and feedback. The demonstration
also showed that 18 of the attributes were very easy to apply in BPDs, according to the three experts,
that is, the experts did not encounter any difficulties applying them. These attributes were: title,
summary, pattern attributes, revision information, author contact information, reviews information,
means, costs, barrier management, owner, relevance, prescriptiveness, consistency, activity, integration,
installation time, application time and experiences and feedback.
The expert in real-life case 1 had difficulty applying five of the attributes (i.e., skills, community
of practice, training needs, acceptability and comprehensiveness) due to lack of information in their
BPDs. The expert stressed the difficulty to identify and specify data/values for some of the attributes if
the users do not know for which situation and audience the BP is documented. One such attribute is
skills.
The expert in real life case 2 had difficulty applying nine of the attributes (i.e., goal, barriers,
usability, comprehensiveness, justification, coherence, adaptability, demonstration of success and
measurement) due to lack of information in their BPDs. The expert emphasized the difficulty of
specifying the data/values for some attributes because post action feedback was not applied in the
organization. One such attribute was justification. Another problem was that the documentation of
data/values for some attributes are rather subjective.
The expert in real life case 3 had difficulty applying seven attributes (i.e., skills, barriers, champion,
usability, coherence, granularity and adaptability). These difficulties are related to the lack of
information in their BPDs. This expert also, as the expert in real-life case 2, emphasized the difficulty
of documenting data/values for attributes that are rather subjective.
x
x
Requirement 3
The third requirement is that the BPDT shall support both the design of high quality BPs and the
evaluation of already designed BPs. According to the experts from the three real-life cases, the BPDT
could be used for both these purposes, although the demonstration was mainly used for evaluating already
existing BPD in order for example to identify missing attributes in theses.
The demonstration showed that one BP attribute, skills, did not exist in any of the three
organizations BPDs. However, the expert from real-life case 2 would like to use it in some of their
BPDs. Also, the attribute, training needs, did not exist in real-life cases 1 and 2. Four other attributes
(i.e., usability, demonstration of success, installation time and application time) did not occur in two of
the real-life cases. One expert (i.e., real-life case 2) confirmed the possibility of adding these attributes to
their BPDs, since they would enhance the application of the BP.
Finally, the experts were asked to express their overall opinion about applying the BPDT. They
indicated that it represents a good foundation to structure and articulate BPDs. One expert (i.e. in real-
life case 1) stated “the template gives you a proper structure for what things you have to document,
and it makes BP a lot easier to use”. They also remarked that the BPDT is relatively straight-forward and
complete and, therefore, it seems to be useful for any industry.
The experts provided some concerns about applying the template in full scale: 1) people need to be
encouraged to fill out 33 elements since it requires some time to do that; 2) the often informal and
loose structure of existing BPDs makes it difficult to structure the BPDs according to the template; 3)
there is a need of technical support for applying the BPDT. Two experts suggested the creation of a KM
tool for applying the BPDT that included clear instructions and examples for its application.

259
Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
5. Conclusions
In this paper a BPDT is demonstrated in three real-life organizations. In each organization, the
BPDT has been applied on some number of BPDs. The demonstration showed promising results
regarding completeness, ease of use and that the template could be used to support the design of new
BPs as well as to evaluate already existing ones.
The demonstration have also identified a number of potential drawbacks of the BPDT, or the need
of additional support when implementing the BPDT:
x
x
One expert showed that the organization had more concrete attributes than the more generic
ones presented in the BPDT. This can cause some problem when applying the BPDT.
x
One expert showed that additional activities is needed for using all the attributes, such post action
feedback. Otherwise the experiences and feedback cannot be documented.
x
Two experts (from two different organizations) claimed that some attributes in the BPDT required
subjective judgments when adding data for these attributes. This can also cause some problem
when applying the BPDT.
x
All three experts (from three different organizations) stated that the BPDT consisted of 33
attributes and it will require some resources and time to add data for all these attributes.
x
All three experts (from three different organizations) also stated that the often loose structure of
existing BPDs makes is difficult to structure the BPDs according to the template
x
All three experts stated that there is a need of technical support for applying the BPDT, for
example in the form of a KM tool.
The potential drawbacks - or the need of additional support when implementing the BPDT - gave
some suggestion for future research. Methodological support is needed for 1) relating attributes already
used in an organization to the attributes in the BPDT; 2) supporting the users to add subjective
judgments for some of the attributes, and 3) customize the BPDT if there is a lack of resources to use
all 33 attributes when documenting BPs. Another research direction is to develop an IT tool to
enhance the application of the BPDT. Moreover, we suggest to demonstrate the BPDT in one
organization in depth, for example as part of a case study or action research project, and test the
BPDT’s relevance to the employees’ daily
References
[1] Jackson SE, Chuang CH, Harden EE, Jiang Y, Joseph JM. Towards developing human resource management systems for
knowledge-intensive teamwork. In: J.M. Joseph (Ed.), Research in personnel and human resources management, Amsterdam, The
Netherlands; 2006, p.27-70
[2] Wang S, Noe RA. Knowledge sharing: A review and directions for future research. Human Resource Management Review,
20; 2010, p. 115-131
[3] Jashapara A. Knowledge Management: An Integrated Approach. 2nd Edition. Pearson Education, Harlow, Essex; 2011.
[4] Argote L. Organizational Learning: Creating, Retaining and Transferring Knowledge. 2nd Ed. Springer Science and
Business Media, New York; 2013.
[5] Graupner S, Motahari-Nezhad HR, Singhal S, Basu S. Making processes from best practice frameworks actionable.
Enterprise Distributed Object Computing Conference Workshops, 13th IEEE, 1-4 September; 2009, p. 25-34
[6] Whittle S, Smith S, Tranfield D, Foster M. Implementing total quality: The downside of best practice. 7th Annual
Conference of the Operations Management Association on International Operations, Crossing Borders in Manufacturing and
Service, UMIST, Manchester, 23-24 June; 1992, p. 247-252
[7] Szulanski G. Exploring internal stickiness: Impediments to the transfer of best practice within the firm. Strategic
Management Journal; 1996, p. 17, 26-43

260 Meshari Alwazae et al. / Procedia Computer Science 72 ( 2015 ) 252 – 260
[8] O’Dell C, Grayson CJ. If only we knew what we know: Identification and transfer of internal best practices. California
Management Review, 40 (3); 1998, p. 154-174
[9] Davies AJ, Kochhar AK. Manufacturing best practice and performance studies: a critique. International Journal of
Operations & Production Management, MCB University Press, 22 (3); 2002, p. 289-305
[10] Netland T, Alfnes E. Proposing a quick best practice maturity test for supply chain operations. Measuring Business
Excellence, 15 (1); 2011, p. 66-76
[11] Watson GH. Strategic Benchmarking Reloaded with Six Sigma: Improve your Company’s Performance Using Global Best
Practice. John Wiley & Sons, Inc., Hoboken, New Jersey; 2007.
[12] Dani SS, Harding JA, Case K, Young RIM, Cochrane S, Gao J, Baxter D. A methodology for best practice knowledge
management. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, 220 (10); 2006,
p. 1717-1728
[13] Shull F, Turn er R. An empirical approach to best practice identification and selection: The US department of defense
acquisition best practices clearinghouse. Proceedings of International Symposium on Empirical Software Engineering, Au stralia;
2005, p. 133-140
[14] Simard C, Rice RE. The practice gap: Barriers to the diffusion of best practices. (McInerney, C.R. and Day R.E. Ed.), Re-
Thinking Knowledge Management: From Knowledge Objects To Knowledge Processes, Dordrecht, The Netherlands: Springer-
Verlag; 2007, p. 87-124
[15] Vesely A. Theory and methodology of best practice research: A critical review of the current state. Central European
Journal of Public Policy 2; 2011, p. 98-117
[16] Asoh D, Belardo B, Neilson R. Knowled ge Management: Issues, Challenges and Opportunities for Governments in the New
Economy. Proceedings of the 35th Hawaii International Conference on System Science, USA; 2002
[17] Wagner EL, Scott SV, Galliers RD. The creation of ‘best practice’ software: Myth, reality and ethics. Information and
Organization, 16 (3); 2006, p. 251-275
[18] Motahari-Nezhad HRM, Graupner V, Bartolini C. A framework for modeling and enabling reuse of best practice IT
processes. Business Process Management Workshops; 2010, p. 226-231
[19] Mansar S, Reijers H. Best practices in business process redesign: Use and impact. Business Process Management Journal,
Emerald Group Publishing Limited, 13 (2); 2007, p. 193-213
[20] Tabrizi RS, Ebrahimi N, Al-Marwai SA. On the comparison of KM criteria classifications. World Conference on
Information Technology, Procedia Computer Science, 3; 2011, p. 684-690
[21] Aggestam L, Persson A. Increas ing the quality in it-supported knowledge repositories: Critical success factors for
identifying knowledge. 43rd Hawaii International Conference on System Sciences (HICSS), Honolulu, HI, USA; 2010
[22] Dyer G, McDonough B. The state of KM . Knowledge Management, 4 (5); 2001, p. 31-36
[23] Dana LE, Smyrnios KX. Family business best practices: Where from and wh ere to. Elsevier Ltd, Journal of Family
Business Strategy, 1; 2010, p. 40-53
[24] Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Quarterly, 28 (1); 2004, p.
75-105
[25] Johannesson P, Perjons E. An Introduction to Design Science. Springer International Publishing, Switzerland; 2014
[26] Alwazae M, Perjons E, Johannesson P. Template-Driven Best Practice Documentation. Submitted; 2015.
[27] Alwazae MMS, Perjons E, Kjellin H. Quality Measures for Documentation of Best Practices. 47th Hawaii
International Conference on System Sciences (HICSS), HI, USA; 2014, p. 3410-3419
[28] Wolfswinkel JF, Furtmueller E, Wilderom C. Using grounded theory as a method for rigorously reviewing literature.
European Journal of Information Systems, 22; 2013, p. 45-55