Proposal of a new framework for project management in a logistics department of an automotive company, applying Lean Thinking principles

October of 2019 André Miguel Rua Cruz Proposal of a new framework for Project Management in a logistics department of an automotive company, applying Lean Thinking principles Master Dissertation Integrated Master's in Industrial Management and Engineering Work done under the guidance of: Professora Doutora Anabela Pereira Tereso Professora Doutora Anabela Carvalho Alves ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii AGRADECIMENTOS Primeiro, à memória do avô Manuel, fonte de inspiração, e que foi o principal suporte nesta jornada que agora termina. À avó Fátima, pais e irmão, que sempre lutaram, fazendo os possíveis e os impossíveis por me ajudar a chegar a este momento. À Isabel pelos eternos momentos de apoio. Aos amigos. Os mais sinceros agradecimentos à minha orientadora, professora Anabela Tereso, e coorientadora, professora Anabela Alves, pelo apoio e ensinamentos neste capítulo da vida. Este projeto não poderia ser possível sem o supervisor da Bosch, Tiago Martins, mas também ao Pedro Silva, João Nuno Gonçalves e Edgar Taveira, que me apoiaram durante toda a jornada, por isso agradeço a eles pela ajuda, pelos ensinamentos e pela disponibilidade absoluta durante os meses de trabalho. Agradeço também a todos os colegas da Bosch, principalmente à equipa de estagiários do departamento, pela disponibilidade e por tornar o início da minha carreira tão interessante. iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v ABSTRACT The current master thesis was developed at Bosch Portugal Car Multimedia S.A., in Braga, with the main goal of proposing a new framework for project management in a logistics department, using Lean Thinking principles. In complex and dynamic business environments, it is important to become more effective and have more flexibility to changes. For that reason, organizations must adopt a project-based management to be increasingly competitive. This research was developed in a logistics department, which main work is sustained by innovation projects applied to the logistics. In order to maximize the project’s success, this research was carried out, whose output is a framework for the management of projects adapted to the operations of the department. To support this research the author also carried out a systematic literature review. In parallel, the author was integrated in the work environment, adopting an action research methodology to develop the framework and to eliminate the current waste associated to project management. Firstly, the diagnosing phase was performed. At this phase the current framework was analyzed and a round of semi-structured interviews with the project managers were carried out, to identify the problems. The list of identified problems was divided into several groups, but it was possible to highlight the time scheduling problem, the lack of information share between stakeholders and the inexistence of a proper deployment phase. Then, on the action planning phase, the new framework and some auxiliary documents used as standards were proposed to solve the problems identified. The final step was the implementation of the proposal, which is a cycle procedure with several improvements during the implementation. The final framework brought new activities and it is capable to adapt to the context of each specific project, minimizing waste and eliminating the problems that were identified earlier. The main results obtained were mostly related to the applicability of a new framework adapted to the department characteristics, which solved about 83% of the identified problems. KEYWORDS Project Management; Lean Thinking; Framework. vi RESUMO A presente tese de mestrado foi desenvolvida na Bosch Portugal Car Multimedia S.A., em Braga, com o objetivo principal de propor uma nova estrutura para a gestão de projetos no departamento de logística, utilizando princípios de Lean Thinking. Em ambientes de negócios complexos e dinâmicos, é importante ser cada vez mais eficaz e ter mais flexibilidade para as rápidas mudanças do mercado. Por essa razão, as organizações devem adotar uma gestão baseada em projetos com o intuito de serem cada vez mais competitivas. Esta pesquisa foi desenvolvida num departamento de logística, cujo principal trabalho é sustentado por projetos de inovação aplicados à logística. A fim de maximizar o sucesso destes projetos, esta pesquisa foi realizada, cujo resultado é uma framework para a gestão de projetos adaptada às operações do departamento. Para apoiar esta investigação, o autor realizou uma revisão sistemática da literatura. Em paralelo, o autor foi integrado no ambiente de trabalho, adotando uma metodologia de investigação-ação, para desenvolver a metodologia e eliminar os desperdícios atuais inerentes à gestão de projetos. Primeiramente, foi realizada a fase de diagnóstico. Nesta fase, o estado atual foi analisado e foi realizada uma ronda de entrevistas semiestruturadas com os líderes de projetos, para identificar os problemas. A lista de problemas identificados foi dividida em vários grupos, mas foi possível destacar o problema de cumprimento da calendarização, a falta de partilha de informações entre os interessados e a inexistência de uma fase de implementação adequada. Em seguida, na fase de planeamento de ações, a nova metodologia e alguns documentos auxiliares utilizados como padrão foram propostos para solucionar os problemas identificados. A etapa final foi a implementação da proposta, que é um procedimento em ciclo com várias melhorias durante a implementação. A metodologia final introduziu novas atividades e é capaz de se adaptar ao contexto de cada projeto específico, minimizando o desperdício e eliminando os problemas que foram identificados anteriormente. Os principais resultados obtidos relacionaram-se essencialmente com aplicabilidade da nova metodologia para as características do departamento, que resolveu cerca de 83% dos problemas identificados. PALAVRAS-CHAVE Gestão de Projetos; Pensamento Lean; Framework. vii TABLE OF CONTENTS Agradecimentos ........................................................................................................................ iii Abstract ...................................................................................................................................... v Resumo ...................................................................................................................................... vi Table of contents ...................................................................................................................... vii Figure index ................................................................................................................................ x Table index ............................................................................................................................... xii List of Abbreviations and Acronyms ......................................................................................... xiii 1. Introduction ........................................................................................................................ 1 1.1 Context and motivation ............................................................................................... 1 1.2 Objetives ...................................................................................................................... 3 1.3 Research methodologies ............................................................................................. 3 1.3.1 Systematic Literature Review ............................................................................... 4 1.3.2 Action Research Methodology ........................................................................... 11 1.4 Structure of the document ........................................................................................ 14 2. Systematic Literature Review ........................................................................................... 15 2.1 Theoretical background ............................................................................................. 15 2.1.1 Project Management .......................................................................................... 15 2.1.2 Lean Production ................................................................................................. 24 2.1.3 Lean Project Management ................................................................................. 30 2.1.4 Agile Methodologies .......................................................................................... 31 2.1.5 Hybrid Methodologies ........................................................................................ 33 2.2 Critical analysis and discussion .................................................................................. 34 2.2.1 What is the relation between Lean Thinking and Project Management? ......... 34 2.2.2 What project management methodologies were found on this research? ...... 36 3. Company Presentation ..................................................................................................... 40 3.1 Bosch group ............................................................................................................... 40 3.2 Business areas and divisions ...................................................................................... 40 viii 3.3 Bosch Car Multimedia ............................................................................................... 41 3.4 Bosch in Portugal ....................................................................................................... 42 3.5 Bosch divisions Braga ................................................................................................ 42 4. Description and Critical Analysis of CM/LOI Current Situation ........................................ 44 4.1 Logistics Department operation ................................................................................ 44 4.2 Diagnosis and main problems ................................................................................... 46 4.3 Process mapping ........................................................................................................ 46 4.4 Problems identification ............................................................................................. 48 4.4.1 Procedure for problems identification ............................................................... 48 4.4.2 Framework problems ......................................................................................... 49 4.4.3 Project management problems.......................................................................... 50 4.5 Agility Assessment ..................................................................................................... 54 4.5.1 Suitability assessment chart - Strategy .............................................................. 55 4.5.2 Suitability assessment chart - Creation .............................................................. 55 4.5.3 Suitability assessment chart - Results ................................................................ 57 4.5.4 Group A - Software development results and conclusions ................................ 58 4.5.5 Group B - Implementation results and conclusions ........................................... 60 4.6 Diagnosing phase conclusions ................................................................................... 62 5. Proposal Presentation ....................................................................................................... 63 5.1 Initial considerations ................................................................................................. 63 5.2 Project Management Business Strategy .................................................................... 66 5.3 Framework structure ................................................................................................. 67 5.4 Framework phases..................................................................................................... 69 5.4.1 Project Management Strategy ........................................................................... 69 5.4.2 Enter Phase ......................................................................................................... 69 5.4.3 Initiation Phase ................................................................................................... 69 5.4.4 Planning .............................................................................................................. 77 5.4.5 Execution, Monitoring and Controlling phase ................................................... 79 5.4.6 Closing ................................................................................................................ 86 5.4.7 Framework Milestones ....................................................................................... 87 ix 5.5 Proposal chapter conclusions .................................................................................... 88 6. Results Analysis ................................................................................................................. 90 6.1 Instill project management processes (Management) ............................................. 90 6.2 Improve the planning of workloads for team members or stakeholders (Method/Measurement) ...................................................................................................... 91 6.3 Use of the same standards among all the projects (Materials) ................................ 92 6.4 Improve and define the roles and responsibilities for project management (Man) 92 6.5 Improve the overall quality of the projects (Environment) ...................................... 93 6.6 Synthesis of the main results ..................................................................................... 93 7. Conclusion ......................................................................................................................... 95 7.1 Final Considerations .................................................................................................. 95 7.2 Future Work ............................................................................................................... 96 References ................................................................................................................................ 97 Appendix 1 – Database Table ................................................................................................. 104 Appendix 2 – Old Framework ................................................................................................. 107 Appendix 3 – Interviews Template......................................................................................... 109 3 management is implemented in the organization but varies in its details by organizational units. Each function has an individual approach regarding process, glossary, training, and project management organization, so tailoring concerns were taken into consideration. 1.2 Objetives The main objective of this research was to propose a new framework for project management, applying Lean Thinking principles in a logistics department of Bosch Car Multimedia. In order to achieve this main objective, it was necessary to: ▪ Identify all past and undergoing processes for project management; ▪ Map these processes; ▪ Develop a standardized framework for project management processes; ▪ Implement the framework for ongoing and for future projects. With the accomplishment of the main objective, it was expected to: ▪ Instill project management processes; ▪ Improve the planning of workloads for team members or stakeholders; ▪ Reduce time wastes on the development of projects; ▪ Improve the scope output, budget traceability and schedule planning on each project; ▪ Improve the overall quality of the projects; ▪ Define the roles and responsibilities for project management; ▪ Use of the same standards among all the projects. 1.3 Research methodologies This section presents the two different methodologies of research that were used. The first one is the procedure that is behind the process of construction of the Systematic Literature Review (SLR). Oates and Capper (2009) say that a SLR aims to provide an explicit, rigorous, reproducible, and auditable process for evaluating and interpreting all available research, relating to a particular research question, topic, area, or phenomenon of interest. It is for this reason that a systematic literature review was conducted (see chapter 2). The other one is 4 about the main point of the study called the Action Research Methodology, in which all the steps are described in order to achieve the main goals of the thesis. 1.3.1 Systematic Literature Review To support the research developed in this master dissertation it was decided to undertake a Systematic Literature Review (SLR) about project management methodologies and related topics. With this, the author intended to deepen the knowledge about this topic. At the same time, the author wanted to highlight important methodologies that could help in the design of the methodology developed in this dissertation. The main findings, conclusions and discussions of the SLR of this specific study are presented in section 2.2. The SLR development aspects, as well as the research questions that guided the study, are presented in this section. The literature review consists of a theoretical background on which the main topics are presented separately and the critical analysis and discussion relating the main topics. As so, a SLR is a form of secondary study that uses a well-defined methodology to identify, analyze and interpret all available evidence related to a specific research question (Nurdiani, Börstler, & Fricker, 2016). The SLR methodology that was used consists on a three-step procedure for data collection, choice criteria and data selection, to provide whatever is necessary to achieve the main goal of this research. This three-step procedure consists of: 1. Defining the appropriate research questions: The process began with the choice of the literature field, which was targeted for this research. Since the scope was defined, the next action was the choice of adequate research questions. This was one of the most important steps, insofar as these questions act as success criteria for the screening that happened further ahead; 2. Defining appropriate search terms: Firstly, it was important to assure the inexistence of studies of this kind, for the same scope. Then a keyword assembly structure that aims to accommodate a broad range of search terms was defined; 3. Process of screening and data selection: Using the success criteria, the last step consist in successive rounds of screening until the list of articles is complete. In the end, a statistical analysis was also done. 5 These three steps, as well as the sub-tasks of each, are described in a process diagram format (Figure 1). Figure 1 - Systematic Literature Review procedure 1.3.2.1 Research question According to Tranfield et al. (2003) a SLR aims to map and evaluate the body of literature and identify potential research gaps highlighting the boundaries of knowledge. Hence, a set of research questions was defined to assess the state of art on the topic of the project management - traditional and agile approaches - applying Lean Thinking principles: 1. What is the relation between Lean Thinking and Project Management? 2. What project management methodologies were found on this research? The research questions presented above have a strong relationship with the exclusion criteria, which is responsible for the process and of scanning the papers. 6 1.3.2.2 Previous literature reviews on the theme Although it is common to find these types of studies, at the time of this research there was no SLR specifically within the scope of this study. It is important to say that uncountable SLR´s about the addressed themes like “project management” or “agile methodologies” were found, however the scope of them was always different from this one. 1.3.2.3 Keyword search and scope definition The search terms were built in a multi-level keyword assembly structure that aims to accommodate a wide range of search terms and fields. This search was inspired on the PICOC structure (Population, Intervention, Context, Outcome and Comparison) as recommended by Schultz and Schultz (2014). The PICOC structure served as base for some fields of the keyword assembly, namely the Population, Intervention and Context. The main level called “Population” defines the search context (Project management), the second layer of the search is divided in three different areas named as “context 1, 2 and 3”. The purpose of the context is to allow a deep search on important areas that are attached to the search context. The final level was inspired in Silva et al. (2010), and it is the “Intervention” terms of research. The result of this process is in Table 1. Table 1 - Research Keywords Population Project Management Main Field Context 1Lean (lean OR "Process improv*" OR "Continuous improvement" OR kaizen OR kanban OR jit OR "5S " OR jidoka OR standardization OR heijunka OR pul l OR "Visual system" OR triz OR "six sigma" OR "Lean green" OR "Lean green" OR tpm OR smed OR levelling OR leveling OR "Simultaneous lean" OR tqm OR "Lean manag*") Keywords to cover the Lean thinking field Context 2 - Agile (agile OR agility OR scrum OR " XP" OR "extreme programming" OR FDD OR "feature-driven development" OR "feature-driven" OR "Dynamic Systems Development Method" OR DSDM OR "Adaptive Software Development" OR "ASD" OR "Crystal and Rational Unified Process" OR "RUP" OR TDD OR " test-driven development" OR "testdriven") Keywords to cover the Agile field Context 3 - PM fields ("Cost manag*"OR "Quality manag*"OR "Risk manag*" OR "Procurement manag*" OR "Stakeholder* manag*") Keywords to cover the field 7 Another important aspect is the definition of the logic operators, which is important to define the scope of the research. Specifically, the logic behind this study is “Population AND (Context 1 OR Context 2 OR Context 3) AND Intervention” as it is possible to see in Figure 2. 1.3.2.4 Database output The following step is the choice of filters for the keywords, otherwise the number of results of the research would not be reasonable. The first research had as output 3511 papers. Therefore, the research that was conducted in the Scopus database was made with the keywords presented in Table 1, but using the “title, abstract” search, for articles from journals, that are written in English and with a time restriction (1st January 2000 to 28th January 2019). This reduced the raw data to 1085 papers, which served as base for the literature analysis. The filtering procedure that was used has four different and intercalated main steps. From the moment that the first sample, with 1085 papers, was in an excel file, the reviewing Intervention terms - (model* OR process* OR framework* OR method* OR technique* OR methodolog* OR t ool* OR program* OR system* OR practice* OR ad option OR tailor* OR "Case stud*") Intervention words Figure 2 - Literature scope 8 methodology begun. The first step was to verify if there was any repeated paper. From that sample, it was necessary to read the abstracts of the papers and exclude the ones that fulfilled the exclusion criteria. The exclusion criteria follow the same line of thinking of the research questions. The articles that apparently seemed to answer at least one of the questions, or even bring something innovative to the field of project management frameworks, were considered. At this time, the sample had 151 papers. Every article on that list of 151 was read, allowing to understand which articles had passed wrongly through the screening phase. Then, 80 articles had something relevant to add on the research, however, at the end, only 30 were selected for the discussion of the topics. The contribution of each one of the articles is in appendix 1. Managed by Elsevier publishing, Scopus is the largest abstract and citation database of peerreviewed research literature in the fields of science, technology, medicine, social sciences, and arts and humanities. It covers over 20,000 peer-reviewed journals including those published by Elsevier, Emerald, Informs, Taylor and Francis, Springer and Inderscience. The Scopus coverage details include access to tens of millions of peer re-viewed journal. The Scopus database is more comprehensive than the Web-of-Science database, which would include only ISI indexed journals, limited to 12,000 titles only. Since we are focusing on peer-reviewed journals, we found that the Scopus database would capture the most reputable international journals, some of which may be relatively new, but influential. For this reason, it was the only research database used. 9 The PRISMA methodology (Preferred Reporting Items for Systematic Reviews and MetaAnalysis) described in Moher et al. (2009) served as base to what was described above. In Figure 3 it is possible to identify the procedure. Figure 3 - Prisma Methodology 10 1.3.2.5 Bibliometric Analysis A keywords-based bibliometric analysis on both the initial (1085 papers) and final (80 papers) samples were performed to better understand what keywords were used on this search. The bibliometric analysis performed to the initial sample reveals that the main keyword by far is “project management”, however, the remaining keywords cover a wide range, which demonstrates the heterogeneity of the search area. On the other hand, the analysis of the final sample gives an idea that the most important keywords previously found are the same at the end of the search, enabling the validation of the content analysis performed in order to refine the initial sample of 1085 (Figure 4) papers into 80 papers (Figure 5). Figure 4 - Bibliometric analysis 1 11 1.3.2 Action Research Methodology Most research textbooks represent research as a multi-stage process that a researcher must follow in order to undertake and complete a research project. The precise number of stages varies, but they usually include formulating and clarifying a topic, reviewing the literature, designing the research, collecting data, analyzing data and writing up (Saunders, Lewis, & Thornhill, 2017). The research philosophy is related to the development and the nature of the knowledge. The research philosophy that is going to be used is the pragmatism. Pragmatism is a philosophy where either or both observable phenomena and subjective meanings can provide acceptable knowledge, dependent upon the research (Saunders, Lewis, & Thornhill, 2009). Figure 5 - Bibliometric Analysis 2 12 Deductive approach can be explained by the means of hypotheses, which can be derived from the propositions of the theory. In other words, deductive approach is concerned with deducting conclusions from premises or propositions. It has been stated that deductive means reasoning from the general to the particular. The research strategy used was the action research. Action research is a disciplined process of inquiry conducted by and for those taking the action. Action research combines theory and practice through change and reflection, in an immediate problematic situation, within a mutually acceptable ethical framework. Action research is an iterative process involving researchers and practitioners acting together on a particular cycle of activities, including problem diagnosis, action intervention, and reflective learning (Avison, Lau, Myers, & Nielsen, 1999). In action research, the researcher wants to try out a theory with practitioners in real situations, gain feedback from this experience, modifying the theory as a result of this feedback, and trying it again (Avison et al., 1999). Figure 6 - Action Research Methodology Based on O’Brien (1998) 19 ▪ Project Scope Management - includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. ▪ Project Schedule Management - includes the processes required to manage the timely completion of the project. ▪ Project Cost Management - includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs, so the project can be completed within the approved budget. ▪ Project Quality Management - includes the processes for incorporating the organization’s quality policy regarding planning, managing, and controlling project and product quality requirements, in order to meet stakeholders’ expectations. ▪ Project Resource Management - includes the processes to identify, acquire, and manage the resources needed for the successful completion of the project. ▪ Project Communications Management - includes the processes required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and ultimate disposition of project information. ▪ Project Risk Management - includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project. ▪ Project Procurement Management - includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team. ▪ Project Stakeholder Management - includes the processes required to identify the people, groups, or organizations that could affect or be affected by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution. A summary of the project management process groups and its connection with the knowledge areas is represented in Table 2. 20 Table 2 - Project Management Process Group and knowledge Area Mapping (PMI, 2017) 21 2.1.1.3. Strategies Project management is a field with great support of published knowledge, and the number of methodologies, due to the nature and scope of each project, is tremendously high. However, those methodologies are based on different project management strategies. Wysocki (2006) defined as project landscape variables the complexity and the uncertainty. These two variables are the foundation that lead to the development of the strategies that are going to be presented next. ▪ Linear strategy Until the early 1990s this was the overwhelming choice of software developers. A Linear strategy is a traditional strategy that consists of dependent, sequential phases that are executed with no feedback loops. The project solution is not released until the final phase (Fernandez, Daniel & Fernandez, John, 2009). A more traditional approach, with the bulk of planning occurring upfront, then executing in a single pass, a sequential process (Project Management Institute, 2017) (Figure 10). Figure 10 - Linear Strategy (Wysocki, 2006) ▪ Incremental Strategy An Incremental strategy consists in a number of dependent phases that are repeated in sequential order. Incremental approaches must meet the same requirements as linear approaches. The goal and the solution must be clearly defined and the approach is chosen so that results can be delivered in stages over the life of the project (Wysocki, 2009). The goal and solution must be clearly defined and documented as a condition for using the models like the Staged Delivery Waterfall model, and the Feature-Driven Development model. These are two examples of incremental approaches and both models require the complete documentation of requirements, functionality and features. It is an approach that provides finished deliverables that the customer may be able to use immediately (Figure 11). 22 Figure 11 - Incremental Strategy (Wysocki, 2006) ▪ Iterative strategy It has a number of phases that are repeated in groups with a feedback loop after each group is completed. The Iterative strategy is a learn-by-doing strategy that uses intermediate solutions as a pathway to discover the details of the complete solution (Fernandez, Daniel & Fernandez, John, 2009). The most known iterative approaches are the Evolutionary Development Waterfall model, the SCRUM methodology, the Rational Unified Process (RUP) and the Dynamic Systems Development Method (DSDM) (Wysocki, 2006). Iterative life cycles improve the product or result through successive prototypes or proofs of concept. Each new prototype yields new stakeholder feedback and team insights. Then, the team incorporates the new information by repeating one or more project activities in the next cycle. Teams may use time boxing on a given iteration for a few weeks, gather insights, and then rework the activity based on those insights. In that way, iterations help identify and reduce uncertainty in the project (Project Management Institute, 2017) (Figure 12). Figure 12 - Iterative Strategy (Wysocki, 2006) ▪ Adaptive strategy An Adaptive strategy is similar to an Iterative strategy except that with an Adaptive strategy each iteration's feedback adjusts the next iteration so that a solution will be converged upon. An iteration can release a partial solution at the discretion of the customer (Fernandez, Daniel & Fernandez, John, 2009) (Figure 13). 23 Figure 13 - Adaptive Strategy (Wysocki, 2006) ▪ Extreme strategy An Extreme strategy is similar to an Adaptive strategy except that instead of adjusting with each iteration to converge upon a solution, the goal of the project must also be discovered and converged upon. The lack of goal clarity is the main difference between the Adaptive and Extreme strategies. This type of project goal uncertainty is also referred to as "chaos" since "often the project ends up with final results that are completely different from the project's original intent" (De Meyer, Loch, & Pich, 2002) as cited in (Fernandez, Daniel & Fernandez, John, 2009) (Figure 14). Figure 14 - Exteme Strategy (Wysocki, 2006) 24 Figure 15 outlines the way that the different strategies interact with the variables of the uncertainty and the complexity. According to Fernandez, Daniel and Fernandez, John (2009) and from an agile project management classification perspective, the Iterative, Adaptive, and Extreme strategies fall under the agile project management umbrella (section 2.1.3). 2.1.2 Lean Production This section presents a briefly introduction to Lean and its origin. In addition, Toyota Production System (TPS), and Lean Thinking principles are presented. Next, waste types and symptoms of waste are described. 2.1.2.1. The origin of Lean Production According to Womack, Jones, & Roos (1990) , the word "Lean" represents a system that requires fewer inputs in order to create the same results as traditional mass production systems, while offering a wider range of products to the final customer. The term Lean Production may have different designations such as just-in-time manufacturing, synchronous manufacturing, world class manufacturing, or continuous flow. The appearance of the Lean Production methodology is associated with the Toyota Motor Company. Lean Production is a management philosophy that implies "doing more with less", which means less effort, less space, less investment and fewer hours of new product development, which will require less time to be produced(Womack & Jones, 1996). It was the Figure 15 - The contemporary software development landscape (Wysocki, 2006) 25 term then used to define this new system of production much more efficient, agile, flexible and innovative than the mass production (Ohno, 1988). In the mid-1950s, Taiichi Ohno and Toyota Motor Company engineers traveled to America to learn the concepts of "Mass Production" that Henry Ford would have implemented. During this time, they realized that Henry Ford's system was not ideal for what they intended. Although they were able to produce large quantities at low cost, there was no productive flexibility, thus exposing themselves to market variations. Taiichi Ohno and his engineers brought the concepts of the production line, but they had to think how to adapt to their reality: small quantities, productive flexibility and continuous production flow. This passage was a turning point in the history of Toyota Motor Company as well as in the history of industrial evolution. Taiichi Ohno founded the TPS - Toyota Production System. TPS has 14 different principles (Liker, 2004), which are going to be presented next: ▪ Principle 1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals. It means that it is important to generate value for the customer, society, and the economy it is your starting point. ▪ Principle 2. Create continuous process flow to bring problems to the surface. Make flow evident throughout your organizational culture. ▪ Principle 3. Use pull systems to avoid overproduction. It is important to provide a downline customer in the production process with what they want, when they want it, and in the amount they want. ▪ Principle 4. Level out the workload (heijunka). Eliminating waste is just one-third of the equation for making lean successful. Eliminating overburden to people and equipment and eliminating unevenness in the production schedule are just as important, yet, generally, not understood at companies attempting to implement lean principles. ▪ Principle 5. Build a culture of stopping to fix problems, to get quality right the first time. Quality for the customer drives the value proposition. ▪ Principle 6. Standardized tasks are the foundation for continuous improvement and employee empowerment. 26 ▪ Principle 7. Use visual control so no problems are hidden. It is important to use simple visual indicators to help people determine immediately whether they are in a standard condition or deviating from it. ▪ Principle 8. Use only reliable, thoroughly tested technology that serves your people and processes. ▪ Principle 9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. ▪ Principle 10. Develop exceptional people and teams who follow your company´s philosophy. ▪ Principle 11. Respect your extended network of partners and suppliers by challenging them and helping them improve. ▪ Principle 12. Go and see for yourself to thoroughly understand the situation (genchi genbutsu). ▪ Principle 13. Make decisions slowly by consensus, thoroughly considering all options. ▪ Principle 14. Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen). These fourteen principles work as guidelines to become a real lean culture. Through the execution of these principles, companies can present results as the form of higher productivity, higher flexibility of the productive system, lower unit costs and superior quality (Black & Steve, 2003). 27 2.1.2.2. TPS House TPS is, for Liker (2004), something that surpasses an isolated set of Lean tools, presenting it as a production system in which all parties contribute to a common goal: better quality, reduction of costs, reduction of lead times, better safety and a better state of mind. Figure 16 represents the way that the author identified to represent the principles, values and culture that underpin the Lean philosophy. The objectives of the TPS philosophy are described on the roof. It is based on two fundamental pillars: ▪ Just in Time (JIT) – the production system where the right quantities are produced at the right time. This system comes with the need to adjust the pace of the processes to the needs of customers, based on Takt-time, ensuring continuous flow (Ohno, 1988). ▪ Jidoka or "Autonomation" - Jidoka symbolizes the quality at the source making visible the problems for the search for continuous improvement (Shingo, 1989). In the central area of the house concepts such as the reduction of waste and the involvement of employees always focusing on the search for continuous improvement are visible. Ohno Figure 16 - TPS House Liker (2004) 28 (1988) also added the concept Kaizen, which in Japanese means change for the better, a philosophy that aims the continuous improvement of all production processes as well as the motivation and integration of employees in the search of beneficial results for the company. The foundation of the house consists of well-defined, stable and standardized processes, level production (Heijunka) and a high use of Visual Management and knowledge of Toyota philosophy. 2.1.2.3. Lean Thinking After the success of the best-seller book from Womack, Jones, & Roos (1990), these authors received many requests from companies that want to know how to implement Lean production. To respond to these requests Womack e Jones (1996) published a second book named Lean Thinking, with the principles for companies to follow in order to implement Lean. They started calling the philosophy behind the system: Lean Thinking (Wilson, 1997). Lean Thinking is the antidote to waste. It is a philosophy to achieve more with less (Jalali et al., 2016). This philosophy has five principles which are: ▪ Identification of value – means that value is always defined by the customer’s needs for a specific product. Only the ultimate customer can define value. It specifies the important requirements or expectations that must be met (Womack & Jones, 1996); ▪ Value stream – it is the mapping of all activities that identifies all the actions that take a product or service through any process, distinguishing the value-added activities from the non-value added; ▪ Flow – this step is made to be sure the remaining steps flow smoothly with no interruptions, delays, or bottlenecks; ▪ Pull production – it is deeply connected to the production, where the costumers pull the products, preventing the increase of stocks; ▪ Pursuit perfection – it is perhaps the most important, making Lean Thinking and process improvement part of a corporate culture. 2.1.2.4. Waste Types The reduction of waste is one of the premises of the TPS house. Waste is referred to as any activity that does not add value to the end customer and that he is not willing to pay (Ohno, 35 Although, Demir et al. (2013) proposed a framework which should allow Project Management, Lean and Agile methodologies being merged into one unit. On its way, the main evidence is the creation of Lean Software Development (Poppendieck et al., 2003), referred in section 2.1.3. In the other hand, the evidences of interactions of Agile Methodologies and Lean are in a higher number, which Lean software development is the main methodology within these two fields. The advocates of Lean or Agile argue that current Project Management theory is obsolete in today’s dynamic and globalized projects (Koskela, L., & Howell, 2002) as cited in (Demir et al., 2013). Agile was mainly a reaction against the document heavy, plan driven software development approaches that were frequently not successful. Lean ideas helped provide a context and specific tools for the development of Agile (Middleton & Joyce, 2012), despite the fact that, the Agile Manifesto, which was produced in 2001 contains no references to Lean. As examples of this interaction, it is possible to found that Scrumban which was derived from Kanban. The scrum itself is similar to Toyota’s small work groups with their daily stand-up meetings (Middleton & Joyce, 2012). There are some frameworks that can interconnect these two topics in the literature, for example, the Leagile approach as suggested by Naylor, Naim, and Berry (1999) as cited in Demir et al. (2013). Leagile also combines Agile and Lean through, using the decoupling point model, where a switch from one paradigm into the other takes place sequentially (Naylor et al., 1999)(Naylor et al., 1999;Taylor, Mason-jones, Naylor, and Denis, 2010; Goldshy & Griftis, 2006). There are also the AgiLean PM (Demir et al., 2013) that eliminates waste in the processes allowing these to react to change. There are other frameworks indirectly attached to Lean, namely the Lean Six Sigma approaches. It is impossible to mention the connection of Lean Thinking and Project Management without mention Lean Project Management (Moujib, 2007). The methodology has obvious origin on the application of Lean Thinking principles to the management of projects. The major objective is on improving processes and reducing waste. Also, Lean management helps to improve efficiency and effectiveness of a project team. Lean project management aims at eliminating waste of time and resources as one of the aspects of overall improvement (Stepanov, 2018). A Project Management Institute conference paper by Aziz Moujib (2007) describes Lean project management as the application of Lean manufacturing principles to 36 the project management process. This is to achieve the same goal: maximizing value while minimizing waste. In section 2.1.3 is explained the Lean Project Management toolbox that Moujib (2007) described. Like it was possible to thought on the first times of this philosophy, Lean production works in controlled situations and processes that repeat over the time. Well, a project does not fit in this model of repetitiveness, it is all about uncertainty most of the times. However, all the philosophy that is on the base of the Lean can be applied to the management of projects, since it is possible to apply Lean Thinking principles in every context. To conclude, it is possible to understand that, even though Lean production is a field with credits signed in the literature, alignment with Project Management can be controversial for and generate distinct opinions among the researchers. 2.2.2 What project management methodologies were found on this research? The main goal of this section is to give an overview about what was found on the literature (within the scope of the SLR) about project management methodologies. From an end user view, this research will enumerate a list of methodologies and practices as well as different perspectives and visions of the field. The scholars of the area of project management enunciated over the years a kind of agility spectrum for project management methodologies, where it is possible to identify two different areas on the end of each side of it. The plan-driven methodologies/traditional/heavy weight, from one side and the Features-driven methodologies/agile in the other. Above, the definitions about these are presented, just like some examples of the different methodologies and practices of each. Nonetheless, it is important to point out a relatively recent wave that can consider itself as standing somewhere between the two types of methodologies in the spectrum, the called Hybrid methods, which are mainly methods that have characteristics of both the types. There is a recent consensus among scholars that agility is a way of coping with external and internal changes, which are viewed as unpredictable and uncertain (Dyck and Majchrzak 2012). Many studies have shown that a majority of the projects exceed their initial costs and deadlines or even remain incomplete. The question is: Why a majority of the projects fail? There is no a common answer. What is certain is that the causes of project failure are many. 37 Of course, to avoid the failure of a project it is desirable that project plans are aimed at being flexible and to allow changes even late in the process (Petrillo, Di Bona, Forcina, & Silvestri, 2018). Some authors as Utterback, Meyer, Tuff, and Richardson (2016) defend that traditional project management approaches can be counter-productive. According to Wysocki’s (2009) cited in (Dyck and Majchrzak 2012) testimonial data gathered from 10,000 project managers, no more than 20 per cent of all projects have the characteristics of traditional projects, but research shows project managers continue to apply these traditional methods to projects for which they are not suited. Despite this vision, traditional Project management cannot be taken apart, being an important guide to a wide range of industries. According to Ahimbisibwe, Cavana, and Daellenbach (2015) Traditional plan-based approaches encompass PRINCE2 (Office of Government Commerce 2009) and PMI (PMBOK, 2013). Other authors like Rehacek (2017) adds ISO 21500 and IPMA ICB as global standards, each one, with a set of contract-driven methodologies that seek adherence to a pre-established plan, as well as presumed certainty, stability, and ease of targeting/controlling existing processes (Dyck and Majchrzak 2012). In addition to what was said before, and as one of the conclusions of this research it is possible to point out that, in some cases, big companies opt to develop their own project management methodologies. These methodologies are, most of the times, based on the methodologies presented before, however, they appeared on the scope of this research. The most important frameworks that were found were the RUP (Rational Unified Process) deployment project published by the Rational Software Cooperation (acquired by the IBM later) (Hewagamage & Hewagamage, 2011) the MSF (Microsoft Solution Framework), the Project Methodology (ITPM), Personal Software Process (PSP), Team Software Process (TSP), and LFA. It is now time to look at the examples of methodologies that were found on this research, regarding to agile approaches. Like was said before, the name agile born from a reunion of project managers, each one of them with their own methodology. They were: Scrum (Ken Schwaber; Mike Beedle, 2001), Lean Software Development (Poppendieck et al., 2003), Crystal Methodologies (Cockburn, 2004), Feature Driven Development (FDD) (Palmer, S. and Felsing 2002), Adaptive Software Development (James Highsmith, 2000), Dynamic System 38 Development Method (DSDM) (Stapleton, 1997), and Extreme Programming (XP) (Kent Beck and Fowler, 2000). The advantages of agile project management and particularly the Scrum-based approach is its simplicity (Cervone, 2014). Scrum is a method of agile development and it is an iterative, incremental framework for development. It puts emphasis on the cross-functional teams working in short development bursts called “Sprints” to regularly produce a complete increment of a product (Anwar, Hafeez, Asghar, Shabbir Hassan, & Hamid, 2014). Extreme Programming is a software development methodology which does not rely on any particular tool, but rather is based on the common understanding of fundamental values and on a disciplined application of best practices (Angioni et al., 2006). The central idea of planning in XP is to plan features to implement rather than the development tasks necessary to implement these features (Van Valkenhoef, Tervonen, De Brock, & Postmus, 2011). These methodologies are highly used nowadays, mainly in software development projects, and are frameworks adapted by contexts with a high degree of agility. Other methodologies and frameworks have been created throughout the times, with more or less agility, normally adapted to the context and needs of the users. The examples that were found were the Kanban, Dev Ops, Scrumban, Leagile (Demir et al., 2013), Agile UP, Safe, Less, DAD, CMMI, IVPM2 Iterative and Visual Project Management Method and TOC/CCPM (Goldrat, 1997). CCPM is an emerging scheduling method that relies on buffers for protecting schedules from overruns and requires resource leveling to develop feasible and competitive schedules (Gu, Li, Ma, Ai, & Wang, 2014). Critical Chain Project Management (CCPM) was developed on the foundations of TOC (Theory of constrains) (Trojanowska & Dostatni, 2017). Beyond this list, it were also found other methodologies, which were referred, but there is not sufficient information to understand their agility like CH2MHill, Nasa Systems, Rapid application development, ITIL and Iconix. The newest member of the equation is this hybrid field however, it seems that it is still a little confusing for the managers. The project management research community should further investigate how to develop “hybrid” management models, considering Agile Project Methodologies and traditional approaches, in order to balance the “agility” (Conforto et al., 2014). F. Tripp and Armstrong (2018), refer that some studies have looked at the integration of these “hybrid” approaches, such as product line engineering, plan-based requirements 39 prioritization, documentation driven methodologies, lean methodologies, service-oriented methodologies and most recently capability maturity, but without the effectiveness that is expected. The words Wagile and Agifall are other ones that are new to project management vocabulary, and they signify whether the approach leans more towards waterfall or agile. Agifall introduces more robust stages of research, strategy and planning phases into tasks and proceeds with sprints to complete them. So, it’s basically an agile project with more information up front. Interestingly, the term Wagile has a negative connotation. It implies that some agile practices have been adopted but the project has been slipping back into waterfall. Such badly managed agile can transform eight 2-week sprints into a series of eight-time boxed waterfalls. Basically, wagile is thought of as waterfall masquerading as agile through daily standups and short iterations, but without principally stepping away from the traditional model. For now, it may be difficult to find a simple explanation for these approaches, however, the author suggest that the use of a hybrid framework can be built after an intensive study of the needs and characteristics of the environment in question. To conclude it is possible to say plan first, execute second because this is the paradigm of traditional project management. Adapt to change as you iterate - this is the paradigm of agile project management. These competing methodologies represent two ends of a spectrum between linear (traditional) and non-linear (agile) project management processes (Baird & Riggins, 2012). More important than the name of the methodology, it is important to understand the context before the implementation of a new way of managing the projects. If it is right to say that there is no need to invent the wheel, it is also true that each case is different, hence, it is required a diagnostic study with diagnostic tools (Agile suitability assessment charts, semistructured interviews and so on) to implement a new framework, and this is the main conclusion that is possible to take from this research. Since the context is identified, this research brings the user a rich database for the existing methodologies. 40 3. COMPANY PRESENTATION This chapter is dedicated to the description of the company where the master thesis project was made. Firstly, some characteristics about the Bosch Group and its business areas will be described. Then an overview about the situation of the company in Portugal, specifically in Braga, will be presented. 3.1 Bosch group In 1886, Robert Bosch (1861-1942), in Stuttgart Germany, opened his own “Workshop for Precision Mechanics and Electrical Engineering”, and years later, was the first one to adapt a magneto ignition device to a vehicle engine. That figure originated the actual logotype associated to the company. Right from the start, the company, was characterized by innovative strength and social commitment. The company, named as Robert Bosch GmbH, started to grow in an accentuated rate, and by the year of 1906, Bosch had subsidiaries in London, Paris and New York. Nowadays, Bosch is a world leading multinational engineering and Electronics Company headquartered in Gerlingen, near Stuttgart, Germany. It is responsible for 440 subsidiaries, installed in 60 countries, employing approximately 402 000 associates. The company generated sales of 77.9 billion euros in 2018 distributed by all its business sectors (Bosch, 2019c). The Bosch Group’s strategic objective is to create solutions for a connected life. Bosch improves quality of life worldwide with products and services that are innovative and spark enthusiasm. In short, Bosch creates technology that is “Invented for life”. 3.2 Business areas and divisions Bosch group divides its operations into four business sectors: Mobility Solutions, Industrial Technology, Consumer Goods, and Energy and Building Technology. The Mobility Solutions business sector is responsible for nearly 60 percent of total Bosch Group sales. The areas of activity of this business sector are, among others, injection technology and powertrain peripherals for internal-combustion engines, solutions for powertrain electrification, steering systems, safety and driver-assistance systems, technology for user-friendly infotainment as well as vehicle-to-vehicle and vehicle-to-infrastructure communication, repair-shop concepts, 41 and technology and services for the automotive aftermarket. This project will be developed, specifically in a subsidiary of the Car Multimedia (CM) area. The Industrial Technology business sector generated roughly 10 percent of total Bosch Group sales. This area includes customized drive, control, and linear motion solutions for factory automation, plant construction and engineering, and mobile machinery. The Consumer Goods business sector contributed with 23 percent of total Bosch Group sales in 2018. Its Power Tools division is a supplier of power tools, power-tool accessories, and measuring technology. In 2018, the Energy and Building Technology business sector generated roughly 7 percent of total Bosch Group sales. It has two areas of business: the global product business for innovative security and communications solutions, and the regional integrator business (Bosch, 2019b). Figure 19 - Bosch sales 2018 (Bosch, 2019b) As a leading IoT (Internet of things) company, Bosch offers innovative solutions for smart homes, smart cities, connected mobility, and connected manufacturing. 3.3 Bosch Car Multimedia The Car Multimedia (CM) division provides smart solutions for the versatile and highly effective integration of entertainment, navigation, telematics, and driver assistance functions 42 in the vehicle. It also supplies infotainment, display, connectivity and HMI solutions for passenger cars, trucks, two-wheelers, and off-highway vehicles. With approximately 6200 employees spread around the world, the division's expenditure on research and development will during this year, alone, amount to approximately 240 million euros (Bosch, 2019d). 3.4 Bosch in Portugal As it was said earlier, Bosch is a multinational company present in several countries around the world. Portugal, which is the country where this project was developed, is no exception. It had 5548 associates at the year of 2017, distributed for four different locations spread through the country. These are the Bosch Termotecnologia, S.A., located in Aveiro, Bosch Car Multimedia Portugal, S.A., located in Braga, the Bosch Security Systems - Sistemas de Segurança, S.A. and the Robert Bosch, S.A., located in Lisbon (Bosch, 2019a). Figure 20 - Bosch Portugal (Bosch, 2019a) 3.5 Bosch divisions Braga Bosch Braga (BrgP) was founded in 1990 under the name Blaupunkt Auto-Radio Portugal Lda. and produced car radios for the Blaupunkt brand. In 2008, the Car Multimedia division (CM) was restructured and the Blaupunkt brand was sold along with the aftermarket radio business 43 segment. Since then, CM focused only on original equipment for the car industry and the plant was renamed Bosch Car Multimedia Portugal, S.A. Bosch (BrgP) is divided in several departments. This type of organizational structure is important because it allows a bigger control and organization on the areas of the company. In a high level, the company divides itself in two different areas: the commercial and the technical area. Both areas have a different responsible, who is in charge of managing its areas, and report directly to the host company in Hildesheim, Germany. Relatively to this project, it was integrated in the logistics department (LOG), more specifically in the Logistics Innovation section (LOI). The LOG department is divided in several sections as: ▪ LOP - Responsible for the shipment of final product, consequently, makes it responsible for the management of customer orders and consequent production planning; ▪ LOM - Responsible for internal logistics management, or in other words, the management of raw material warehouse and supply of production lines; ▪ LOS - Responsible for the purchase of raw materials and the management of their reception at the Bosch BrgP site; ▪ LOT - Responsible for the management of transport by lorry, sea and emergency (airplane), as well as for transport support that requires customs services; ▪ LOD - Responsible for the management and development of packaging; ▪ LOI - Responsible for the realization, control and management of innovation logistic projects aimed at improving the performance of the LOG department. This section also has the responsibility of supporting the remaining LOG department regarding the use of the company's ERP system; ▪ LOC - Responsible for controlling the performance of the entire LOG department, about its associated costs; ▪ LOQ - Responsible for quality control of logistics processes. It is here where Bosch customer complaints are handled and processed (Bosch, 2019a). 44 4. DESCRIPTION AND CRITICAL ANALYSIS OF CM/LOI CURRENT SITUATION In this chapter it will be succinctly described the way of working of the department of CM/LOI – BrgP, and its characteristics. A critical analysis was performed to the current situation, using some tools such as semi-structured interviews, suitability assessment charts, Ishikawa diagrams, Pareto charts and other Lean tools. To conclude, not only a synthesis analysis of the problems identified was done, but also the degree of agility of the department was determined, to finalize this characterization. Doing the bridge between what was clarified at the introduction, this chapter presents the diagnosing phase of the action research cycle, where the aim was to define the context and the problems of the context (Figure 21). 4.1 Logistics Department operation As previously stated, this research took place at the CM/LOI-BrgP department, which has several functions and roles on the logistics of each Car Multimedia headquarter. Placed in Braga, it is responsible for the realization, control and management of logistics oriented innovative projects, which are attached to the development of the company in order to obtain even more accomplishments. Most of the projects that are currently in execution are Industry 4.0 (I4.0) projects with new technologies and innovative developments. These i4.0 projects are made on the development of very different technologies in order to continue the technological development of the company, as it is possible to see in Costa, Carvalho, Fernandes, Alves, and Silva (2017) or Freitas (2017). Furthermore, this section has also the responsibility of supporting the remaining LOG department, regarding the use of the company's ERP system. Independently of these Figure 21 - Diagnosing phase 51 It was divided in three parts, where the first one had questions related to basic information on the projects handled by the project leaders, the second one had its scope on the main problems and difficulties that were faced during the years, and the last one was a space to additional comments that might be relevant. It is extremely important to point out that these are the problems found at the department, and not the problems of the framework, since it is not used. The template is attached at appendix 3. The output of these 12 different interviews is presented in Table 4 where, besides the problems that were identified, and, consequently, the needs that are extrapolated from the problems, it also includes the number of times that these problems were mentioned. This fact can differentiate the importance and the urgency among them. Beyond that the type of waste (Section 2.1.2.4) that each problem brings is also identified. Since the interviews phase ended, the next step was to draw the main conclusions of the process. Table 4 - Identification of problems Problems Number of times that the problems were mentioned Lifecycle phases Types of wastes generated 1 Folders disorganization 4 Controlling Defects/Rework 2 Difficulty in time schedule planning 2 Planning Defects/Rework, waiting and skills wastes 3 Lack of alignment by the stakeholders 5 Initiation Defects/Rework and waiting wastes 4 Lack of risk management 4 Planning Defects/Rework and waiting wastes 5 Bad definition and deficit exposure of project requirements 6 Initiation Defects/Rework, skills wastes 6 Lack of information about the actual state of the project 8 Controlling Defects/Rework, Overproduction and skills wastes 7 Lack of documentation and important information about the project closure 3 Closure Skills wastes 8 Lack of definition of roles and responsibilities 7 Initiation Defects/Rework, waiting and skills wastes 9 Poor management of resources 3 Planning Defects/Rework, waiting and over production wastes 52 It is important to mention that each phase is not static, and these problems are noticed trough some different phases, however on the table 4 is an organization of the phase where the problem starts. The graph of Figure 28 represents the number of times that the problems were mentioned during the interviews and the related project phase, to allow a better understanding about the process output. It is possible to conclude that the nature of the problems is spread over different project management processes, where the project initiation are the ones where most problems were identified. Figure 28 - Graph of the identified problems It is possible to point out that the 80/20 rule can be partially identified. The 80/20 rule is partially utilized and is possible to see that 75% of the problems identified (nine out of twelve) are on the first two phases of the methodology (Initiation and Planning phases). It can be said that 75% of the identified problems are on the first 40% of the identified phases. 10 11 Inexistence of a communication plan Poor or inexistence of a deployment phase 1 2 Planning Initiation Waiting wastes Defects/Rework, inventory and skills wastes 12 Inexistence of a financial analysis; 1 Planning Defects/Rework wastes 53 Figure 29 represents a scheme that was based on the Ishikawa diagram, in order to determine the main causes for the occurrence of some problems. The problem of the Lack of alignment by the stakeholders was the problem that was chosen to represent this technique. Figure 29 - Ishikawa diagram with the causes of the lack of alignment of the stakeholders In a nutshell, it is possible to identify that the major problems and needs found on the way that the projects are managed, at this department, can be identified on a macro, meso and micro vision, detailed in Figure 30. 54 Figure 30 - Levels of problems To conclude it is possible to say that, at this point, sixteen framework problems (section 4.4.2) and twelve project management problems (section 4.4.3) were identified, being that some of them are the same at both lists. These outputs were needed to continue this diagnostic phase. 4.5 Agility Assessment This section is going to present the suitability assessment chart study, which was developed in order to obtain a better approach to the proposal. This was the last step of the diagnosing phase, in which the characteristics of the old framework and the identified problems until this point were collected. The missing piece and the main goal of this section is to determine the degree of agility that the new framework must present. The main advantages of this study is a better perception of the needs of the context, which is a really important step on the development of a new framework, as stated earlier. 55 4.5.1 Suitability assessment chart - Strategy Firstly, it is important to refer that this study was inspired by the Agile Suitability Filter tool (Project Management Institute, 2017). The thought behind this study is simple. The first step was the construction of an excel quiz template, then, it was sent to different members of the department, and finally, the respective conclusions were achieved, based on the answers. However, it is important to clarify the division of the projects into two types. According to the information gathered on the semi-structured interviews, it was possible to conclude that the department projects can be software development (Group A) and Implementation projects (Group B) (Figure 31). Figure 31 - First division into project types Further ahead, on the fifth chapter, a new way of characterizing projects was proposed in order to organize the topics of the new framework, however, and at this phase, this represents how the division works. 4.5.2 Suitability assessment chart - Creation The first field of the quiz is the project identification, where the user is able to insert the project name and type. This section will allow an easier evaluation of the results, since the projects are already divided by types. The assessment quiz can be divided in three different groups of questions, each group with three different questions, where the first one is the organizational culture quiz, the second is the team members’ quiz and the last one is regarded to project issues. Then, each question has a row of ten possible answers (a scale from 1 to 10), and this is the way that the respondents can classify the respective project by a score in each one of the nine different questions. Twelve different studies were made about old and on-going projects of 56 the department. The scale that was referred above, starts on the value 1 which is the lowest mark, and it increases until the classification of 10, which is the highest mark. The excel that was developed gives an automatic answer for each type of methodology and should be adopted for each group of questions, depending on the scoring that was attributed previously. An example of this can be seen in Figure 32. In the figure it is possible to identify the average, the standard deviation, and the median of each point. The average value is the average of every answer of every point in question, for example, for the question 3b, the value 7.67 is the medium value of all the studies that were taken for that specific question. The same logic is made to the standard deviation and the median. The standard deviation can give another input to this study, this because the lower the value is, the better it is considered the study, and for the same group of projects it means that the way of dividing the projects was the appropriate. In order to understand the scorecard of either the quiz or the output graphic, it is important to give some considerations about what is considered, in this case, traditional, hybrid or agile methodologies: ▪ When the word “traditional” is a result, it means that the characteristics found about that specific topic resembles to the ones usually found on plan-driven projects. ▪ When the word “agile” is a result, it means that the characteristics found about that specific topic resembles to the ones usually found on feature-driven projects. ▪ In its turn, the term “hybrid”, like was said earlier, represents the characteristics that cannot fit in the other two types. In other words, these characteristics are not too extreme to be considered as “traditional” or “agile”. In the example presented at Figure 33, it is possible to see the score and the respective answer about the agility of the methodology that should be used for the field “project issues”. Figure 32 - Quiz example 57 Figure 33 - Graph result – implementation project 4.5.3 Suitability assessment chart - Results The results were compiled in two different categories according to the two different types of projects, the group A, which are the software development results, and the group B, which are the implementation results. In order to understand if the data can be trustable, for each question, it was made a statistical study with the calculation of mean, median and standard deviation Figure 34. It is possible to affirm that the data is trustworthy, since the standard deviation values are low, and the biggest value is 2,6 (question 3b.). This means that the different answers from different users were close. 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number… Assessment chart Tradicional Hybrid Agile Result Figure 34 - Quiz example 58 4.5.4 Group A - Software development results and conclusions For the organizational culture field (the questions 1a., 1b., 1c.), the main fact that can be pointed out is the need of documentation at the department (1b.), which is on the traditional level (the less darker blue field). The heavy documental need is on a traditional level, and this is an important point to take in consideration. Besides that, the other answers are on a hybrid level (Figure 35). If the organizational culture field has traditional points, the team field is mostly agile with two of the three questions in that area (Figure 36). 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number… Assessment chart - Group A Tradicional Hybrid Agile A Figure 35 - Assessment chart Software development 1 59 Finally, on the project matters, the results are mostly high hybrid with agile variations (Figure 37). 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number… Assessment chart - Group A Tradicional Hybrid Agile A Figure 37 - Assessment chart Software development 3 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number… Assessment chart - Group A Tradicional Hybrid Agile A Figure 36 - Assessment chart Software development 2 60 4.5.5 Group B - Implementation results and conclusions For the organizational culture field, the main fact that can be pointed out is the need of documentation at the department, as well as with group A. Both groups had close results on this matter (Figure 38). If the organizational culture field has traditional points, the team field is mostly hybrid. Comparatively to the group A, this one obtained result with less agility (Figure 39). 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number of… Assessment chart B Tradicional Hybrid Agile Result Figure 39 - Assessment chart implementation projects 2 0 2 4 6 8 10 1a. What is the product owner's… 1b. What is the documentary need… 1c. What is the decision-making… 2a. Number of Project Team members? 2b. Team Members Experience 2c. Ease of getting feedback from… 3a. Change of requirements… 3b. How critical is the project? (What… 3c. Frequency of deliveries (number of… Assessment chart B Tradicional Hybrid Agile Result Figure 38 - Assessment chart implementation projects 1 67 requirements from the costumers and allows the increase of competitiveness among the other competitors. Figure 45 - Project Business Strategy II 5.3 Framework structure Framework structure was the name created to identify and present each methodology represented in each project phase. According to PMI (2017) a project can be divided in five different phases: Initiation, Planning, Execution, Control and the Closing phase (Figure 9). Some authors and methodologies do not consider this project structure, however the names that are given mean the same. For that reason, this will be the bottom line for the construction of the framework. A project management framework has the flexibility to be adjusted to the project needs, goals and constraints. A framework can have many phases and many processes per phase, where a process transformation takes place every time a new project is introduced (Markopoulos et al., 2008). Process frameworks are characterized by the agility concept. In frameworks there is a method, an approach, a standard, a philology, a logic, but no strict rules, specific phases, specific process or process dependencies (Markopoulos et al., 2008). The structure of the framework was inspired on the good practices explained in PMBOK (Figure 9). The framework is composed by six different phases and five different milestones and it is presented in Figure 46. 68 Figure 46 - New Framework for the management of projects 69 5.4 Framework phases In the next section, the characteristics and the procedures applied in each phase of the construction of the framework will be explained step by step, and a final summary of the new framework will be presented. In addition, whenever necessary, a bridge between the proposal and the data that was collected on the diagnosing phase is built to ensure the adaptability from the new framework, to the characteristics and problems of the department. 5.4.1 Project Management Strategy According to the results of the suitability assessment chart presented in section 4.6, the new framework must follow a hybrid approach with heavy documental needs attached, due to the company structure and difficulty of the flow of information. Taking in account the different project management strategies presented in section 2.1.1.3, and the facts mentioned on the paragraph above, the strategy that was proposed was the Iterative for the management of projects. The methodology can be seen as an Iterative approach, mostly because of the facts that are explained on the section 2.1.1.3, where it is said that an iterative lifecycle or strategy allows to group the work into time boxes where each box is target of evaluation, with the possibility of improvement from a time box to another. 5.4.2 Enter Phase In this section it is explained the beginning of the processes of the new framework. This is an introductory phase, on which the project request is developed and the assignment of the project team is done. Most of the projects that started during this research came from an idea of someone who talked to a co-worker being considered the right person to handle the idea. It is proposed that this should be documented on a document called Project request. This is an important phase because it is here that is discussed if the project can bring future improvements or not, since the Milestone 0 – Go/No Go is the next step. 5.4.3 Initiation Phase In the management of projects all phases are important, nevertheless, it is important to remember that in this research, 75% of the problems found came from inconsistencies of the 70 Initiation and Planning phases. For this reason, this phase embodies other dimensions of importance. It was stablished that the project charter is one of the important tools of this phase and it should be sent from the person that had the idea to the appropriate project manager, via email, with the information of the type of project, the idea and some improvements that would be taken from the idea. The next step is made by the project manager which role is to understand if the idea is doable. Then there are two ways to present the project to superiors in order to get approval. On the Point CIP (Continuous Improvement Process) weekly meeting or on the Steering Committee. The Point CIP is a weekly meeting that usually is made with the collaboration of all the members of each team where each one can discuss new ideas and problems that were found. On the other hand, the Steering Committee is a round of meetings, which usually takes place once a month, gathering the responsible for the departments in order to present new deliverables and align the next steps. The difference between these two is that the Steering Committee is more formal and with people with more power on the decision-making process. From this presentation several conclusions can be taken. If the project request is not ok, the idea is cancelled. If it is ok, this presentation will have the feedback and the guidelines that the project must follow in order to succeed. If the guidelines are agreed upon by all involved, it is time to define the team members and their roles and responsibilities. 71 The moment that the team is identified is the first milestone called the MS0 - Go/no Go and with this the enter phase is finalized (Figure 47). The initiation is characterized by two main documents: The project charter as suggested in Figure 47 and the stakeholder’s register document. The project charter is a document that needs more information and detail compared to the project request, being this the first version of the project charter. One more time, is important to point out that it is important to simplify processes and eliminate wastes, whereby the transformation of the project request into the project charter allows the elimination of unnecessary documentation and repetitiveness of answers (information that is explained in more than one document). The project charter themes of answer are described on Figure 48. Figure 47 - Enter and Initiation phases 72 In section 4.6, Diagnosing phase conclusions, it was concluded that the documentation needed in the company is high whatever the type of project, and in this phase it is possible to see the documentation need, that was identified, being fulfilled. In the next sections each one of the project request elements is going to be explained. ▪ Purpose The purpose of the project needs to be explained and needs to be explained to the team members. The purpose is the fundamental reason for initiating the project, leading it to reach the main goals. The purpose shows how much the project is beneficial for all the interested parts, being them the company, the product owner, the team or the end user. The purpose should answer the next questions: o Why are we doing the project? o What is the intention of the project owner? o What will be created, changed or enhanced? Figure 48 - Project Charter areas 73 ▪ Scope The scope defines what is inside and outside the project boundary. It is an important part for the alignment of expectations among the different parts. For instance, a good scope definition can prevent unnecessary disagreements regarding workloads and roles of each one. The scope should answer the next questions: o Which areas should be covered with this project? o Which areas should not be covered with this project? ▪ Success Criteria Success criteria indicate when the project purpose has been accomplished with a satisfactory result. The success criteria should be sufficiently detailed, in order to understand the line that allows identifying a project as a successful one. The success criteria should answer the next questions: o What (goals/targets) should be achieved in order for the project to be successful? o What are the benefits of the project? o How will the benefits be measured? ▪ Outcome The outcome captures what the project should lead towards identifying what is the output that is expected to reach. The outcome needs to be defined, because it influences the focus of the project. It should not be confused with purpose, which is the reason the project is carried out and the intentions of the project owner, whereas the outcome reflects the concrete desired result of the project. To deliver the project benefits and to fulfill the purpose, the project team must define the expected outcome of the project. The outcome should answer the next question: o What do we want to deliver to obtain the purpose? 74 ▪ Team Members The definition of what was exposed previously about the composition of the project team. ▪ Stakeholders Identification By definition, a stakeholder is a group or an individual, which is affected or affects the project. They are important because, usually they have resources for the project. Regardless the implementation of a stakeholder analyses further ahead, in the project charter it is important the identification of the complete group of stakeholders. In the stakeholders register document is described the communication flow and the importance/interest matrix. ▪ Users The users are individuals or groups who benefit from the outcome of the project. The users are important, because they validate the reason for the project’s existence. An absence of users means a lack of purpose and no justification to continue. Identifying users’ needs, early in the project, will increase the chance of achieving the best possible outcome. ▪ Restrictions Every project has restrictions set by its environment. This may for example be rules, procedures or standards, but also aspects such as time, money, technology, or knowledge. ▪ Risks Risks are different from constraints in that they only have potential to occur. They can be defined as threats and opportunities. Every project holds uncertainties, which can affect it in both good and bad ways. This analysis should answer the next questions: o What are the possible events or conditions that can affect the project? o What are the threats? o What are the opportunities? o How would risks affect the project? 75 ▪ Timeline The idea here is to present an overview about the main roadmap of the project, the dates of each milestone and some temporal boundaries. It is not needed a detailed schedule of the project development. ▪ Savings/Benefits In a generic way, it is important to convince the sponsor about the benefits and the savings that the project will generate. This can be a tricky task because it is all about guessing the gains, however, is an important indicator for the partners and its alignment with the team. It is important to clarify that the project charter is a document of extreme importance, since it is the place where all the project questions are answered. For that reason, it takes time and several meetings between the members to define the final version of the document. Regarding to the Stakeholders Register document, it is divided into two different parts: the Communication Plan for stakeholders, and the Power/Interest matrix (Figure 49). ▪ Power/Interest matrix The Power/Interest matrix is made for the team and it is about the people and organizations that are affected or affect your work. Some of these may have the power either to block that Figure 49 - Stakeholders Register areas 76 work or to advance it. Some may be interested in what you are doing, while others may not care, so it is needed to work out who you need to prioritize (see an example in Figure 50). Communication Plan for stakeholders This information establishes the plan of meetings and the flow of information for the different types of clusters of stakeholders. Depending on the group that the stakeholder is inserted, is the communication plan. In this plan, it is important to define key-players representative of a group of stakeholders to decrease the communication channels. The excess of communication channels can, sometimes, be thought as a major problem. For instance, if a project has a team of 5 people plus 2 groups of stakeholders each one with 4 people, there are 13 people involved in the project. Using the equation below, it is possible to conclude that there are 78 possible communication channels. This situation is going to bring loss of information and confusion to the environment. Well, with a proper communication plan and a defined strategy, for example electing someone in each group to be the key-speaker, the number of communication channels decrease for only 3 possible channels (1 element from the team and two others representing the other groups of stakeholders). Figure 50 - Power/Interest matrix Adapted from Mendelow (1981) 83 Figure 53 - White Board example In addition to this dynamic, it is proposed that each project team and each project manager find a proper dynamic to the flow of information within the team. However, what is proposed is the implementation of daily meetings near to the respective whiteboard where each member can answer to these questions: 1. What have you been working on? 2. What are you working on today? 3. Do you have any problems or impediments to making progress? These questions were based on the studies of Griffiths (2004). 5.4.4.1.2. Medium/long term organization With medium/long term organization, what is meant is the purpose of a place to work and to organize each step of the team and its roadmap for the future. This one is a topic that, just like others, needs a certain level of maturity for the framework, and for that reason this is not a proposal for implementation. The proposal is presented in section 7.2, as future work. 84 5.4.4.2. Performance Control You cannot manage what you cannot control; You cannot control what you cannot measure; You cannot measure what you cannot define. Adapted from (Cheng, 1994) The performance control is the other section of the control phase that is responsible to indicate some KPI’s, namely: ▪ Project Speed The speed of the project is an indicator that can give some insight about the speed that the project is having. The speed can be measured having into account the predicted dates of closure of either each phase or the project closure, and the beginning date. The speed on each phase depends on the percentage of workloads done per the percentage of time that has passed since the beginning of the phase. The workloads can be determined per phase depending on each deliverable that are supposed to deliver at each specific time of the project. In order to understand the logic behind the construction of the KPI´s, above is presented an example. On the next example it is important to presume some information. A specific phase named X has associated seven different deliverables with different workloads (Table 5). Table 5 - Example Deliverables and its workloads Deliverables Workloads D x1 8 D x2 3 D x3 13 D x4 3 D x5 8 D x6 21 D x7 21 The starting date of the phase is 15th of August, the end date is 15th of September, and the current date is the 27th of August. This means that the number of days predicted for the phase is 31, the number of days that already passed since the beginning is 12, and the number of 85 days for the predicted end of the project is 19. Following that logic, it is possible to say that the percentage of time that passed is 39% (Table 6). Table 6 - Example 1 dates Initial date 15/8/2019 Days since the beginning 12 End date 15/9/2019 Days until the predicted end 19 Current date 27/8/2019 Percentage of time passed 39% Toal days 31 Another important input that is possible to point out from the text is the percentage of work that was done at this day, which is 45%. 𝑆𝑝𝑒𝑒𝑑 = % 𝑜𝑓 𝑤𝑜𝑟𝑘𝑙𝑜𝑎𝑑𝑠 𝑑𝑜𝑛𝑒 % 𝑜𝑓 𝑡𝑖𝑚𝑒 𝑡ℎ𝑎𝑡 𝑝𝑎𝑠𝑠𝑒𝑑 The meaning of the result indicates indirectly if the projects are delayed or not. The scale of results varies from 0 and do not have a maximum limit, and if the result is lower than 1 it means that, with the same pace, the project will be late. If the result of the speed is more than 1 it means that the project probably is loose on time. In the example presented above, the Speed is 1.17, which allows us to understand that, at this day, the project is on time. However, it is difficult to understand what the practical effect of these numbers is. That’s why the next KPI was created. It is important to warn that this process relies on the accuracy of the assignment of workloads to the different deliverables. To increase this accuracy, the PMO team of the department will have an important role to support the project managers. ▪ Project Delay/Slack This is the other KPI, which is attached to the project speed. To reach this value, first it is necessary to calculate the number of days that, at the current pace, the project or the phase is predicted to finish. Then it is easy to predict if the phase or project is on time or not. Taking the example above explained and seeing that the speed is 1.17, it is expected that the next KPI is positive, or by other words, the project will be ahead of schedule. 86 A way to quantify this is taking into account the pace that the phase already has. In this example, five deliverables (the sum of the workloads is 35) were completed in twelve days. Dividing them, the result is 2.92 workloads per day. Well, if the pace is 2.92 workloads per day, it is expected that for the remaining 42 workloads the phase will last for 14.4 more days. Adding these 15 days, rounding up the value, the final date is 10th of September. Since the predicted date for the end of the phase was 15th of September, it means that, at this pace, the phase is 5 days ahead of schedule (Table 7). Table 7 - Example 1 results Workloads done (%) 45% Speed = % Workloads done / % Time spent 1.17 Real workloads at this pace 2.92 How many days to the end at this pace 14.4 End date at this pace 10/9/2019 Delay or Slack of the phase 5.0 The sum of the values of this indicator per phase results in the overall delay/slack of the project. This happens because of the possibility of overlapping of phases on time. 𝐷𝑒𝑙𝑎𝑦 / 𝑆𝑙𝑎𝑐𝑘 = 𝐸𝑛𝑑𝑖𝑛𝑔 𝑑𝑎𝑡𝑒 (𝑝𝑙𝑎𝑛𝑛𝑒𝑑)− 𝐸𝑛𝑑𝑖𝑛𝑔 𝑑𝑎𝑡𝑒 (𝑝𝑒𝑑𝑖𝑐𝑡𝑒𝑑 𝑎𝑡 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑆𝑝𝑒𝑒𝑑) The two indicators that were presented have a direct relation between them. For instance, if a phase of a project has the speed at 1.17, that means that the slack of the phase is 5 days as stated in the example. On the other hand, taking in account another example, where the speed value is 0.83 it is possible to determine that the delay is 7 (Table 8). Table 8 - Example 2 results Workloads done (%) 45% Speed = % Workloads done / % Time spent 0.83 Real workloads at this pace 2.06 How many days to the end at this pace 20.4 End date at this pace 21/9/2019 Delay or Slack of the phase -7.0 On its turn, if the speed is 1, it means that the phase is on time, without any delay or slack to the end date. This phase ends with the Milestone of End of execution and Stabilization phase (MS4). 5.4.6 Closing 87 Regarding the fact that, at this phase, most of the work is done, this is an extremely important phase, which usually does not have enough effort of the department. The closing phase of this framework starts with the Milestone MS4 – End of execution and Stabilization phase. Like it is possible to understand, this is a phase meant to develop processes of stabilization, namely maintenance, deployment and training strategies. It is possible to argue that these stabilization strategies depend on the nature of the different projects, however, this is just a standard of tools that may help the project manager, and the PMO department can help and support these questions. Maintenance strategy – If a project is well developed, with all the features and characteristics working, it may seem that it is closed, however if the plan to maintain the project tools or functionalities does not exist, all the efforts can be in vain. A proper maintenance strategy is responsible for a seamless stabilization of the project. At this stage, preventive maintenance rules are defined, just like the action plans in case of failure. Training – The training or the education of the end user is a crucial part of a project, since the project cannot reach the success criteria if the end user is not trained for the new functions. In other words, it is possible to say that the project success depends on the right training. Next, the final Milestone happens, MS5 – Project Closure, with the final deliverables, a final report and the new product or service. Deployment strategy – By definition the deployment of something is the group of activities that make the product or service available to use. This topic is related with the division that was explained in section 5.1 because the division is oriented to a sequential project type. It is proposed that an idea should follow the path: first the R&D project; then the PoC project; then the Pilot project; and then the Yokoten project. The deployment strategy is made to clarify these barriers and the strategies and timings needed to follow this division. 5.4.7 Framework Milestones Through the review of the framework it is possible to find some milestones, which are going to be explained on a summarized way in this section. There are at least 5 different milestones, one at each change of phase. It is at least, due to the iterative strategy applied on the Execution, Monitoring and Controlling phase, where at the 88 end of each iteration, there is one sub-milestone. The transition from the Enter phase to the Initiation phase is made with the Milestone 0 – The Go / No Go. It determines if the project will be born or not, based on the information of the Project Request and the Team assignment. Then we have the kick-off Milestone 1, that is between the Initiation and the Planning phase, on which is the formal presentation of the project for the stakeholders with a well-structured Project Charter. The Milestone 2 is the Start of Execution, where the plan is done. During the execution, there are a number of sub-milestones at the end of each iterative cycle, where it is discussed the Lessons Learned, if there are any Change Requests, and to give the plan for the next iteration. At the end of this process is the Milestone 4 – End of Execution and Stabilization phase, which marks the end of that important phase of the Execution. Finally, the last one is the Milestone 5 – Project Closure, with the delivery of the final product or service from the project to the client. At this phase the product or the service is stabilized and at perfect working conditions. 5.5 Proposal chapter conclusions This section comes like a conclusion after the presentation of the proposal, since it is important to define some aspects. Firstly, it is important to remember that this study followed an action research methodology. From the five phases that are characteristics of this methodology, due to the lack of time, the research only reaches the third phase – Taking Action. The next phases of Evaluating and Specifying the Learnings, presuppose time to evaluate the tool. Instead the possible alterations are proposed in section 7.2 (Future Work). Furthermore, it should not be forgotten that the Diagnosing phase is explained in chapter 4, the Action Planning is in the fifth chapter and the Taking action was developed in the department following the plan previously detailed. Another thing to point out is that this is a draft version of the framework, which is going to be target of continuous improvements during the time, in order to make it a more robust framework. Like it is stated in section 4.6, it was required to follow a hybrid approach for the framework. It is easy to identify the various artefacts from the PMBOK and consequently of the plan driven or traditional methodologies, however the framework is considered hybrid because of the dynamic phase of execution and monitoring phase. Analyzing that phase, it is possible to find 89 a lot of similarities with the Agile framework named Scrum, where the ideas and the main framework was inspired. The differences are only the names that were given, for example instead of sprints, it is called Milestones with deliverables to reach, but the idea and the procedures are similar. This is the reason why the framework can be classified as a hybrid framework. The framework was, at the time of the end of this research project, starting to be implemented at the department, however, and due to the lack of time, only presumable results are described below. 90 6. RESULTS ANALYSIS In this section, the expected results of the effects of the proposal is presented. Due to time constraints, only some steps of the framework were taken, so mainly expected results are analysed. It is important to say that due to the specific characteristics of the project, the results cannot be presented on a quantitative way. A new way of work for a department was the main output of this project, and despite the undeniable importance of the project and its impact, the results are not quantifiable. This section is structured reminding the problems that were found in section 4.4.2 and comparing them with the situation after the implementation of the framework. The list of problems that were chosen were the ones from Table 4, since the problems related to the management of projects are the ones that matter the most. To allow a better understanding of the context, that problems from Table 4 were divided by the objectives of the section 1.2. For each objective, the tool 5M1E was used in order to organise the problems. The abbreviation stands for Management, Method/Measurement, Machines, Materials, Man and Environment, even though none of the problems could suit on the Machines category. 6.1 Instill project management processes (Management) The next sections are related to questions that can fit on the management issues. 6.1.1 Improvement of schedule planning With the implementation of an iterative strategy, the planning process became easier, reducing the difficulty reported in section 4.4.3. The plan can be designed without all the characteristics that were necessary previously, and at each increment, right before the start of each execution milestone, a new round of planning is made. With this is expected to achieve a proper planning that can reflect a lower degree of uncertainty of a plan for a project. 6.1.2 Better risk management The Risk management was one of the concerns that were mitigated with the new framework. The Risk management document is presented in the planning phase, and the new template is going to be developed as it will be referred in the next steps chapter just like the necessary 91 training sessions that the team needs, in order to improve the risk management practice. This measure will probably solve the problem. 6.2 Improve the planning of workloads for team members or stakeholders (Method/Measurement) The next sections are related to questions that can fit on the method or measurement issues. 6.2.1 Visualization of actual state of the project The lack of information within partners is a topic that depends on other factors, namely the level of commitment of the members. However, with the introduction of, not only of the Steering committees (with presentation of the projects developments) but also the whiteboards (visual exposition of the current status) helped to improve this topic. This measure will probably solve the problem, because it is expected that the actions allow a better integration with the stakeholders and on time updates about the projects. 6.2.2 Bad or inexistence of a deployment phase Like it was said before, the deployment phase is now one of the parts that are on the new closing phase with the deployment strategy. With this measure it is expected that actions like the training of the end user, the project lessons learned, or the maintenance strategy, start to be made. All these actions bring advantages and it is expected that, with them, problems related to this area will decrease. 6.2.3 Bad definition and deficit exposure of project requirements The answer for this topic seems to be the same that was answered above in the “Lack of information about the actual state of the project” topic. The steering committees and the whiteboards came to solve this problem. It is expected that these specific events, or the exposure of the whiteboards to the open space, bring more information to the stakeholders and the team of a project. 6.2.4 Inexistence of a communication plan The plan for communications for different groups of stakeholders was done. This was the possible solution proposed for this matter. With a proper plan it is expected that the 92 communication channels start to be less, minimizing wastes of misinterpretation and repetitiveness of information. 6.2.5 Inexistence of a financial analysis The financial analysis was not considered due to the maturity level that the framework needs to achieve. It was decided that the financial analysis would be added somewhere in the future, since the moment that the framework was introduced and the way of working of the department are stabilized. 6.3 Use of the same standards among all the projects (Materials) The next sections are related to questions that can fit on the materials issues. 6.3.1 Lack of documentation and important information about the project closure One of the biggest differences between the two frameworks is precisely the new way of closing projects with the characteristics that they need. The maintenance strategy usually supports the projects that interact with the shop floor and hardware, guaranteeing a clean closure. The same can be said for the training and the deployment strategy. This measure will probably solve the problem, since it is expected that the lessons learned from project closure to project closure act effectively avoiding the repetitiveness of problems. 6.3.2 Better folders organization The documental disorganization was a general problem within the projects, however the framework did not cover this topic due to the fact that in parallel to this project, another one was being developed, which scope was to standardize the folders of the department. 6.4 Improve and define the roles and responsibilities for project management (Man) The next sections are related to questions that can fit on the topic of man issues. 6.4.1 Lack of definition of roles and responsibilities The assignment and acceptance of roles and responsibilities are always a difficult change for the partners. However, the stakeholder’s management document can be one of the factors 99 Fernandez, Daniel, J., & Fernandez, John, D. (2009). Agile Project Management - Agilism Versus Traditional Approaches. The Journal of Computer Information Systems, 49(2), 10–17. Fowler, M., & Highsmith, J. (2001a). Agile Manifesto. Software Development, 9(8), 28–35. https://doi.org/10.1111/j.0022-0477.2004.00877.x Fowler, M., & Highsmith, J. (2001b). The Agile Manifesto (Article). Software Development Magazine: The Lifecycle Starts Here, (August). Freitas, A., Maio, A., Maia, P., Gomes, N., Nogueira, A., Carvalho, M. S., … Machado, S. (2017). Savings In Internal Logistics using RFID-Based Software System in a Lean Context, (October), 11–13. Gilb, T., & Finzi, S. (1988). Principles of Software Engineering Management, 1–30. Goldrat, E. (1997). Critical Chain. The North River Press Publishing Corporation P.O. BOX 56. Goldshy, T. J., & Griftis, S. E. (2006). Modeling Lean, Agile, and Leagile Supply Chain Strategies. Journal of Business and Logistics, 27(1). Griffiths, M. (2004). Using Agile Alongside the PMBOK. Retrieved March, 1–8. https://doi.org/10.1017/S1474745605002673 Gu, L., Li, N., Ma, G., Ai, Q., & Wang, A. (2014). Improved Critical Chain Project Management Framework for Scheduling Construction Projects. Journal of Construction Engineering and Management, 140(12), 04014055. https://doi.org/10.1061/(asce)co.19437862.0000908 Hewagamage, C., & Hewagamage, K. P. (2011). Redesigned framework and approach for IT project management. International Journal of Software Engineering and Its Applications, 5(3), 89–106. Hines, P. P., & Taylor, D. (2007). Going lean, Lean Enterprise Research Centre. MedGenMed : Medscape General Medicine, 9(4), 3–43. Holweg, M., & Maylor, H. (2018). Lean leadership in major projects: from “predict and provide” to “predict and prevent.” International Journal of Operations and Production Management, 38(6), 1368–1386. https://doi.org/10.1108/IJOPM-02-2017-0100 IPMA. (2015). IPMA Individual Competence Baseline ® PUBLICATIONS Individual Competence Baseline for Project, Programme & Portfolio Management Version 4.0. Jalali, A., Hertogh, M., Bosch-rekveldt, M., & Blom, R. (2016). Does lean & agile project management help coping with project complexity. Procedia - Social and Behavioral Sciences, 226(October 2015), 252–259. https://doi.org/10.1016/j.sbspro.2016.06.186 100 James Highsmith. (2000). Adaptive Software Development. Dorset House Publishing Co. Free Sample Chapter. Ken Schwaber; Mike Beedle. (2001). Agile Software development With Scrum. Edition, Pearson International. Kent Beck, & Fowler, M. (2000). Planning Extreme Programming (First Edit). Addisson Wesley. Koskela, L., & Howell, G. (2002). The underlying theory of project management is obsolete. USIR. Retrieved from http://usir.salford.ac.uk/id/eprint/9400/ Liker, J. K. (2004). The Toyota way: 14 management principles from the world’s greatest manufacturer. Action Learning Research and Practice. Lloyd, G. (2013). Lean Project Management – It’s all about value. Markopoulos, E., Bilbao, J., Bravo, E., Stoilov, T., Vos, T. E. J., Talamanca, C. F., & Reschwamm, K. (2008). Project management stage mutations within agile methodological framework process transformations. WSEAS Transactions on Information Science and Applications, 5(5), 776–785. Middleton, P., & Joyce, D. (2012). Lean software management: BBC worldwide case study. IEEE Transactions on Engineering Management, 59(1), 20–32. https://doi.org/10.1109/TEM.2010.2081675 Milosevic, D., & Patanakul, P. (2005). Standardized project management may increase development projects success. International Journal of Project Management, 23(3), 181– 192. https://doi.org/10.1016/j.ijproman.2004.11.002 Moher, D., Liberati, A., Tetzlaff, J., Altman, D. G., & Group, T. P. (2009). Preferred Reporting Items for Systematic Reviews and Meta-Analyses : The PRISMA Statement, 6(7). https://doi.org/10.1371/journal.pmed.1000097 Moujib, A. (2007). Lean project management. In P. P. M. I. Newtown Square (Ed.), PMI® Global Congress 2007—EMEA. Budapeste, Hungary. Naylor, J. Ben, Naim, M. M., & Berry, D. (1999). Leagility : Integrating the lean and agile manufacturing paradigms in the total supply chain, 62, 107–118. Nurdiani, I., Börstler, J., & Fricker, S. A. (2016). The impacts of agile and lean practices on project constraints: A tertiary study. Journal of Systems and Software, 119, 162–183. https://doi.org/10.1016/j.jss.2016.06.043 O’Brien, R. (1998). An overview of the methodological approach of action Research. University of Toronto, 1–22. https://doi.org/10.3415/VCOT-07-10-0095 101 Oates, B., & Capper, G. (2009). Using systematic reviews and evidence-based software engineering with masters students. Ease, 1–9. Ohno, T. (1988). Toyota Production System. International Journal of Operations. Packendorff, J. (1995). Inquiring into the temporary organization: New directions for project management research. Scandinavian Journal of Management, 11(4), 319–333. https://doi.org/10.1016/0956-5221(95)00018-Q Palmer, S., & Felsing, J. (2002). A practical guide to feature-driven development. Technical University of Munichical University of Munich. Petrillo, A., Di Bona, G., Forcina, A., & Silvestri, A. (2018). Building excellence through the Agile Reengineering Performance Model (ARPM): A strategic business model for organizations. Business Process Management Journal, 24(1), 128–157. https://doi.org/10.1108/BPMJ03-2016-0071 PMI. (2017). A Guide to Project Management Body of Knowledge. PMI (Vol. 91). PMI. Pollack, J., & Adler, D. (2015). Emergent trends and passing fads in project management research: A scientometric analysis of changes in the field. International Journal of Project Management, 33(1), 236–248. https://doi.org/10.1016/j.ijproman.2014.04.011 Poppendieck, B. M., Poppendieck, T., & Wesley, P. A. (2003). Copyright Many of the designations used by manufacturers and sellers to distinguish their products. Project Management Institute, I. (2017). A Guide to the Project Management body of Kowledge (PMBOK® Guide)--Sixth edition. Project Management Journal. https://doi.org/10.1002/pmj.20125 Rehacek, P. (2017). Application and usage of the standards for Project Management and their comparision. Journal of Engineering and Applied Sciences. Saunders, M., Lewis, P., & Thornhill, A. (2009). Research Methods for Business Students. 5th ed. Pearson Education Limited. Essex CM20 2JE. https://doi.org/10.1007/s13398-0140173-7.2 Saunders, M., Lewis, P., & Thornhill, A. (2017). Research Methods for Business Students (Fifth edition). Nervenheilkunde. https://doi.org/10.1080/00223891.2010.528484 Schultz, B., & Schultz, A. (2014). [Neuromonitoring in children - how deep does my patient sleep?]. Anasthesiol Intensivmed Notfallmed Schmerzther, 49(2), 84–90. https://doi.org/10.1145/1134285.1134500 Shenhar, A. J., & Dvir, D. (1996). Toward a typological theory of project management. Research 102 Policy, 25(4), 607–632. https://doi.org/10.1016/0048-7333(95)00877-2 Shingo, S. (1989). Shingo__Shingeo__a_Study_of_the_Toyota_Production_System_From_an_Industrial_Engineering_Viewp oint__1989__Productivity_Press__306P_.Pdf. Silva, F. Q. B., Costa, C., França, A. C. C., & Prikladinicki, R. (2010). Challenges and solutions in Distributed Software Development Project Management: A systematic literature review. Proceedings - 5th International Conference on Global Software Engineering, ICGSE 2010, 87–96. https://doi.org/10.1109/ICGSE.2010.18 Stepanov, A. (2018). What is Lean Project Management? Its Definition, Principles, and Methodology. Retrieved October 23, 2019, from https://blog.ganttpro.com/en/what-islean-project-management-its-principles-methodology-and-tools/ Taylor, P., Mason-jones, R., Naylor, B., & Denis, R. (2010). International Journal of Lean , agile or leagile ? Matching your supply chain to the marketplace, (May 2013), 37–41. Tranfield, D., Denyer, D., & Smart, P. (2003). <Tranfield, Denyer, Smart - 2003 - Towards a methodology for developing evidence-informed management knowledge by means of systematic rev.pdf>, 14, 207–222. https://doi.org/10.1111/1467-8551.00375 Trojanowska, J., & Dostatni, E. (2017). Application of the Theory of Constraints for Project Management. Management and Production Engineering Review, 8(3), 87–95. https://doi.org/10.1515/mper-2017-0031 Turner, J. R. (2008). The Handbook of Project-Based Management: Leading Strategic Change in Organizations. Annals of Physics. Utterback, J., Meyer, M., Tuff, T., & Richardson, L. (2016). When Speeding Concepts to Market Can Be a Mistake The speed with which is to move con, 22(4), 24–37. Van Valkenhoef, G., Tervonen, T., De Brock, B., & Postmus, D. (2011). Quantitative release planning in extreme programming. Information and Software Technology, 53(11), 1227– 1235. https://doi.org/10.1016/j.infsof.2011.05.007 Wilson, J. (1997). Book Selection MR Goodman : Study Notes in System Dynamics. Journal of the Operational Research Society, 48, 1144–1150. Womack, J., & Jones, D. T. (1996). Lean Thinking-Banish Waste and Create Wealth in Your Corporation. The Journal of the Operational Research Society, 48(11), 1148. https://doi.org/10.1057/palgrave.jors.2600967 Womack, J. P., & Jones, D. T. (1996). Lean thinking: banish waste and create wealth in your 103 corporation. Journal of the Operational Research Society. https://doi.org/10.1057/palgrave.jors.2600967 Womack, J. P., Jones, D. T., & Roos, D. (1990). The Machine That Changed the World: The Story of Lean Production. HarperPerennial. Wysocki, R. K. (2006). Effective Software Project Management. Wiley Publishing.inc. Joseph B. Wikert. Wysocki, R. K. (2009). Effective Project Management (Sixth). Willey Publishing.inc. 104 APPENDIX 1 – DATABASE TABLE References What is the relation between Lean Thinking and Project Management? What Project Management methodologies were found on this research? Ahimbisibwe, Arthur;, Robert Y.; Cavana, and Urs Daellenbach. 2015. “A Contingency Fit Model of Critical Success Factors for Software Development Projects A Comparison of Agile and Traditional Plan-Based Methodologies.” (January). - + Angioni, M., Carboni,D., Pinna, S., Sanna, R., Serra, N., & Soro, A. (2006). Integrating XP project management in development environments. Journal of Systems Architecture, 52(11), 619–626. https://doi.org/10.1016/j.sysarc.2006.06.006. - + Anwar, S. A., Hafeez, Y., Asghar, S., Shabbir Hassan, M., & Hamid, B. (2014). Towards a framework for scrum handover process. Proceedings of the Pakistan Academy of Sciences, 51(4), 265–275. - + Cervone, H. F. (2014). Understanding agile project management methods using Scrum. - + Cockburn, A. (2004). Crystal clear a human-powered methodology for small teams, (January 2004). - + Demir, S. D., Bryde, Dj, & Sertyesilisik, B. (2013). Introducing AgiLean to Construction Project Management. Journal of Modern Project Management, (3), 1. Retrieved from http://researchonline.ljmu.ac.uk/ + - Dyck, S., & Majchrzak, T. A. (2012a). A contingency fit model of critical success factors for software development projects. Journal of Enterprise Information Management Industrial Management & Data Systems Iss Logistics Information Management, 23(5), 224–244. https://doi.org/10.1108/17410391011008888 - + Goldshy, T. J., & Griftis, S. E. (2006). Modeling Lean, Agile, and Leagile Supply Chain Strategies. Journal of Business and Logistics, 27(1). + - Gonzalez, W. (2014). Applying Agile Project Management to Predevelopment Stages of Innovation. International Journal of Innovation and Technology Management, 11(04), 1450020. https://doi.org/10.1142/s0219877014500205 - + 105 References What is the relation between Lean Thinking and Project Management? What Project Management methodologies were found on this research? Gu, L., Li, N., Ma, G., Ai, Q., & Wang, A. (2014). Improved Critical Chain Project Management Framework for Scheduling Construction Projects. Journal of Construction Engineering and Management, 140(12), 04014055. https://doi.org/10.1061/(asce)co.1943-7862.0000908 - + Hewagamage, C., & Hewagamage, K. P. (2011). Redesigned framework and approach for IT project management. International Journal of Software Engineering and Its Applications, 5(3), 89–106. - + Holweg, M., & Maylor, H. (2018). Lean leadership in major projects: from “predict and provide” to “predict and prevent.” International Journal of Operations and Production Management, 38(6), 1368–1386. https://doi.org/10.1108/IJOPM-02-2017-0100 + - Middleton, P., & Joyce, D. (2012). Lean software management: BBC worldwide case study. IEEE Transactions on Engineering Management, 59(1), 20–32. https://doi.org/10.1109/TEM.2010.2081675 + - Naylor, J. Ben, Naim, M. M., & Berry, D. (1999). Leagility : Integrating the lean and agile manufacturing paradigms in the total supply chain, 62, 107–118. + - Palmer, S., & Felsing, J. (2002). A practical guide to feature-driven development. Technical University of Munichical University of Munich. - + 106 References What is the relation between Lean Thinking and Project Management? What Project Management methodologies were found on this research? Petrillo, A., Di Bona, G., Forcina, A., & Silvestri, A. (2018). Building excellence through the Agile Reengineering Performance Model (ARPM): A strategic business model for organizations. Business Process Management Journal, 24(1), 128–157. https://doi.org/10.1108/BPMJ-03-2016-0071 - + Pons, D. (2008). Project management for new product development. Project Management Journal, 39,2:82–97. - + Poppendieck, B. M., Poppendieck, T., & Wesley, P. A. (2003). Copyright Many of the designations used by manufacturers and sellers to distinguish their products. + + Rehacek, P. (2017). Application and usage of the standards for Project Management and their comparision. Journal of Engineering and Applied Sciences. - + Taylor, P., Mason-jones, R., Naylor, B., & Denis, R. (2010). International Journal of Lean , agile or leagile Matching your supply chain to the marketplace, (May 2013), 37–41. + - Tripp, John, and Deborah J. Armstrong. 2018. “Agile Methodologies: Organizational Adoption Motives, Tailoring, and Performance.” Journal of Computer Information Systems 58(2): 170–79. https://doi.org/10.1080/08874417.2016.1220240. + - 107 APPENDIX 2 – OLD FRAMEWORK Old framework Before the project 2Initiation 1Needs of the client MS1Kick-off 3Planning Phase Brainstorming Project Request LSWLogistic strategic workshop Validation of the PR with the client Valid PR? Schedul a meeting with the decision team(CLP,Client;LOGP;PL) Defining the project team Yes No New conditions accepted? Yes No Cancelled This is a preview process that does not happen in a speciffic moment; It is like a database of potencial projects and business ideias. Each client present a Project Request – which is a document that contains the title, description, benefits of the project, risks, consequences, criteria, investments, efforts, KPI´s, and relevant dates. A folder that contains some Project requests. The PR are allocated in priority pools and a project leader is attributed to each one of the projects. • Project LeaderOrganize, manage, repport, control cash-flows, schedule and keeps the levels of motivation; • Participant – Realize the activities; • Process owner – Aproove the process; • Sponsor – Advise and manage conflicts. MS1-Kick-off of the project • Lecture of the P.R to the project team; • Communication of the project goals; • Presentation of the project rules namely the personal functions, the standard documents which are available, and the follow-up method: • The aim of this milestone is to levelling the main information among the team members and assure the commitment Communic ation Plan Word document with: • Meetings frequency; • Follow-up method; • Team members participation type. Document with some charts to: • Resources consumption; • Project modifications; • Costs, sales etc; • KPIS management. Document with: • All the schedules, dates, and deadlines (planned and realized) Excel document with: • Cash-flow during the whole project; • VAL; • Investment plan. Cash-flow analysis Time schedule Cockpit chart 108 Old Framework MS2Beggining of the execution 4Execution (VSM/VSD and implementation) MS5End project 5Stability control MS3Future state validation MS4End of execution 3Planning MS2Beggining of the execution • Present and validate with the team the outcomes of the planning phase; • Remember the objectives; • The purpose of this Milestone is to validate the plan. Time schedule control Cash-flow mapping Open point list Planing Follow-up meetings Others Keep-up with the KPI´S and the target condition Meetings Coordinate fine tunning activities Others With activity satus and comments Action plan for errors and subsequen tly their correction s With activity satus and comments • Reporting and cockpit chart control: • Atualization of the presentation standard; • Manage who can attend at the meetings; • Ensure right trainning for the team members; Checklist For standard work; It allows to understan d if the standards are being followed MS3Future state validation At this point, the aim of this Milestone is to validate the future state proposal MS4End of execution To present the implementation of the plan; To confirm the target condition and the final date for the stabilization phase (phase 5) MS5End project • Presentation of results • Validate the taget condition • Lessons learned (doc) • Satisfaction document Communic ation Plan Word document with: • Meetings frequency; • Follow-up method; • Team members participation type. Document with some charts to: • Resources consumption; • Project modifications; • Costs, sales etc; • KPIS management. Document with: • All the schedules, dates, and deadlines (planned and realized) Excel document with: • Cash-flow during the whole project; • VAL; • Investment plan. Cash-flow analysis Time schedule Cockpit chart