Received: 26 July 2017 Accepted: 6 May 2018

DOI: 10.1002/kpm.1578

RESEARCH ARTICLE

An analysis of the relationship between knowledge sharing and

the project management process groups
Fernanda Gomes | Mírian Oliveira | Marcirio Silveira Chaves

School of Business, Pontifical Catholic

University of Rio Grande do Sul, Porto Alegre, Because knowledge sharing (KS) can leverage project results, this paper aims to ana-
RS, Brazil
lyze the relationship between KS and the project management process groups
Correspondence
Mírian Oliveira, School of Business, Pontifical (PMPGs). This qualitative research, conducted in large information technology (IT)
Catholic University of Rio Grande do Sul, companies, consists of two phases: (a) an exploratory phase, based on content analy-
Porto Alegre, RS, Brazil.
Email: miriano@pucrs.br sis of nine interviews and documents; and (b) a case study phase based on two cases,
where data collected from six interviews and documents were analyzed using content
Funding information analysis. The research facilitated the identification of the knowledge types involved in
CNPq; CAPES
each process group as well as opportunities to influence knowledge conversion, thus
enabling enhancement of the results obtained from KS in the organization. Further-
more, we identified opportunities to share interproject knowledge that can avoid
rework, optimize time, and reduce costs. The study's findings will allow managers to
define opportunities for KS in organizations, by identifying when knowledge is being
stored and so facilitating the retrieval process. Identifying how employees share
knowledge also provides an opportunity to stimulate and inhibit certain behaviors
and so create control mechanisms to enhance knowledge management. Lastly,
resource allocation is facilitated by identifying the IT necessary to support KS in pro-
ject teams and which stakeholders are required for each process group. This research
combines two different domains by focusing on the means by which KS can leverage
results in project management. It also proposes a new, empirically tested, relationship
for KS and PMPG, as well as expanding our understanding of the influence KS has on
project management.

1 | I N T RO D U CT I O N create a product, service or exclusive result” (PMBOK, 2013). IT pro-

Knowledge management (KM) consists of processes involving the
creation, sharing, storage, and use of knowledge that are intended to
contribute to the achievement of business objectives. The benefits
most widely associated with KM are improved organizational perfor-
mance and human resource development (Yahyapour, Shamizanjani,
& Mosakhani, 2015). However, other benefits are also attributed to
KM, such as improved relationships with clients and suppliers (Goldoni
& Oliveira, 2010).
Lech (2014) suggests the application of KM in the management of
information technology (IT) projects as an area of research to be
explored. IT projects allow companies to implement strategy and
improvements. A project is “a temporary endeavour undertaken to
jects are particularly relevant, given that investments in IT are likely
to increase in the coming years to enable companies to achieve a wide
range of objectives (Rigby & Bilodeau, 2015). Managing IT projects is a
complex activity because they are knowledge‐intensive, involve
interproject relationships (Lech, 2014), and require a variety of stake-
holders (Lampel, 2001).
Knowledge asymmetry between the stakeholders in an IT project
decreases over the course of a project, due to knowledge sharing (KS;
Lech, 2014). KS is one of the KM processes, “where individuals mutu-
ally exchange their (implicit and explicit) knowledge and jointly create
new knowledge” (Hooff & Ridder, 2004, p. 118). KS is important in
leveraging innovation, organizational learning, and the development
of new skills that can result in increased productivity (Mueller, 2014),

168 Copyright © 2018 John Wiley & Sons, Ltd. wileyonlinelibrary.com/journal/kpm Knowl Process Manag. 2018;25:168–179.
GOMES ET AL.
being considered one of the most important KM processes (Kuo &
Young, 2008). KS can aid in the project management (PM), because
learning from previous failures and successes means the wheel does
not have to be reinvented with each new project (Iebowitz &
Megbolugbe, 2003). Project managers have to consider the ways
and means by which knowledge is shared, otherwise the team will
make the same errors and the organization will pay to acquire the
same knowledge repeatedly (Fernie, Green, Weller, & Newcombe,
2003), which means that lessons learned should be leveraged (Rhodes
& Dawson, 2013).
According to Todorovic, Petrovic, Mihic, Obradovic, and Bushuyev
(2015, p. 773), KM “is an insufficiently explored topic in project man-
agement” and its mechanisms should be adopted according to the
stages of KM implementation in the organizations (Oliveira, Maçada,
& Curado, 2014). KS, one of the KM processes, is a major concern
for project managers (Bell, van Waveren, & Steyn, 2016; Fernie
et al., 2003), and the capacity for KS across projects is often limited
(Andersen & Hanstad, 2013). Taking that into account, this research
aims to analyze the relationship between KS and the project manage-
ment process groups (PMPGs) in IT projects, considering the types of
knowledge, the stakeholders, and ITs involved. It is hoped that the
results of this research will contribute towards raising productivity
and reducing costs in IT projects.
This article is divided into eight sections. Following this introduc-
tion, Section 2 presents the main concepts related to the PMPGs and
KS. After which, Section 3 describes the methodology adopted in this
research. Section 4 presents the results of the exploratory research,
and Section 5 the results from the case studies. In Section 6, the results
are discussed, and finally, in Section 7, the theoretical and practical
implications are presented, followed by the conclusions (Section 8).
2 | T HE R E L A T I O N S H I P BE T W E E N T H E
PMPGs AND KS
In this paper, KS is considered synonymous with the transfer and dis-
semination of knowledge, involving individuals (employees and external
clients). KS is a process that allows the transformation of individual
learning into organizational capacity (Nesheim & Hunskaar, 2015).
Physical proximity among individuals can be considered a facilitator
for KS (Janet, Wee, & Chua, 2013), and IT is a means of reducing the
barrier of geographical distance (Coakes, 2006). KS can be supported
by IT (Oliveira et al., 2014), especially in the geographical distribution
of staff. Examples of such IT are electronic discussion forums, blogs,
and e‐mails (Bell et al., 2016). These technologies can be used in the
different PMPGs. Regarding each project process, many channels are
used, but face‐to‐face is considered important because it provides the
opportunity for interaction (Koskinen, Pihlanto, & Vanharanta, 2003).
KS has to occur at each stage of an IT project. KS meetings held
following project completion may not achieve their goal because les-
sons may have already been forgotten (Bell et al., 2016). The authors
highlight the relevance of institutionalizing KS mechanisms with the
aim of retaining knowledge within the organization. KS is important
for the retention of knowledge, for example, in the case of an
employee leaving the company.
169
Regarding the types of knowledge shared, we adopt Nonaka and
Konno's (1998) consolidated classification, by which knowledge can
either be tacit, which means that it is shared among individuals with-
out being documented, or explicit, as in documents with the lessons
learned from a project. Both these types of knowledge can be shared.
Nevertheless, project teams prefer tacit knowledge and social interac-
tion among their members (Zhang & He, 2016). Tacit knowledge is
based on an individual's experience, and team members prefer to seek
knowledge by consulting a colleague—tacit knowledge—than by
searching a repository—explicit knowledge (Koskinen et al., 2003).
Knowledge can be seen as something that is made to be constantly
mobilized and applied, rather than only being managed to be captured
and stored (Sandhawalia & Dalcher, 2010).
Knowledge can also be classified as either business knowledge or
technical knowledge (Lech, 2014). Business knowledge relates to func-
tional areas such as accounting, sales, and human resources, for exam-
ple. Technical knowledge is “necessary in conjunction with the
selection and use of database management software, network man-
agement, add‐on programming, client‐server‐architectures and perfor-
mance measurement” (Lech, 2014, p. 553).
KS can improve the quality of work within a project and also
between projects (Nesheim & Hunskaar, 2015). Projects are tempo-
rary, limited by scope and time (Todorovic et al., 2015). “The core pro-
ject management is the management of a temporary task with a
definite start‐up and end‐point in time” (Nesheim & Hunskaar, 2015,
p. 1417). The Project Management Institute describes the PMPGs
(PMBOK, 2013). Each PMPG (Initiating, Planning, Executing, Monitor-
ing and Controlling, Closing) contains a number of dossiers submitted
by the PMBOK (2013), which are summarized in Tables 1–5. Table 1
shows the Initiating process group.
Table 2 shows the Planning process group.
Table 3 shows the Executing process group.
Monitoring and Control “consists of the processes required to
track, review and regulate a project's progress and performance, iden-
tify any areas in which changes are needed in the plan and initiate the
corresponding changes” (PMBOK, 2013). Table 4 shows the Monitor-
ing and Control processes in this group.
Closing includes the closure of the project or phases and the clo-
sure of the procurement, as shown in Table 5.
The process groups do not necessarily follow a linear sequence
(they might also occur in parallel). For example, whereas Executing is
ongoing, Monitoring and Control activities may also be occurring.
During the empirical research, for each PMPG, the following
aspects will be analyzed: (a) type of knowledge—tacit × explicit; tech-
nical × management; intraproject × interproject; (b) stakeholders; and
(c) IT support.
TABLE 1 Initiating process group
Process Stakeholders
Develop project Project sponsor; stakeholders; project
charter manager
Identifying Project manager; project team
stakeholders
Source: Adapted from the PMBOK (2013).
170 GOMES ET AL.

