A Risk Breakdown Structure proposal for Multiple Project Software Environments Camila Gomes Pereira (Universidade Federal de Pernambuco, PE, Brasil) - cgp@cin.ufpe.br Júlio Venâncio de Menezes Júnior (Universidade Federal de Pernambuco, PE, Brasil) juliovenancio@gmail.com Cristine Martins Gomes de Gusmão (Universidade Federal de Pernambuco, PE, Brasil) cristine.gusmao@pq.cnpq.br With the advance of the need for software solutions, the number of projects being developed also grows. Hence, a company hardly realize just one project at a time. Several distinct projects are developed simultaneously, and this environment is called Multiple Project Environments. Every software project is susceptible to events that may affect its success. Aiming to minimize these negative events arises the process of risk management. The process of risk management involves tools that make it possible to assist on the process of management. On this context, the Risk Breakdown Structure (RBS), is a tool that lists the risk factors categorically. The objective of this work is to analyse and propose enhancements on the RBS proposed by Almeida et al (2012), with the goal of making the tool more comprehensive and effective on the process of risk identification. Keywords: Risk Breakdown Structure, Multiple Project Software Environment, Risk Factors, Risk Management. 1. Introdução No contexto atual as mudanças acontecem em grande velocidade, levando as empresas a terem que se adaptar constantemente às novas mudanças. Diante disso, as empresas se veem em um ambiente extremamente competitivo, onde é necessário fazer a percepção dos ambientes internos e externos à empresa para identificar possíveis oportunidades e ameaças (PORTO; BANDEIRA, 2006). Este cenário exige que as organizações busquem formas de tornarem-se mais competitivas em relação às outras. Técnicas e ferramentas são adotadas para alavancar a produtividade e eficiência, para assim se destacar perante a concorrência. Nesta busca por vantagem competitiva, a evolução tecnológica influenciou o ambiente organizacional. Soluções em software passaram a ser importantes ferramentas que auxiliam as organizações a atingirem seus objetivos. Neste contexto, a utilização de software é considerada como de grande importância para a sobrevivência das empresas. Atualmente, não só as empresas têm recorrido à utilização de software, mas também todas as áreas da atividade humana (GUSMÃO, 2007). Isso levou a um aumento da demanda de produção de software, onde as empresas desenvolvedoras de software precisam produzir projetos para as mais diversas funções. Com o aumento da demanda, empresas desenvolvedoras de software precisam saber gerenciar mais de um projeto simultaneamente, levando em consideração os diferentes objetivos de cada projeto e as metas da organização. Projetos de desenvolvimento de software estão sujeitos aos mais diversos eventos que podem influenciar o seu sucesso. Segundo Heldman (2005), riscos podem causar consequências negativas como também oportunidades. O gerenciamento de riscos tem como objetivos aumentar a probabilidade e o impacto dos eventos positivos e reduzir a 5235
probabilidade e o impacto dos eventos negativos no projeto (PMI, 2013). Nesse contexto, o gerenciamento de riscos contribui para aumentar a probabilidade de sucesso do projeto. Existem vários riscos que podem afetar o andamento do projeto. Onde é preciso identificar os riscos associados ao projetos. A identificação de riscos é uma atividade que pretende coletar os possíveis riscos para o projeto, compondo uma documentação sobre os dados coletados. Identificar riscos muitas vezes produz apenas uma enorme lista de riscos, que pode ser difícil de entender e de gerenciar. Os riscos encontrados devem ser estruturados hierarquicamente de forma a tornem-se compreensíveis (HILLSON, 2002). Nesse contexto, surge a Estrutura Analítica de Riscos (EAR), uma ferramenta que auxilia a gestão de riscos, com o objetivo de apresentá-los de forma clara, a fim de serem melhor gerenciados (HILLSON, 2002). E que pode ser usada em conjunto com outras técnicas de comunicação e identificação de riscos. Neste sentido, o presente trabalho tem como objetivo avaliar e propor melhorias em estrutura analítica de riscos já existente para ambientes de múltiplos projetos de software (ALMEIDA et al, 2012), pois alguns riscos e fatores de riscos foram considerados relevantes após revisão de literatura. Este artigo encontra-se dividido seis seções, a primeira iniciaa abordagem de forma mais ampla sobre o assunto estudado, passando pela explanação da proposta da estrutura analítica de riscos. A seção dois aborda de forma geral os conceitos de riscos em engenharia de software. A seção três aborda os objetivos e a importância do gerenciamento de riscos em projetos de software. A seção quatro caracteriza o ambiente de desenvolvimento de múltiplos projetos de software, trazendo a diferenciação entre o gerenciamento de portfólio de projetos e gerenciamento de múltiplos projetos. A seção cinco apresenta um dos métodos de identificação de riscos, EAR, enfatizando a taxonomia proposta pelo Software Engineering Institute (CARR et. al,1993 ). A seção seis abordou o processo metodológico de construção da EAR proposta, como também a demonstração da mesma. A seção sete destina-se a apresentar as contribuições da EAR proposta, como também os trabalhos futuros. 2. Riscos Desde os primórdios que os riscos fazem parte da vida humana. As decisões estão cercadas de possibilidades e incertezas, o que leva o homem a procurar mitigar os impactos negativos de suas escolhas (GUSMÃO, 2007). Conscientemente ou não, pessoas e organizações tomam decisões todos os dias. Entretanto, esta atividade precisa ser esclarecida, o que propiciará o entendimento sobre a natureza dos riscos. Levando assim a melhor adoção de técnicas e estratégias que diminuam ou neutralizem seus efeitos (GUSMÃO, 2007). Muitas vezes a palavra risco está associada e efeitos negativos. Entretanto, eles também podem ser oportunidades (HELDMAN, 2005).Saber gerenciar essas oportunidades se tornou peça chave para obter o sucesso do projeto. Muitas abordagens para gerenciar riscos vêm sendo propostas. Pode-se citar o modelo de Boehm (BOEHM, 1988), que propôs o ciclo de vida espiral, onde acrescentava o paradigma de gerenciamento de riscos. 3. Gerenciamento de Riscos em Projetos de Software Projetos de desenvolvimento de software estão expostos aos mais diversos tipos de eventos. Estes eventos podem tanto trazer danos como benefícios ao projeto. Em engenharia de software a área que gerencia esses eventos é gerência de riscos. Esta área é 5236
responsável por diminuir as probabilidades de fracasso do projeto, ajudando a alcançar as metas estabelecidas para o projeto. Além disso, essa importância ganha mais significado, uma vez que riscos estão sendo definidos como exposições a consequências da incerteza, sendo assim eles podem significar tanto perdas como ganhos em potencial (GUSMÃO, 2007). Sendo assim, o objetivo do gerenciamento de riscos é identificar e tratar os possíveis problemas relacionados ao projeto a fim de que seus efeitos sejam minimizados ou neutralizados; em conjunto com a identificação das possíveis oportunidades, a fim de que elas sejam aproveitadas. Neste contexto, saber gerenciar riscos tornou-se uma atividade fundamental às empresas modernas, uma vez que incertezas fazem parte dos projetos de software. Apesar do gerenciamento de riscos ser um processo de grande importância, o desenvolvimento de software, particularmente, envolve riscos imprevisíveis e difíceis de serem tratados, como exemplo: mudanças de requisitos, variações tecnológicas, etc. (KENDRICK, 2003). Este risco compromete o sucesso do projeto, impedindo que os objetivos da organização sejam alcançados. A importância do gerenciamento de riscos é amplamente reconhecida. A cada dia, mais profissionais e empresas apontam esta prática como essencial para o sucesso do projeto. Apesar disso, a aplicação do gerenciamento de riscos está abaixo da expectativa. Em parte isto pode ser explicado pelo fato de que o processo de gerenciamento de riscos é complexo, e isso torna-se ainda mais difícil em um ambiente de múltiplos projetos (GUSMÃO, 2007). 3.1. Atividades da Gerência de Riscos O processo de gerenciamento de riscos é desenvolvido como um processo iterativo, com atividades sequênciais, de modo que possibilite a tomada de decisão e o desempenho organizacional. Nos tópicos a seguir, serão apresentados os 5 processos de gerenciamento de riscos de acordo com o Guide to the Project Management Body of Knowledge Guia PMBOK (PMI, 2013). 3.1.1. Planejamento do Gerenciamento de Riscos Neste processo é definido como as atividades de gerenciamento de riscos serão conduzidas. Onde as equipes de planejamento fazem reuniões para desenvolver o plano de gerenciamento de riscos, que contém as diretrizes adotadas para o projeto como: prazos, orçamento, metodologia, papéis e responsabilidades. Este processo é importante, pois garante a visibilidade dos riscos no projeto. 3.1.2. Identificação de Riscos Este processo identifica e documenta os riscos que podem afetar o projeto. A documentação dos riscos permite à equipe melhor conhecê-los, para assim tomar as devidas decisões. Por ser um processo iterativo, novos riscos vão sendo documentados ao longo do projeto, à medida que forem sendo considerados como ameaças ou oportunidades. O envolvimento de toda a equipe na identificação de riscos contribui para o aumento do número e riscos identificados, ajudando assim tanto no presente projeto, como nos que serão desenvolvidos futuramente. 3.1.3. Análise de Riscos 5237
Após os riscos serem identificados, nesta etapa eles são avaliados de acordo com a sua probabilidade de ocorrência e impacto. Existem duas maneiras de analisar os riscos: Análise Qualitativa dos Riscos: Esta análise prioriza os riscos identificados de acordo com a probabilidade de ocorrência e seu impacto no projeto. Análise Quantitativa dos Riscos: Com o objetivo de servir de base para a tomada de decisões, a análise quantitativa de riscos analisa numericamente os impactos que os riscos identificados podem trazer ao projeto. 3.1.4. Planejar Respostas aos Riscos Nesta fase desenvolvem-se as ações necessárias para mitigar as ameaças e aumentar as oportunidades. Este processo ajuda o gerente a direcionar seus esforços para os riscos considerados como prioritários. 3.1.5. Controle de Riscos Esta fase tem como objetivo verificar a eficiência do processo de riscos durante todo ao projeto. Com esta verificação, é possível corrigir os possíveis erros cometidos durante o projeto, melhorando assim, o processo de gerenciamento.entre outros benefícios pode-se citar a atualização de riscos identificados e lições aprendidas, que também servirão de suporte em projetos futuros. É importante ressaltar que o monitoramento de riscos deve ser realizado durante todo o projeto. 4. Ambientes de Múltiplos Projetos O desenvolvimento de um produto é composto pela organização de várias tarefas que podem ser executadas de várias maneiras. Saber gerenciar essas atividades veem ganhando notoriedade com o surgimento da área de gerência de projetos, onde o sucesso das empresas depende em grande parte do resultado de seus projetos. Para aumentar a eficácia e a eficiência do processo de desenvolvimento, novas abordagens estão sendo introduzidas (DANILOVIC; BÖRJESSON, 2001). Atualmente, devida à alta demanda por soluções em software, dificilmente as empresas desenvolvedoras de software realizam um projeto por vez. Nesse ambiente, as empresas têm que lidar com os diferentes objetivos de cada projeto, onde cada projeto pode ser influenciado por outros que estejam sendo executados simultaneamente. Ao mesmo tempo em que há dificuldade em alocar recursos, onde, de certa forma, todos os projetos são inter-relacionados e interdependentes. Isso cria uma estrutura multi-nível chamado ambiente de multiprojetos (DANILOVIC; BÖRJESSON, 2001). 4.1 Gerenciamento de Portfólio de Projetos É comum a mistura entre os conceitos de gerenciamento de portfólio e gerenciamento de múltiplos projetos. Por isso é importante ressaltar a diferença entre eles. Com a multiplicidade de projetos sendo desenvolvidos simultaneamente, a gestão precisa avaliar e priorizar os projetos que serão desenvolvidos para que o plano estratégico da empresa seja atingido. Então há a seleção para executar os projetos que se enquadrem nos objetivos da empresa. Já a gerência de múltiplos projetos se encarrega de distribuir e controlar os recursos entre os diversos projetos sendo executados simultaneamente, considerando as particularidades de cada um deles. 5. Estrutura Analítica de Riscos 5238
Uma das formas de proporcionar melhorias em ambientes de desenvolvimento de software é através do uso de métodos, técnicas e ferramentas. Que têm como objetivo acelerar processos, produzir estimativas precisa e garantir a qualidade do processo e do produto. Na literatura são encontrados diversos tipos de processos e ferramentas para incorporar à gerência de riscos. Neste contexto está inserida a Estrutura Analítica de Riscos (EAR), que é uma forma de representar categoricamente os riscos em diversos níveis. Uma EAR serve de apoio para a identificação de riscos através da organização por categorias. Os riscos encontrados são inseridos nas categorias existentes. Este é um processo iterativo, onde novos riscos podem ser inseridos a medida que forem sendo identificados. Abaixo, na figura 1, está um exemplo de uma EAR segundo o PMBOK (2013): Figura 1. Exemplo de Estrutura Analítica de Riscos (EAR) (PMBOK, 2013) A Estrutura Analítica de Riscos mostra a sua importância através de benefícios como: facilitar a comunicação e a compreensão dos riscos, permite a inserção de novos riscos a medida que eles forem encontrados, ajuda a tomada de decisão através dos riscos catalogados, entre outros. 5.1 Taxonomia do SEI A taxonomia de riscos produzida pela SEI (Software Engineering Institute) fornece um método estruturado disciplinado para a gestão de riscos em desenvolvimento de software. A taxonomia também serve como base para o desenvolvimento de outros métodos e atividades para o gerenciamento de riscos (CARR et al, 1993). 5239
Figura 2. Estrutura Analítica de Riscos em Desenvolvimento de Software (CARR et al, 1993) Conforme apresentado na figura 2, a taxonomia do SEI está organizada em três classes principais: Engenharia de Produto: Refere-se aos aspectos técnicos do trabalho desenvolvido. Ambiente de Desenvolvimento: Refere-se aos procedimentos, ferramentas e métodos utilizados no desenvolvimento do produto. Restrições de Programa: Refere-se aos fatores contratuais, operacionais e organizacionais do projeto de desenvolvimento de software, mas que estão fora do controle da gestão. 6. Proposta de EAR para Ambientes de Múltiplos Projetos A construção da EAR proposta no presente artigo foi feita tendo como base o trabalho de Almeida e demais autores (2012), com o objetivo de avaliar e propor melhorias na Estrutura de Riscos já existente, pois após uma revisão bibliográfica foram encontrados riscos considerados relevantes. Além disso, é notória a necessidade de evolução de estudos e pesquisas na área de Gerenciamento de Riscos no contexto de Múltiplos Projetos de Software. Sendo assim, a EAR proposta contém a categorização de novos riscos encontrados na literatura de engenharia de software. Tornando-se uma ferramenta mais completa e abrangente que auxiliará no processo de gerenciamento de riscos. a EAR proposta por Almeida e demais autores (2012) foi construída a partir da taxonomia de riscos desenvolvida pelo SEI. Essa escolha, segundo os autores, se deve ao fato de que a EAR do SEI consiste em uma estrutura hierárquica já consolidada, além de mapear características genéricas e processos de desenvolvimento de software (ALMEIDA et al, 2012). A EAR proposta no presente trabalho foi feita em três etapas. Na primeira foi feita uma revisão bibliográfica com o objetivo de coletar riscos presentes em ambientes de múltiplos projetos de software. Após a coleta, a segunda etapa consistiu na inserção dos riscos 5240
encontrados e a sua categorização para serem melhor entendidos. Com isso, foi feita uma análise desta EAR, onde foi notado que novos riscos considerados relevantes não estavam presentes. Por fim, na terceira etapa, os riscos coletados na revisão bibliográfica foram agregados à EAR 6.1. Revisão Bibliográfica Esta etapa consistiu na busca por trabalhos que apresentassem fatores de riscos identificados em projetos de software a fim de aprimorar a EAR. A seguir será descrito o passo-a-passo da pesquisa bibliográfica. 6.1.1. Processo de Busca O processo de busca foi feito nas seguintes bases de dados: IEEE Xplore 1. Google Scholar 2. O IEEE Xplore é uma biblioteca digital que disponibiliza conteúdos técnicos e científicos publicados pelo IEEE (Institute of Electrical and Electronics Engineers). O Google Scholar é uma ferramenta de pesquisa para literatura acadêmica, abrangendo as mais diversas disciplinas e modalidades de trabalhos (livros, teses, artigos, dissertações entre outros). O objetivo da pesquisa foi encontrar trabalhos relacionados a riscos em projetos de software. Para isso, as pesquisas foram feitas através do uso das seguintes palavraschaves: Software Project Risk Software Project Software Development Desenvolvimento de software Identificação riscos software Identification risks software Riscos projetos software Gerenciamento riscos software Risk management software 6.1.2. Critérios de Aceitação Os trabalhos retornados pela pesquisa passaram por um processo de avaliação, onde primeiramente foram analisados seus títulos e resumos para verificar a compatibilidade com o tema pesquisado. Os trabalhos que se enquadraram com o objetivo da pesquisa foram salvos para posteriormente serem lidos por completo. No total foram salvos 23 trabalhos. 6.1.3. Coleta dos Fatores de Riscos Os trabalhos salvos na etapa anterior foram lidos por completo. A leitura pretendia confirmar se os trabalhos salvos realmente se enquadravam no objetivo pesquisado. Do total de 23 trabalhos salvos, após a leitura a penas 13 foram considerados relevantes para a pesquisa. Através desta leitura, foram extraídos os fatores de riscos para múltiplos projetos de software. Todos os fatores de riscos foram listados em um documento para poderem ser analisados a fim de se eliminar as redundâncias e os fatores de risco duplicados. 1 http:// ieeexplore.ieee.org/ 2 http://scholar.google.com/ 5241
6.1.4. Construção da Estrutura Analítica Proposta Os fatores de riscos redundantes e duplicados foram eliminados da listagem. O total de fatores de riscos resultantes após a filtragem de acordo com as classes em que foram inseridos foi: Engenharia de Produto: 35 Ambiente de Desenvolvimento: 72 Restrições de Programa: 26 No total foram mapeados 133 novos fatores de riscos que encontram-se representados graficamente de acordo com suas classes na figura 3: 80 70 Total de fatores de riscos 60 50 40 30 20 10 0 Engenharia de Produto Ambiente de Desenvolvimento Restrições de Programa Figura 3. Fatores de Riscos para Ambientes de Múltiplos Projetos de Software por Classe Após uma análise, os fatores de riscos foram classificados de acordo com os elementos mais compatíveis. Abaixo, na tabela 1, está a número dos fatores de riscos de acordo com os elementos em que foram distribuídos: Elementos Quantidade Requisitos 11 Design 9 Codificação e teste unitário 3 Integração e teste 3 Eng. de especialidades 9 Processo de desenvolvimento 21 Sistema de desenvolvimento 8 Processo de gerenciamento 20 Métodos de gerenciamento 7 Ambiente de trabalho 16 5242
Recursos 6 Contrato 4 Interfaces de programa 16 Tabela 1. Fatores de Riscos para Ambientes de Múltiplos Projetos de Software por Elementos Os fatores de riscos foram organizados numa planilha com a mesma estrutura feita por Almeida e demais autores (2012). Para cada atributo foi feita uma análise para saber em qual classe da estrutura analítica de riscos ele se encaixaria. A Tabela 2 mostra parcialmente onde são apresentados os fatores de risco relacionados a fonte de risco Requisitos, da classe Engenharia de Produto. Risco Nível 0 Classes Nível 1 Fontes de Riscos Nível 2 ID do Fator de Risco Fatores de Risco Nível 3 Riscos de Desenvolvimento de Software Engenharia de Produto Requisitos 1 Granularidade adequada ao desenvolvimento de software 2 Gold-Plating 3 Requisito padrão 4 5 Adequação ao tamanho e complexidade do projeto Requisitos conflitantes Tabela 2. Disposição dos Fatores de Riscos Encontrados de Acordo com a Taxonomia do SEI Parcial 6.2. Principais Resultados e Discussões A medida que as pesquisas sobre gerenciamento de riscos em projetos de software avança, também crescem os riscos identificados. Nesse contexto é notória a necessidade de aprimorar as ferramentas existentes para que melhor auxiliem seus usuários, neste caso os gerentes de projetos. Os resultados da pesquisa não somente contribuiu para o aprimoramento da EAR, mas como também para a identificação dos fatores de riscos mais citados na literatura de engenharia de software. Neste sentido foi observado que os fatores de riscos relacionados a processos de gerenciamento são os mais citados pelos autores, isto evidencia como as práticas de gerenciamento de projeto são importantes para o sucesso do mesmo. 5243
Outro fator de risco bastante citado na literatura foi em relação aos preocessos de desenvolvimento, onde os paradigmas, práticas e ferramentas usadas auxiliam no desenvolver do produto software. O conhecimento acerca destas informações sobre os riscos auxiliam tanto o gerente como a sua equipe a melhor lidar com os possíveis eventos que possam afetar o projeto. 7. Conclusões e trabalhos em andamento Atualmente, o uso das tecnologias está presente nas mais diversas atividades humanas. Isso levou a um aumento da demando por soluções em software, onde empresas desenvolvedoras de software executam mais de um projeto simultaneamente para conseguir dar conta da demanda. Somando-se a isso, tem-se a necessidade de gerenciar os ricos inerentes a todo projeto de software. Precisando de uma gerência que mitigue os riscos que podem causar danos ao projeto. Neste contexto, a Estrutura Analítica de Riscos é uma importante ferramenta que auxilia no gerenciamento de riscos, no sentido de identificá-los e catalogá-los hierarquicamente, ajudando o gerente e sua equipe. Este artigo teve como objetivo avaliar e aprimorar a EAR proposta por Almeida, Venâncio e Gusmão (2012), pois através de pesquisa bibliográfica foram encontrados riscos considerados relevantes. Durante a pesquisa bibliográfica foram encontrados 133 fatores de risco para ambiente de múltiplos projetos de software que foram distribuídos entre os elementos da EAR após uma análise que identificou em qual elemento o fator de risos melhor se encaixaria. O resultado disto foi uma EAR mais abrangente, que auxiliará os gerentes e suas equipes a melhor identificar os riscos em seus projetos, tanto os atuais, como os futuros. Através deste mapeamento foi possível identificar que os riscos mais citados na literatura são oriundos do processo de gerenciamento e do processo de desenvolvimento. Isso permite ao gerente maior percepção dos riscos associados ao seu processo de desenvolvimento, como também permite a equipe identificar quais os possíveis riscos que podem aparecer durante o processo de desenvolvimento do software. A Estrutura Analítica de riscos fornece suporte à identificação de riscos e também a incorporação de novos à medida que forem sendo encontrado. Com o avanço das pesquisas em gerenciamento de riscos em projetos de software, e através do mapeamento sistemático em outras bases de dados será possível encontrar novos fatores de riscos para ambientes de múltiplos projetos de software. Através do mapeamento sistemático da literatura, foi elaborada uma EAR mais abrangente que auxiliará no processo de gerenciamento de riscos, através de uma forma categorizada que permitirá a sua adequação em diferentes projetos de software. Como continuidade a esse trabalho, no próximo passo será feito um estudo comparativo entre as abordagens de cálculo de similaridade para relacionar as características dos projetos de software. O objetivo deste estudo é fazer uma comparação entre as principais abordagens de cálculo de similaridade. O resultado final desta etapa é escolher o método que melhor se adéqüe ao contexto de ambiente de múltiplos projetos de software de acordo com o desempenho e métricas estabelecidas, gerando novos trabalhos que apresentem os resultados das avaliações com as lições aprendidas. Agradecimentos Os autores agradecem ao CNPq pelo apoio necessário à realização deste trabalho. 5244
Referências ANDRADE, M. J. et al. Consequências e Características de um Processo de Desenvolvimento de Software de Qualidade e Aspectos que o Influenciam: uma avaliação de especialistas. BARRETO, A. O. S.; ROCHA, A. R. Analyzing the Similarity among Software Projects to Improve Software Project Monitoring Processes. In: Seventh International Conference on the Quality of Information and Communications Technology, 2010. BOEHM. B. W.: A spiral model for software development and enhancement. IEEE Computer, 21 (5), 1988. p. 61-72. CARR, M. J. et al. Taxonomy Based Risk Identification. RelatórioTécnico. Pittsburgh. 1993. DANILOVIC, M.; BÖRJESSON, H. Managing the MultiprojectEnviroment. In: The Third Dependence Structure Matrix (DSM) International Workshop, 2001, Boston. Proceedings. GUSMÃO, C. M. G. Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento de Software. Tese de Doutorado em Ciências da Computação. Centro de Informática. Universidade Federal de Pernambuco/Brasil. 2007. HELDMAN, K. Project Manager s Spotlight on Risk Management. (Harbor Light Press, Ed.). San Francisco. 2005. HILLSON, D. The Risk Breakdown Structure (RBS) as an Aid to Effective Risk Management. Fifth European Project Management Conference. Cannes. 2002. KENDRICK, T. Identifying and managing project risk: essential tools for failureproofingyour project. 1.a. ed. New York, NY, USA: Amacom, 2003. PMBOK, G. Um guia do conhecimento em gerenciamento de projetos. 5 o Pensilvânia. 2013. Edição. PORTO, Maria Alice Guedes; BANDEIRA, Anselmo Alves. O processo decisório nas organizações. In: SIMPEP, 13., 2006, Bauru. São Paulo, 2006. 5245