The approach of organizational knowledge management is characterized by the ability of a company to create knowledge as a corporate asset and understand the need to manage it and give it the same care as that devoted to the achievement of tangible assets (Nonaka & Takeuchi, 2003).

The field of knowledge management generates increasing interest in several areas such as the project management (Kebede, 2010). This happens in the discipline of knowledge management because its processes and tools aim to increase the potential knowledge for making more assertive decisions, contributing to the competitive advantage of the organization (Kebede, 2010).

The MLL is part of knowledge management, contributing to the identification of the root cause of problems recorded and studied, an activity that helps maintain the social capital of the organization (Park & Lee, 2014). Lessons learned (LL) projects as a learning activity, in many cases, become critical for the project in the implementation of an Information System (IS) (Milton, 2010; Park & Lee, 2014).

The MLL may pose psychological challenges and individual characteristics that motivate people to share information (Jugdev & Wishart, 2014).

Swan et al. (2010) indicate that the mechanisms of high level of knowledge articulation and knowledge coding tend to be ineffective considering that projects are in their structure and nature temporary endeavors. In this sense, some scenarios can collaborate with learning in projects, dependent on senior professionals, professionals with knowledge and experience in project teams. Key people are important in enabling the transfer of learning between individuals (Kerzner, 2015; Swan et al., 2010).

Argote (2011) analyzes organizational learning considering three steps in its composition: creation, retention and transfer of knowledge. When companies learn from experience, new knowledge is created for the company. Knowledge must then be maintained so that it exhibits some persistence and validity over time (Argote, 2011). Knowledge can be transferred within and between project units. When transferring knowledge, the project is affected by experience, based on that of previous projects (Argote, 2011; Sense, 2004).

One of the most common ways to share project knowledge is to capture the positive and negative aspects of LL (Wiewiora& Murphy, 2015). Thus, when used effectively, the process can assist project managers in the reuse of knowledge and prevention of future errors and their repetition (Pemsel & Wiewiora, 2013). However, the processes of capture, storage, analysis and reuse of LL often remain underestimated (Wiewiora & Murphy, 2015). Wiewiora and Murpy (2015) argue that Web-based collaboration is easily accessible, intelligible and user-friendly, allowing the sharing of project knowledge to overcome existing problems. As a result of this study, some characteristics of these tools are highlighted in relation to LL: storage and sharing, visibility, feedback, priority, Capture mechanisms, capture tools, systemic approach and quality. Based on these authors, the LL can have a strong influence on people, groups and especially on the more experienced, inside and outside the projects.

In addition to these factors, the use of processes and tools, especially those with easy access, such as the collaborative tools of web 2.0, can help in the management of LL (Chaves, Araújo, Rosa, Gloria Jr, & Nogueira, 2016; Veronese & Chaves, 2016). These issues contribute to the objectives of the research, during the instantiation of the Target model and in the use of the wiki, with its convenience, ease of use and behavior change, contributing to the MLL.

The increasing adoption of virtual teams in IT projects contributes to the need for employee mobility and the need for collective, rapid decisionmaking by project team members in different locations (Reed & Knight, 2010). This contributes to the increase in virtual teams and the use of web 2.0 collaborative tools as support for decision making (Turban, Liang, & Wu, 2011).

Technology plays an important role, and the use of centralized systems is especially important to support collaboration (De Mattos & Laurindo, 2015). Wikis are suitable for projects with teams physically distributed in remote locations, allowing team members to organize and publish content, freeing the project manager for greater dedication to other activities (Milton, 2010).

Wikis assist project teams in defining scope, documentation, collaboration, discussion and follow-up activities. Added to these scenarios, IT projects and software quality are very dependent on the definition of the scope, the specification of tasks, communicated and understood. This scenario contributes to the assertion that wikis can be a potential solution for defining scope and tasks effectively used to promote an evolutionary mindset throughout the project (Chaves, Tessi, Winter, & Damasceno Jr., 2015; Gholami & Murugesan, 2011; Han &Anantatmula, 2007; Rosa et al, 2016).

Holtzblatt et al. (2010) conclude that the return on investment depends heavily on how the technology is adopted. For a positive effect on collaboration, the authors conclude that we should consider what prevents workers from coding and sharing knowledge. It is necessary to be aware of the work environment that users are entering, checking the possibility of sharing knowledge in various tools. Holtzblatt et al. (2010) also suggest an incentive structure, clear policies and guidelines, and support and encouragement of information sharing practices.

A wiki-based system allows you to maintain and control activities that include complete control over versions and their content. Wikis also include a history of revisions, allowing archived changes to be rolled back, and the traceability of information, which helps control inappropriate information by identifying the authors through the history. This ease of control and identification does not eliminate user mistrust regarding malicious content, posing doubts about the reliability of the wiki. Added to this, security issues should be strongly considered in building the process of using the wiki (Gholami & Murugesan, 2011; Von Krogh, 2012).