TABLE 2 Planning process group

Processes Stakeholders
Develop project management plan Project manager; project team; program and portfolio manager
Plan the management scope Project manager; project team; clients
Collect requirements Client, project team; project manager
Define scope Client/stakeholders/project team; project manager
Create work breakdown structure (WBS) Project team; project manager
Plan the schedule management Project manager; project team; clients
Define activities Project team; project manager
Sequence activities Project team; project manager
Estimate activity resources Project team; project manager
Estimate activity durations Project team; project manager
Develop schedule Project manager
Plan cost management Project manager; program; portfolio and project office manager; project sponsor
Estimate costs Project team; project manager
Determine budget Project team; project manager; program, portfolio and project office manager
Plan quality management Client/stakeholders/project team/project manager
Develop human resources plan Project team; project manager
Plan communications Clients/stakeholders/ project team/project manager/program manager/portfolio manager/project office
manager; project manager
Plan risk management Client/stakeholders/project team/project manager/program manager/portfolio manager/project office
manager; project manager
Identify risks Client/stakeholders/project team/project manager/program Manager/portfolio manager/project office
manager
Perform qualitative risk analysis Project team; project manager; clients/stakeholders
Perform quantitative risk analysis Project team; project manager; clients/stakeholders/project manager/project team/program and portfolio
manager/project office manager
Plan risk responses Project team; project manager
Plan procurements Project manager; project team; program/portfolio/project office manager
Plan stakeholder management Project manager; project team

Source: Adapted from the PMBOK (2013).

TABLE 3 Executing process group

Processes Stakeholders

Direct and manage project Execution Project team; project manager

Perform quality assurance Client/stakeholders; project manager
Acquire project team project manager
Develop project team Project manager, project team
Manage project team Project manager
Management communication Project manager; project team
Conduct procurements Project manager
Manage stakeholder expectations Project manager; project team

Source: Adapted from the PMBOK (2013).

3 | METHOD
This research adopts the positivist paradigm using a qualitative
approach, because it is necessary to acquire an in‐depth understand-
ing of the issue (i.e., KS) in each given context (i.e., PM; Malhotra &
Galletta, 2002). An exploratory phase was followed by a multiple case
study because diversity in relation to research methods in the Infor-
mation Systems area is thought to benefit such research by facilitating
the capture of valuable information (Venkatesh, Brown, & Bala, 2013).
The exploratory phase, consisting of interviews with experts, was
intended to review and supplement the relationship between KS and
the PMPGs. Case study methodology was used because it is suitable
when the object is a broad and complex phenomenon and requires a
holistic, in‐depth analysis, as well as being inseparable from the con-
text in which it is inserted (Yin, 2005).
We conducted nine interviews in the first phase (exploratory) and
six interviews in the second phase (case study), stopping when we
found data saturation in each phase (Yin, 2005). In both phases, data
were collected from documents and interviews to ensure data triangu-
lation. All the documents provided, which included business require-
ment document, system requirement document, technical design
document, project plan, materials from meetings (minutes,
GOMES ET AL. 171

TABLE 4 Monitoring and Control process group This content was analyzed according to Bardin (2008). The categories

Processes Stakeholders
are the type of knowledge, the stakeholders, and the IT, and the sub-
categories were identified in the interviews. Initially, open coding was
Monitor and Control the Project manager; program/portfolio/
project work project office manager used. After which, axial coding was conducted to categorize the
Perform integrated change Project manager/program/portfolio/ interviewees' responses while respecting the characteristics identified
control project office manager/ in each category (Motavire & Brown, 2013).
stakeholders
The following phase consisted of a multiple case study. The unit
Verify scope Client
of analysis is the IT project. The multiple case study considered two
Control scope Project manager
projects, carried out in different companies. Similar results were
Control schedule Project manager
expected from the chosen case studies, namely, that the company is
Control costs Project manager
not an intervening factor in the analyzed relationships.
Perform quality control Project manager
For this research, criteria were adopted for the selection of
Control communications Project manager
companies in which the projects were selected, as well as for the
Control risks Project manager
selection of projects. The identity of the companies will be kept con-
Administer procurement Project manager
fidential, and for the purposes of this study, they will be identified as
Control stakeholder involvement Project manager
Company A and Company B. Similarly, the identification of the pro-
Source: Adapted from the PMBOK (2013). jects (analysis units) on which this study is based will be maintained
confidential, and they will therefore be identified as Project 1 and
Project 2.
TABLE 5 Closing process group
The selection criteria for the companies where the cases were
Processes Stakeholders investigated determined they should be large (over 100,000
Close project or Project manager; project team employees) multinational companies in the technology sector. This
phase
type of company tends to work with multifunctional project teams,
Close Project manager; program/portfolio/project office
procurements manager covering a wide range of professionals and multicultural project teams.
In addition, the technology sector usually works on projects. It was
Source: Adapted from the PMBOK (2013).
decided to select only IT projects in order to eliminate ambiguities that
projects of a different nature could bring to the study. The projects
presentations), and metrics, were reviewed. The documents were not
had to have been completed between 2014 and the onset of data col-
mentioned explicitly as authorization was not obtained from the com-
lection, so that interviewees could easily remember them.
panies. Table 6 presents the interviewees' profiles.
Companies A and B have been operating in the technology field
The interview script (see Appendix A) was prepared considering
for over 30 years. Project 1 in Company A was intended to reduce
each of the PMPGs and the type of KS (tacit × explicit, technical × man-
the number of telephone contacts between customers and the
agement, intraorganizational × interorganizational); the stakeholders
company's customer service staff to reduce the cost these contacts
involved in KS; and the IT used to support KS. An expert in KS and a
generate. The aim of the project was to include more options in the
project manager validated the script. The interviews took place at
electronic service menu so that when clients called the company, it
the interviewees' companies, lasted around 30 min, were recorded
would be unnecessary to call a professional because the electronic
and later transcribed, which generated more than 250 pages of text.
menu itself could guide the customer in relation to how to meet their
need. The project was carried out between June 2014 and February
TABLE 6 Interviewee profiles 2015, and the team consisted of a developer, two test area profes-
sionals, a business analyst, a project manager, and an outsourced com-
Time
working pany to develop and upgrade the system. Project 2 in Company B, a
Time in in the IT technology services provider, was intended to consolidate a
the position field
Interview Interviewee Position (years) (years) customer's antivirus management environment in a single and new

Experts 1 Project manager 8 5

management console in the latest version of the product used,
2 Project manager 2 22 Symantec Endpoint Protection, on a system platform operating in
3 Project manager 10 20
the latest version. The old servers were disabled, which would reduce
4 Project manager 3 13
5 Project manager 3 13 costs for the customer. The new console management structure was
6 Project manager 6 22 revised and changed to reduce extra settings not used in the old con-
7 Project manager 4 16
8 Project manager 6 10 sole/version. These settings left the console clean and improved the
9 Project manager 3 15 management of rules, policy groups, and support for the managed
Case Study A 10 Project manager 5 15 machines. The project was carried out from August to November
11 Test analyst 9 14
12 Developer 15 15 2015, and the team included a solution architect, two antivirus admin-
Case Study B 13 Project manager 10 5 istrators, an SQL Server database analyst, a Windows operating sys-
14 IT architect 1 10 tem analyst, a VMware virtualization analyst, a backup analyst, a
15 IT analyst 5 13
monitoring analyst, and a project manager.
172 GOMES ET AL.

4 | EXPLORATORY PHASE ANALYSIS
The analysis is structured according to the three aspects studied:
knowledge type, the stakeholders involved, and IT used for KS in the
different PMPGs.
4.1 | KS and the type of knowledge generated
We considered the following aspects in the analysis of the type of
knowledge: tacit or explicit; technical or management; and intraproject
or interproject. Table 7 shows the results identified for the group of
initiating processes.
Table 8 shows the results identified for the group of Planning
processes.
Table 9 shows the results identified for the group of Execution
processes.
Table 10 shows the results identified for the group of Monitoring
and Control processes.
Table 11 shows the results identified for the group of Closing
processes.
Management and technical knowledge are shared throughout the
projects, but at different intensities depending on the group of pro-
cesses. In addition, knowledge is converted (Nonaka & Konno,
1998), from tacit to explicit, for example, and the modes of conversion
can be inhibited or stimulated to benefit the organization. Another
important finding was that in most cases in which interproject sharing
occurs, it is because the projects are somehow related, so that, the
scopes are related and, therefore, greater benefit is perceived when
KS (Hooff & Ridder, 2004) occurs.
A great deal of discussion and tacit KS were seen to occur
during the PMPGs, the outcome of which tended be externalized,
documented, and stored to facilitate recovery of that knowledge

TABLE 7 Type of knowledge shared in the Initiating processes

Aspects Observations
Tacit × explicit Tacit knowledge transformed into explicit knowledge through the documentation of business requirements, which will later
be used in other activities related to the project.
Technical × management Most of the knowledge shared during Initiation is related to the business strategy; therefore, it is management.
Technical knowledge is also shared when it comes to internal IT projects and when the requirements begin to be detailed
during Initiation.
Intraproject × interproject Intraproject knowledge sharing predominates, because it is related to the work of the project itself. When there is a
relationship between projects, interproject knowledge sharing may occur.

TABLE 8 Type of knowledge shared in the Planning process group

Aspects Observations

Tacit × explicit Explicit knowledge is dominant during planning because of the amount of documentation generated. However, tacit
knowledge is also shared, which is crucial for the documentation generated to be of the required quality.
Technical × management Both types of knowledge are shared. However, management knowledge is the focus of knowledge sharing during planning,
because the project goal is defined.
Intraproject × interproject Knowledge arising from the planning can be both intraproject and interproject.

TABLE 9 Type of knowledge shared during Execution

Aspects Observations
Tacit × explicit Tacit: knowledge shared by the project team, largely originating from the team's experience.
Explicit: documentation arising from the execution, for example, the minutes of meeting where project team decisions are
documented.
Technical × management Technical: main type of knowledge shared during the execution.
Management: While also shared during the execution, it is not the main focus.
Intraproject × interproject The knowledge shared is based on the execution of activities during a specific project. However, certain projects may
indicate good practices that should be shared with other project teams.

TABLE 10 Type of knowledge shared during the Monitoring and Control processes
Aspects Observations
Tacit × explicit Tacit: knowledge discussed in the appropriate forums in relation to the monitoring and control processes.
Explicit: documented knowledge arising from the monitoring and control processes.
Technical × management Technical knowledge is the basis for knowledge sharing management knowledge, because it provides inputs that facilitate
the generation of managerial knowledge.
Management knowledge: indicators that show the project's “health” status.
Intraproject × interproject Knowledge is shared both with the internal project team design as with other project teams and even external forums (board
meetings, for example).
GOMES ET AL. 173

TABLE 11 Type of knowledge shared during the Closing processes

Aspects Observations
Tacit × explicit Explicit: related to the bureaucratic activities involving the project closure (documentation, etc.).
Tacit: meetings, trainings.
Technical × management Management: bureaucratic activities involved closing the project (documentation, etc.).
Technical: lessons learned and the sharing of technical knowledge from the project activities with the client.
Intraproject × interproject Intraproject: bureaucratic activities related to the project closure.
Interproject: making documentation and lessons learned from the project available for future reference by other project
teams.