Figure 1 presents the Target model proposed by Rosa et al. (2016), which is predictive and explanatory in its processes, with support from the wiki (Rosa et al., 2016). The Target model is focused on the needs of lessons learned in projects during the phases: initiation, details (planning), implementation (execution) and closing of project life cycle.

The Verify process was added to the Collect process, and the Disseminate process was added to the Store process. This unification was created because the verification process was taken as an optional process that could be carried out at the time of collection.

The Dissemination process was included in the Store process, because it can be triggered as a notification at the time of storage. Although this process has been united with the storage, it can also occur intrinsically with the awareness process (Rosa et al., 2016).

support, and an analysis of its use. This study stimulates the effort to improve MLL through practical situations involving the subject studied. In an exploratory context with practical actions, this study is supported by a qualitative and exploratory approach. The ontology of this research is objective, related to facts and data, and hence measurable. This study creates conditions to interfere in the appearance or modification of facts in order to explain what happens with practical phenomena in an MLL environment in an IT project.

The Target model is the artifact validated in practice under the paradigm of Design Science Research (DSR) (Gregor & Hevner, 2013; Pournader, Tabassi, & Baloh, 2015). Recent debates seek to contribute to the practice through research, for example the European communities in Germany and the UK (Gregor&Hevner, 2013).

The importance of research to the practical field highlights the orientation of the DSR paradigm, emphasizing the link between the utility and the truth, "the truth lies in the utility" (Pournader et al., 2015). This view of DSR does not preclude its potential to contribute to the improvement of the theory (Cole, Purao, Rossi &Sein, 2005). In line with the paradigm, the method adopted in this work was Technical Action Research (TAR). The method supports the search for a solution to a problem using an artifact or prescription, narrowing the gap between theory and practice. While most methods of empirical research seek to study the phenomenon as it is currently, researchers using action methods (e.g. action research) seek to intervene in the situations studied (Wieringa, 2012).

A satisfactory solution, but not necessarily perfect, it is a common practice in DSR (Cole et al., 2005; Huff, Tranfield, &Aken, 2006; Lacerda, Dresch, Proenca, & Junior, 2013; Papas et al, 2012). TAR under the same platform as the Action Research method adds to the technical nature of research, which is conducted on two simultaneous and independent fronts, the practical and the theoretical (Thiollent, 2009). This research proposes a solution to a specific and empirical problem, where literature does not offer a theoretical framework, a feature found in Action Research (Patton, 2015). The steps of the study based on the method and paradigm are presented in Figure 2, deepening the study on collecting information in a software development project.

The research was carried out in two cycles. During the instantiation of the artifact, adjustments, actions and their evaluations were carried out between cycles.

In an attempt to find a solution for the customer's problem, meetings were held in order to understand the project mechanisms, MLL, the company´s characteristics, develop the wiki pages with managers, directors and all the 29 employees. Ten employees, from three distinct areas, worked directly in the research.

The interviews began forty-five days after the wiki pages were released for use and after two months of awareness and preparation work. After the first three interviews, it was possible to make adjustments, increasing awareness actions and dissemination of the work, in addition to stimulating employee participation. During the research, documents, meeting minutes, project records and processes were collected, contributing to the researcher’s analysis and observations in the field,

concluding with a confirmatory focus group, two months after the instantiation of the artifact.

The interview and focus group protocols are available in Appendix A and Appendix B.

PARTICIPANT PROFILE

Table 1 shows the classification of respondents and Table 2 their functions. Each respondent is represented by the initial "I" plus a numeric character, e.g. “I1”. The results indicate an average age of 26, 80% with bachelor's degree, and 20% with bachelor's degree in progress. Added to this scenario, 20% have completed or are completing an MBA. Most respondents, 90%, do not have schooling in projects, only one of them is attending an MBA in projects. The average IT experience of the respondents is 4 years and 3 years is the average time working in the company where the research was carried out.

The paradigm on which the research is based, DSR, gives this research an epistemological position of pragmatism, and thus leads to the pursuit of improving both the theory and practice.

The theoretical contribution lies in the practical utility (Corley &Gioia, 2011) of an LL model, which was validated in the field. In addition, this research adds new knowledge to the MLL in projects by promoting innovation in the MLL and introducing a LL model validated in the IT industry.

The use of the wiki in the research contributes to the vision of Faraj, Jarvenpaa, & Majchrzak (2011) and Von Krog (2012), as a tendency for interaction in companies, especially in innovation with the adoption of social media.

As a practical implication, the use of Target model brings as a contribution a better MLL in an IT project. It contributes to the construction of knowledge through action and experimentation, considering the social environment in which it is inserted, consisting of a group of people working on the project. In this sense, the instantiation of an LL model in an IT project using a wiki facilitated stakeholder understanding as to how useful this model is.