for future use. Thus, good practices identified in one project
may be applied to facilitate work on future projects and optimize
the results.
4.2 | KS and the stakeholders involved
We noted that the project managers were concerned with allocating
staff members from development and test teams and from other pro-
jects that depended in some way on the project in question as early as
feasible (if possible, from the Initiating process group). This allows the
team members to become familiar with the project's business goals
and the client to share with those professionals the knowledge needed
to support other project activities to avoid misunderstandings that
may impact the scope of delivery. This means that KS is extremely
important in IT projects, as suggested by Lech (2014). Another notable
point drawn from the analysis of the results is the involvement of the
client throughout the project cycle, even during the execution of the
project—stakeholder management (PMBOK, 2013), where the shared
knowledge tends to be technical. The project managers were seen to
be concerned about sharing both technical and management knowl-
edge with the client to ensure their constant involvement (as an active
member of the project team), as this tends to decrease divergence
regarding expectations and, consequently, increase the likelihood of
the project being successful. Finally, the executive levels were seen
to be closely involved during the project, as shown by the fact the pro-
ject manager's report on status was constantly updated throughout
the project life cycle. This is another example of stakeholder manage-
ment and expectation alignment (PMBOK, 2013). Table 12 shows the
stakeholders involved in KS within the various PMPGs, as mentioned
by the interviewees.
Different stakeholders are involved in the PMPGs, and knowing
which stakeholders are needed for each PMPG is critical for enhancing
resources and ensuring all the necessary stakeholders are properly
committed (PMBOK, 2013). From the Initiating stage, the project man-
agers were seen to be concerned to engage at least one representa-
tive from each of the teams involved to ensure alignment with the
scope and activities required for the project. In addition, there was a
noticeable involvement of external stakeholders in the different
PMPGs, such as the PM office and executive team (mainly) during
Monitoring and Control activities. This fact suggests that the project
teams have activities related to the organization's strategy, as each
project team is responsible for the implementation of its scope (i.e.,
the implementation of the strategy through projects), as suggested in
the literature review (PMBOK, 2013).
4.3 | Technologies supporting KS
Numerous technologies perform the same function (i.e., they meet the
same business need), and this can cause variations that allow the pro-
ject team to share knowledge internally and externally. However, sev-
eral technologies are used to reduce the barrier of geographical
distance (Coakes, 2006). Table 13 presents the results of the

TABLE 12 Stakeholders

Initiating Planning Executing Monitoring and Control Closing

Stakeholders Interviewed Interviewed interviewed Interviewed interviewed
Project Manager All All All All All
Business Analyst / Product Manager 1, 2, 4, 5, 6, 9 1, 3, 4, 5, 6, 8, 9 3, 4, 5, 6, 8, 9 1, 6, 8, 9 1, 3, 4, 5, 6, 8, 9
Client 1, 2, 3, 5, 6, 7, 8, 9 1, 3, 5, 6, 7, 8, 9 1, 2, 3, 5, 6, 7, 8, 9 1, 2, 5, 6, 7, 8 1, 2, 3, 4, 5, 6, 7, 8
Management Board 1 1, 9 1, 3, 9 All 1, 2, 4, 6, 7, 9
Test professionals 1, 4, 5, 7, 8 All All 1, 2, 6, 7, 8, 9 All
Auditors 1, 3 1, 3 1, 3 1, 3 1, 3
PMO members 3, 4, 9 2, 3, 4, 9 3, 4, 9 1, 2, 3, 5, 6, 7, 9 2, 3, 4, 6, 7
Developers 4, 5, 6, 7, 8 1, 2, 4, 5, 6, 7, 8, 9 All 1, 2, 4, 6, 7, 8, 9 All
Shared Services 4, 8 2, 3, 4, 6, 7 2, 3, 4, 6, 7, 9 2, 6, 7 2, 3, 6, 7
Managers 5, 7, 9 1, 3, 5, 6, 7, 8, 9 All 2, 3, 4, 6, 7, 8 2, 4, 5, 6, 7, 8
Program Manager 7 1
Systems Analyst 7, 8 7 7 7 7
Managers of Interlocking Projects 9 1, 2 1 9 9
Release Manager 2 4, 9

Note. PMO: project management office.

174 GOMES ET AL.

TABLE 13 Technologies involved in knowledge sharing

Initiating Planning Executing Monitoring and Control Closing

IT Interviewed Interviewed interviewed Interviewed interviewed
Instant Messages 1, 3, 4, 5, 6, 7, 8, 9 All All All All
Microsoft office All All 1, 2, 4, 5, 6, 7, 8, 9 1, 2, 4, 5, 6, 7, 8, 9 1, 2, 4, 5, 6, 7, 8, 9
PM Tools All All 1, 2, 4, 5, 6, 7, 8, 9 All 1, 2, 3, 4, 5, 6, 7, 9
E‐mail 1, 2, 3, 5, 6, 7, 8, 9 1, 3, 5, 6, 7, 8, 9 1, 3, 4, 5, 6, 7, 8, 9 1, 3, 4, 5, 6, 7, 8, 9 1, 2, 3, 4, 5, 7, 8, 9
SharePoint 1, 3, 4, 5, 6, 7, 8, 9 All 1, 2, 3, 4, 5, 7, 8, 9 1, 2, 3, 4, 5, 7, 8 1, 2, 3, 5, 6, 7, 8, 9
Team Foundation Server (TFS) 1, 2, 5 1, 5, 6, 7 8 1, 3, 4, 5, 6, 7, 8, 9 1, 3, 5, 7, 8 1, 7
Tele‐Conferencing 3, 4, 5, 6, 7, 8, 9 2, 3, 4, 5, 6, 7, 8, 9 2, 3, 4, 5, 6, 7, 8, 9 2, 3, 4, 5, 6, 7, 8, 9 2, 3, 4, 5, 6 ,7, 8
Video‐ Conferencing 6, 9 6, 9 3, 6, 9 6 6
Wiki ‐ 3 7 7 7
Drop‐Box 8 8 8 8 8
Technical Tools (Development and Test) ‐ ‐ 2, 9 ‐ ‐

Note. PM: project management.

interviews with respect to the IT involved in KS during the different
PMPGs, consolidating the technologies and PMPG according to each
of the interviewees.
Similar technologies are used for KS within the PMPGs during the
project life cycle, because they are considered essential to ensure the
necessary activities throughout the project. As an example, one can
mention activities such as knowledge storage (Sharepoint), or even
communication between members of the project teams (tele‐ and
video‐conferencing and e‐mail). Moreover, technologies provide more
effective control over what is being carried out by project teams (an
example of such technologies are the management project tools and
team foundation server [TFS]). Hence, clearly, once it is decided which
technologies will be used during the project, they tend to remain
throughout the project life cycle, with little variation (e.g., TFS is not
always used during the project Initiating or Closing, but once it starts
to be used during Planning, it is also used during the Executing and
Monitoring and Control—this is an example of variation). Nevertheless,
according to the trend seen in this research, once the technology is
defined, it tends to be used for KS throughout most of the PMPGs.
the business requirements document, which is analyzed by the project
team together with the client.
The knowledge originating from the Initiation can be used for
multiple projects. However, this was not a consensus in Case Study
A, where only the professional testing area believes that knowledge
from the Initiation can be shared among similar projects. The
interviewed developer and the project manager believe that such
knowledge is relative to a single project. This discrepancy may be
due to the nature of the functions of each role, as the scope of work
of both the project manager and the developer varies dramatically
from project to project, whereas that of the test professionals tends
to follow a software determined by the organization. In this case,
the knowledge originating from the Initiation tends to be intraproject
in Case Study A, which is also in line with the results of the interviews
with the experts.
Interviewee 06: “[…] most of the projects I have worked with, in
practically all of them, the BRD (Business requirement document) is
focused on a project.”
Interviewee 09: “Within the project. It is usually documented. Ide-
ally, it is discussed and then documented.”

5 | CASE STUDY ANALYSIS Planning

5.1 | Case Study A
The results of Case Study A are presented below.
5.1.1 | KS and the type of knowledge generated
Initiating
During project initiation, it is perceived that the shared knowledge
tends to be managerial in Case Study A, which confirms the results
of the interviews with the experts. In addition, the interviewees in
Case Study A responded that tacit knowledge tends to become
explicit so that the project's business objectives can be documented,
reinforcing, once again, the socialization and externalization of knowl-
edge, according to the knowledge spiral model (Nonaka & Konno,
1998). As an example of the initial documentation, one can mention
During Planning, the shared knowledge tends to be both managerial
(regarding the way the project is managed) and technical (regarding
the system requirements and technical details of the project's scope),
which confirms the result found in the analysis of the literature review
and is also consistent with the answers provided by the experts.
The literature review suggested that the knowledge shared
during Planning is explicit. However, based on Case Study A, the
sharing of tacit knowledge was also seen to occur. An example of
such tacit KS would be the planning meetings in which the discussions
depend on project team members sharing tacit knowledge, which is
called socialization, according to the knowledge spiral model (Nonaka
& Konno, 1998). The decisions resulting from these meetings are
subsequently documented, thus generating explicit knowledge,
externalization, according to the knowledge spiral model (Nonaka &
Konno, 1998). The same result was found from the interviews with
the experts.
GOMES ET AL.
It was concluded that during Planning, the shared knowledge can
be both intraproject and interproject, although the project manager
alone was in accordance with this idea, and then only if the projects
are related. The technical team believes that KS during the Planning
is specific to the project in question due to the activities carried out
(directly related to the project's scope). Therefore, it is concluded that
the fact that the knowledge may or may not be shared between pro-
ject teams is also directly linked to the functions performed by the
professionals. The PM experts responded along the same lines as the
project manager in Case Study A.
Executing
During project Execution, it was confirmed that most of shared knowl-
edge is technical, although managerial knowledge, arising from the
monitoring activities that occur during Execution, was also being
shared. The same result was found from the interviews with the
experts.
Moreover, as mentioned by all the interviewees in Case Study A,
the sharing of both tacit and explicit knowledge takes place during the
Execution of projects. An example of explicit knowledge is the techni-
cal design document, and an example of tacit knowledge is the KS ses-
sions involving members of the project teams, which are intended to
ensure that all the team members have access to the same knowledge
and conduct a peer review of the activities carried out.
Based on the literature review, it was understood that both
intraproject and interproject knowledge may originate from the exe-
cuting process group, because different projects might be related.
Nevertheless, in Case Study A, most of the knowledge shared in that
group is of the intraproject type. This finding differs from the conclu-
sion reached by the PM experts, who agreed with the findings from
the literature review. Only the developer said there was both
intrainterproject and interproject sharing, although he mentioned that
it is a practice in the teams in which he works and not a practice of the
organization as a whole. The developer claimed that sharing
intraproject and interproject knowledge benefits the quality of the
code generated in the Execution of projects, as it provides an oppor-
tunity for developers at various levels of seniority to review code.
Monitoring and Control
There is consensus between the literature and the interviewees that
the knowledge shared during Monitoring and Control is explicit in
nature, because it is directly linked to documents regarding the project
indicators. The experts believe that tacit knowledge is also being
shared during Monitoring and Control, and, once again, the authors
believe that the divergence can be explained by the nature of the
functions: PM experts work closely together in project monitoring
and control and, therefore, tend to share more knowledge, both tacitly
and explicitly, about their activities.
The literature review showed that the knowledge shared during
Monitoring and Control is managerial in nature, whereas the inter-
viewees in Case Study A reported that technical knowledge is used
as an input to managerial knowledge and that if there are risks and
technical problems to be discussed, these are reported in the Monitor-
ing and Control process group. Once again, there is divergence in rela-
tion to the responses highlighted by the experts, and again, it is
175
believed to be due to the nature of the functions (technical and man-
agerial). In addition, based on the literature review, it was seen that
the knowledge originating from the Monitoring and Control process
groups would be specific to a project. However, during Case Study
A, knowledge was also found to be shared with other projects in exec-
utive meetings, for example. This conclusion is consistent with that
reached by the experts.
Closing
During project closure, both technical and managerial knowledge are
shared, but the literature review indicated that the focus is the sharing
of managerial knowledge. Like the experts, the study interviewees in
Case Study A reported that both technical and managerial items make
up the lessons learned and both should be shared.
There is a consensus among the interviewees that the knowledge
originating from the Closure is explicit, as concluded from the litera-
ture review. The experts, however, disagree, believing that there are
debates grounded on tacit knowledge during the lessons learned
meetings. Interviewees 2 and 3 from Case Study A believe that the
knowledge shared during project closure is specific to the project itself
(technical team), whereas the project manager (Interviewee 1) believes
that the knowledge arising during the Closure can be shared with
other project teams, as suggested by the experts. It is believed that
because the project manager's perspective is more generic compared
with the technicians' more specific view, this discrepancy is again
due to the function performed by those professional. As most of the
interviewees believe that the knowledge shared during Closure is
intraproject, this is the conclusion reached.
5.1.2 | KS and the actors involved
As in the interviews with the experts, it was noticed that all the inter-
views in Case Study A are consistent with the relations proposed
based on the literature review. However, the interviews regarding
the stakeholders involved in KS in the different PMPGs from Case
Study A provided more details than the literature review.
The authors see these details as being crucial in assisting the man-
agers of organizations in the planning and allocation of human
resources (actors) in the various stages of PM. No new actors were
identified besides those mentioned during the interviews with the
experts, and therefore, there is no need to incorporate new stake-
holders to the findings of this study.
5.1.3 | KS and the technologies involved
Next, as part of Case Study A, there is an analysis of the technologies
involved in KS and the PMPGs. As seen regarding stakeholders, the
technologies involved in KS are consistent with the relations proposed
in the interviews with the experts. Based on Case Study A, there is a
need to incorporate more KS technology, the details of which are as
follows:
• Service‐Desk Tool: Tool used by the organization to manage the
changes that occur in the customer's production environment.
With this exception, all other technologies used for KS have
already been mentioned above.
176
5.2 | Case Study B
This section presents the findings from Case Study B.
5.2.1 | KS and the types of knowledge generated
During the analysis of the interviews from Case Study B, it was noted
that many relationships between KS and the PMPGs originating from
the literature review were confirmed, although some differences were
found and are detailed below.
Initiating
Case Study B, like the literature review, stressed that during project ini-
tiation, managerial knowledge is shared, which is consistent with the
results found in both Case Study A and the interviews with the experts.
However, the analysis of the literature identified that the knowledge
shared during Initiation is tacit, whereas the interviews concluded that
both tacit and explicit knowledge is shared, as KS occurs both in meet-
ings and through documentation. This result is also consistent with the
results found in both Case Study A and the interviews with the experts
and strengthens socialization and externalization, according to the
knowledge spiral model (Nonaka & Konno, 1998).
The literature review suggested that the interproject knowledge
can be shared during Initiation, because related projects might be con-
sidered, but only one of the respondents agreed with this statement
while emphasizing that such interproject sharing only occurs when
projects are similar. This result is also consistent with the results found
in both Case Study A and in the Interviews with the experts.
Planning
During project Planning, the knowledge shared is both technical and
managerial, according to the interviewees from Case Studies A and B
as well as the literature review. The analysis of the literature suggests
that during Planning, KS mainly consists sharing documentation. How-
ever, the interviewees from Case Study B reported that in addition to
explicit knowledge, there was much tacit KS (unanimity among the
interviewees: experts, Case Study A and Case Study B).
Knowledge tends to stay among the members of the project team
during Planning, although, if a similar project is identified, knowledge
may be shared between them. Therefore, it is thought that knowledge
originating from the Planning activities can be both intraproject and
interproject in nature because projects might be related and impact
each other, which means that project teams must be aligned regarding
scope, chronogram, and so forth. This response is consistent with the
literature review and the responses provided by the experts, although
it is not consistent with Case Study A (the explanation for the differ-
ence in the results from Case Study A is in the section on Planning
related to Case Study A).
Executing
During project Execution, the knowledge shared tends to be technical
for the most part. However, the project manager interviewed for Case
Study B believes that managerial knowledge is also shared during Exe-
cution, which is in accordance with the responses from the experts
and the interviewees from Case Study A. Nevertheless, the techni-
cians suggested that during Execution, most of the knowledge shared
GOMES ET AL.
is technical and, therefore, regarding Case Study B, technical knowl-
edge will be seen as being predominant during Execution (once again,
there is a difference in the responses according to the function per-
formed by each respondent).
Unanimously, the interviewees (from both Case Study A and Case
Study B) agree with the findings from the literature review in terms of
the type of knowledge shared: tacit (from discussions, workshops) and
explicit (documentation).
Like the project manager and the experts, the literature review
suggests that the knowledge originating from the Execution can be
intraproject and interproject in nature because projects might be
related, whereas the technical teams believe that knowledge shared
during Execution is closely related to the scope of the project itself
and hence intraproject. Again, the difference can best be understood
as being related to job function. This result was similar to that found
in Case Study A.
Monitoring and Control
The literature review and the Interviews with experts indicate that the
knowledge shared during the Monitoring and Control of a project
tends to be managerial. This understanding was confirmed by the
interviews from the Case Studies (A and B), but it became clear that
the managerial knowledge in Monitoring and Control is generated
from technical knowledge arising from the project activities.
Based on the literature review and the Interviewees from Case
Studies A and B, it can be concluded that during Monitoring and Con-
trol, the knowledge shared is explicit, because it is directly linked to
the project documentation. The experts believe that tacit knowledge
is also shared during Monitoring and Control and, again, this diver-
gence is probably due to the nature of the respective functions: PM
experts work more intensely in the Monitoring and Control of pro-
jects, and therefore, they tend to share more about their activities
(both tacitly and explicitly).
There is disagreement regarding the scope of this knowledge: The
literature review showed that it is intraproject knowledge (related to
project health), whereas, according to the interviewees from Case
Study B, it is interproject knowledge (because projects might be
related and this might be shared with a wider audience). One of the
respondents did not specify regarding this issue. The experts and
interviewees from Case Study A believe that both intraproject and
interproject knowledge is shared. Thus, it is believed that this knowl-
edge may be either internal or external to the project.
Closing
The interviews with the experts and with the professionals from Case
Studies A and B showed that both technical and managerial knowl-
edge form part of the project Closure activities, not just managerial
knowledge as suggested by the literature review.
It was found that both tacit and explicit knowledge is shared
(whereas the analysis of the literature review and Case Study A
focuses on explicit knowledge for documentation in the project
Closure activities). The experts also believe that both tacit and explicit
knowledge is shared.
Both intraproject and interproject knowledge can be shared dur-
ing closure, according to the literature review, the experts, and the
GOMES ET AL.
interviewees from Case Study B. They consider that the lessons
learned are a way to share interproject knowledge, whereas the tech-
nicians interviewed in Case Study A think such knowledge should only
be for the project itself.
5.2.2 | Sharing knowledge and the stakeholders
involved
As with the interviews with the experts and the interviewees in Case
Study A, all the interviewees from the Case Study B project were
found to be consistent with the relations proposed based on the liter-
ature review. However, the interviews regarding the stakeholders
involved in KS in the different PMPGs from Case Study B provided
more details than the literature review.
These details are crucial to assist managers in the planning and
allocation of human resources (stakeholders) in the various stages of
PM. In Case Study B, a new stakeholder can be incorporated into
the stakeholders list involved in KS, according to the following details:
1. Service Request Manager: a person responsible for receiving cus-
tomer demands, evaluating them and engaging the project man-
ager when necessary. When demand is not related to a project,
the Service Request Manager routes the request to the appropri-
ate sectors.
Aside from the above‐mentioned stakeholder, no new players
were identified that have not previously been mentioned.
5.2.3 | KS and the technologies involved
As noted regarding the stakeholders involved, the technologies
involved in KS are consistent with the relations proposed in the of
the literature review. During the interviews with the experts and in
Case Study A, new technologies that support the KS process were
incorporated. However, no new technologies were incorporated as a
result of Case Study B.
6 | DISCUSSION
Based on this research, it was concluded that the technologies used at
the intersection of the PMPGs and KS are similar during the entire pro-
ject life cycle, as they are considered essential in enabling the activities
necessary throughout the project. An example would be activities such
as knowledge storage (Sharepoint), or communication between project
team members (tele‐ and video‐conferencing and e‐mail). In addition,
technologies enable more efficient project control (Respondent 2)
because they provide managers with information about what is being
done by the project teams (examples of such technology are PM tools
and TFS). Hence, it is clear that once the technologies to be used during
the project have been defined, they tend to remain throughout the pro-
ject life cycle with little variation (e.g., TFS is not always used during
project Initiation or Closure, but once it starts to be used during Plan-
ning, it is also used during the Execution and Monitoring and Control
—this is an example of variation, although following the trend seen in
this research, once the technology is defined, it tends to be used at
the intersection of most the PMPGs and KS).
177
It was also concluded that different stakeholders are involved in
the PMPGs and that knowing which stakeholders are needed for each
PMPG is critical for optimizing resources and ensuring that all the nec-
essary stakeholders are properly engaged. From the project Initiation,
the project managers were seen to be concerned to engage at least
one representative of all the teams involved in order to ensure align-
ment with the project scope and the activities required. In addition,
the involvement of external stakeholders was noted in several PMPGs
such as, for example, members of the PM office and executive team
especially during the Monitoring and Control activities, which indi-
cates that project teams engage in activities related to the
organization's strategy, with each project team being responsible for
achieving its scope (i.e., operationalization of the strategy through pro-
jects), as suggested in the literature review.
Both types of knowledge (managerial and technical) are shared
during the projects, although at different intensities in the PMPGs.
In addition, knowledge is transformed (explicit to implicit, for example),
and the knowledge conversion modes can be inhibited or stimulated
to benefit the organization. Another important finding was that in
most cases, when interproject sharing occurs, it is because the pro-
jects are somehow related or interdependent, that is, the scopes are
related and, therefore, greater benefit is perceived when KS occurs.
Many discussions involving the exchange of tacit knowledge were
seen to occur in the PMPGs, and the outcome of these discussions
tends to be externalized, documented, and stored to facilitate the
recovery of that knowledge. This enables good practices identified in
one project to be applied in other projects to facilitate the work on
future projects and optimize the results.
7 | T H E O R E T I C A L A N D P RA C T I C A L
IMPLICATIONS
7.1 | Theoretical contributions
This basic research proposes a theoretical advance by linking two
major fields, KM and organizational PM, specifically in the subfields,
KS and PMPGs, respectively. We identified the types of knowledge
within each PMPG (PMBOK, 2013) and opportunities to influence
knowledge conversion (Nonaka & Konno, 1998) to enhance the results
obtained through KS in the organization. Furthermore, we identified
opportunities to share interproject knowledge that avoid rework and
optimize time and costs for organizations. This research provides a
means to determine whether the shared knowledge is technical or
managerial in nature in order to optimize communication and knowl-
edge creation. This study also adds a new stakeholder to be considered
in further research involving KS tasks and PM, the Service Request
Manager. The findings described in this paper can help stakeholders
share knowledge in similar IT project settings as, for example, this arti-
cle maps the main stakeholders working on each process group.
7.2 | Practical implications
This paper can benefit practitioners in several ways. This research con-
tributed by approximating two topics, PM and KS, through the
178
proposed relationships. Understanding the proposed relationships
between KS and PMPG allows:
• Resource allocation optimization—We identified which stake-
holders should be involved at each stage of the project (which
enables the percentage of actor allocation necessary to be
mapped and thus allocate the stakeholders to more than one pro-
ject, where possible, which tends to reduce costs).
• Identify specific tools that assist KS, so that companies can make
them available to employees and avoid communication problems
due to the lack of appropriate tools.
• Identify the type of knowledge generated in each PMPG—Regard-
ing the type of knowledge generated, we identified:
• Whether the knowledge is tacit or explicit—identifying knowledge
conversion models in each of the PMPGs provides opportunities
where it is possible, for example, to encourage combining knowl-
edge, socialization, and so forth, according to the needs of the
organizations.
• Intraproject or interproject—This means it is possible to identify
opportunities where knowledge can be shared with other project
teams, so that they save time in their daily activities or avoid
rework by using knowledge gained on other projects. A good
example of this is the lessons learned, where a lack of encourage-
ment to use lessons learned from previous projects was perceived,
as reported by one of the experts interviewed.
• Technical or management—We identified that stakeholders with a
technical and managerial background need to work more closely
together so that both types of shared knowledge are optimized.
For example, we found out that during monitoring and control, it
is of paramount importance that the technical knowledge sup-
ports the sharing of both intraproject and interproject manage-
ment knowledge, because the risks and problems should be
correctly reported. In this group of processes, the project manager
should work with the technical team to optimize the results of the
monitoring and control, because although most of shared knowl-
edge is managerial in nature, there is technical input, a factor that
must be considered, including in the allocation of resources.
Therefore, this study makes a major contribution to research on
KM and PM by demonstrating relationships between the PMPGs
and KS.
8 | C O N CL U S I O N S
The objective of this study was to analyze KS in IT PMPGs, consider-
ing three perspectives: the types of knowledge, the stakeholders, and
the ITs.
This research has some limitations. First, the proposed relation-
ships were established based only on KS, whereas other KM processes
were not considered. Following this research, we intend to explore
other KM processes. Second, several technologies that serve the same
purpose (i.e., to resolve the same business need) are available on the
market. Thus, if applied in other organizations, the technologies used
GOMES ET AL.
for KS may differ, considering that this is a constantly evolving market.
Finally, the number of interviewees can be extended in the future stud-
ies as well as the introduction of a confirmatory focus group to corrob-
orate the individual opinions. For further research, we suggest the
application of this research in small and medium‐sized companies and
in other sectors while also identifying the changes in the adopted IT.
ACKNOWLEDGEMENTS
The authors are grateful for the support provided by CAPES
(Coordenação de Aperfeiçoamento de Pessoal de Nível Superior—Brazil)
and CNPq (Conselho Nacional de Desenvolvimento Científico e
Tecnológico—Brazil).
ORCID
Mírian Oliveira http://orcid.org/0000-0002-5498-0329
Marcirio Silveira Chaves http://orcid.org/0000-0002-3554-0328
RE FE RE NC ES
Andersen, S. S., & Hanstad, D. V. (2013). Knowledge development and
transfer in a mindful project organization. International Journal of
Managing Projects in Business, 6(2), 236–250. https://doi.org/
10.1108/17538371311319007
Bardin, L. (2008). Análise de conteũdo. Lisboa: Edições 70.
Bell, L., van Waveren, C. C., & Steyn, B. H. (2016). Knowledge‐sharing
within the project‐based organization: A knowledge‐pull framework.
South African Journal of Industrial Engineering, 27(4), 18–33. https://
doi.org/10.7166/27‐4‐1580
Coakes, E. (2006). Storing and sharing knowledge: Supporting the
management of knowledge made explicit in transnational organisations.
The Learning Organization, 13(6), 579–593. https://doi.org/10.1108/
09696470610705460
Fernie, S., Green, S. D., Weller, S. J., & Newcombe, R. (2003). Knowledge
sharing: context, confusion and controversy. International Journal of
Project Management, 21(3), 177–187. https://doi.org/10.1016/S0263-
7863(02)00092-3
Goldoni, V., & Oliveira, M. (2010). Knowledge management metrics in software
development companies in Brazil. Journal of Knowledge Management,
14(2), 301–313. https://doi.org/10.1108/13673271011032427
Hooff, B. V. D., & Ridder, J. A. (2004). Knowledge sharing in context: The
influence of organizational commitment, communication climate and
CMC use on knowledge sharing. Journal of Knowledge Management,
8(6), 117–130. https://doi.org/10.1108/13673270410567675
Iebowitz, J., & Megbolugbe, I. (2003). A set of frameworks to aid the
project manager in conceptualizing and implementing knowledge
management initiatives. International Journal of Project Management,
21(3), 189–198. https://doi.org/10.1016/S0263‐7863(02)00093‐5
Janet, C. N., Wee, A., & Chua, Y. K. (2013). The peculiarities of knowledge
management processes in SMEs: The case of Singapore. Journal of
Knowledge Management, 17(6), 958–972. https://doi.org/10.1108/
JKM‐04‐2013‐0163
Koskinen, K. U., Pihlanto, P., & Vanharanta, H. (2003). Tacit knowledge
acquisition and sharing in a project work context. International Journal
of Project Management, 21(4), 281–290. https://doi.org/10.1016/
S0263‐7863(02)00030‐3
Kuo, F.‐Y., & Young, M.‐L. (2008). Predicting knowledge sharing practices
through intention: A test of competing models. Computers in Human
Behavior, 24(6), 2697–2722. https://doi.org/10.1016/j.chb.2008.03.015
Lampel, J. (2001). The core competencies of effective project execution:
The challenge of diversity. International Journal of Project Management,
19(8), 471–483. https://doi.org/10.1016/S0263‐7863(01)00042‐4
GOMES ET AL. 179

Lech, P. (2014). Managing knowledge in IT projects: A framework for
enterprise system implementation. Journal of Knowledge Management,
18(3), 551–573. https://doi.org/10.1108/JKM‐01‐2014‐0006
Malhotra, Y., & Galletta, D. F. (2002). Role of commitment and motivation
in knowledge management systems implementation: Theory, concep-
tualization, and measurement of antecedents of success. Proceedings
of the 36th Hawaii International Conference on System Sciences
(HICSS'03), Computer Society.
Motavire, R., & Brown, I. (2013). Profiling grounded theory approaches in
information systems research. European Journal of Information Systems,
22, 119–129. https://doi.org/10.1057/ejis.2011.35
Mueller, J. (2014). A specific knowledge culture: Cultural antecedents
for knowledge: Sharing between project teams. European
Management Journal, 32, 190–202. https://doi.org/10.1016/j.
emj.2013.05.006
Nesheim, T., & Hunskaar, H. M. (2015). When employees and external con-
sultants work together on projects: Challenges of knowledge sharing.
International Journal of Project Management, 33(7), 1417–1424.
https://doi.org/10.1016/j.ijproman.2015.06.010
Nonaka, I., & Konno, N. (1998). The concept of “Ba”: Building a foundation
for knowledge creation. California Management Review, 40(3), 40–54.
https://doi.org/10.2307/41165942
Oliveira, M., Maçada, A. C. G., & Curado, C. (2014). Adopting knowledge
management mechanisms: Evidence from Portuguese organizations.
Knowledge and Process Management, 21(4), 231–245. https://doi.org/
10.1002/kpm.1445
Rigby, D., & Bilodeau, B. (2015). Management tools and trends, 2015.
Available in: < http://http://www.bain.com/publications/articles/man-
agement‐tools‐and‐trends‐2015.aspx>.25mar.2016.
Sandhawalia, B. S., & Dalcher, D. (2010). Knowledge flows in software pro-
jects: An empirical investigation. Knowledge and Process Management,
17(4), 205–220. https://doi.org/10.1002/kpm.357
Todorovic, M. L., Petrovic, D. C., Mihic, M. M., Obradovic, V. L., &
Bushuyev, S. D. (2015). Project success analysis framework: A knowl-
edge‐based approach in project management. International Journal of
Knowledge Management, 33(4), 772–783. https://doi.org/10.1016/j.
ijproman.2014.10.009
Venkatesh, V., Brown, S., & Bala, H. (2013). Bridging the qualitative‐quan-
titative divide: Guidelines for conducting a mixed methods research in
information systems. MIS Quarterly, 37(1), 21–54.
Yahyapour, S., Shamizanjani, M., & Mosakhani, M. (2015). A conceptual
breakdown structure for knowledge management benefits using
meta‐synthesis method. Journal of Knowledge Management, 19(6),
1295–1309. https://doi.org/10.1108/JKM‐05‐2015‐0166
Yin, R. K. (2005). Case study: Design and methods. United States. Sage.
Zhang, L., & He, J. (2016). Critical factors affecting tacit‐knowledge
sharing within the integrated project team. Journal of Management
Engineering, 32(2), 1–10. https://doi.org/10.1061/(ASCE)ME.1943‐
5479.0000402
How to cite this article: Gomes F, Oliveira M, Chaves MS. An

PMBOK. (2013). Project management guide, Project Management Institute. analysis of the relationship between knowledge sharing and
Rhodes, L., & Dawson, R. (2013). Lessons learned from lessons learned. the project management process groups. Knowl Process Manag.
Knowledge and Process Management, 20(3), 154–160. https://doi.org/ 2018;25:168–179. https://doi.org/10.1002/kpm.1578
10.1002/kpm.1415

APPENDIX A
INTERVIEW SCRIPT
In this appendix, the interview script used in this research is presented (Table A1), with questions that allow the validation of the mapping done
based on the literature regarding the relationship between KM and the PM processes. Moreover, using this script together with document anal-
ysis, it was possible to conduct the Multiple Case Study.

TABLE A1 The Interview Script

Knowledge sharing

Knowledge sharing occurs 1) What type of knowledge is shared throughout 2) Who are the stakeholders 3) Which technologies
throughout the project project phases? involved in KS? support this process?
Tech Man Tac Exp Intra Inter Comments Comments Comments
Initiating
Planning
Execution
Monitoring and Control
Closing