Estudo comparativo das metodologias de gestão de projetos
Abstract
Cada vez mais a gestão de projetos tem assumido um papel preponderante no que concerne ao sucesso de um projeto e ao seu desenvolvimento. Desta forma, o interesse nesta área tem vindo a aumentar e tem feito com que as organizações adotem metodologias ou normas que lhes permitam atingir esse sucesso, adaptando-as às suas necessidades. Existem diversas metodologias que podem ser adotadas e personalizadas às características de cada organização. Contudo, cada projeto é único e existem diversos tipos de projeto no que diz respeito à complexidade ou risco e por este motivo, a mesma abordagem pode não funcionar em qualquer um. Com vista a auxiliar as organizações e os gestores de projeto e a simplificar esta questão, este estudo tem como objetivo desenvolver uma proposta de modelo comparativo. Para isso será desenvolvido um estudo intensivo das metodologias de gestão de projeto e, de entre as mais utilizadas no setor das TI, foram selecionadas e analisadas cinco metodologias. São ainda identificados modelos de categorização de projetos na literatura e é identificado um dos modelos para adaptação às metodologias de gestão de projeto analisadas. Esta comparação poderá ser utilizada como meio de consultoria para melhoria do posicionamento da organização no que respeita à seleção da metodologia de gestão de projeto mais adequada, tendo em conta as suas necessidades e de acordo com determinadas dimensões.
Full text
Universidade do Minho Escola de Engenharia Beatriz Araújo Azevedo Estudo Comparativo das Metodologias de Gestão de Projetos Outubro de 2022 Estudo Comparativo das Comparativo de Gestão de Projetos Beatriz Araújo Azevedo UMinho | 2022
Beatriz Araújo Azevedo a86577 Estudo Comparativo das Metodologias de Gestão de Projetos Outubro de 2022 Dissertação de Mestrado Mestrado integrado em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação do Professor Doutor Pedro Miguel Gonzalez Abreu Ribeiro
DIREITOS DE AUTOR 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/
v AGRADECIMENTOS Ao Professor Doutor Pedro Ribeiro, pela disponibilidade, passagem de conhecimento, prontidão, orientação e pelo apoio fornecido ao longo desta etapa e nas fases de bloqueio. À minha irmã e aos meus pais, pelo incentivo e constante motivação nos momentos certos. Aos meus amigos, pelo constante companheirismo e que sempre acreditaram em mim e me incentivaram a dar o meu melhor. Nenhum percurso é feito individualmente e por isso, o meu eterno agradecimento e reconhecimento a todos os que, de alguma forma, participaram nesta etapa.
vi 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. Universidade do Minho, 29 de outubro de 2022 Assinatura:
vii RESUMO Estudo Comparativo das Metodologias de Gestão de Projetos Cada vez mais a gestão de projetos tem assumido um papel preponderante no que concerne ao sucesso de um projeto e ao seu desenvolvimento. Desta forma, o interesse nesta área tem vindo a aumentar e tem feito com que as organizações adotem metodologias ou normas que lhes permitam atingir esse sucesso, adaptando-as às suas necessidades. Existem diversas metodologias que podem ser adotadas e personalizadas às características de cada organização. Contudo, cada projeto é único e existem diversos tipos de projeto no que diz respeito à complexidade ou risco e por este motivo, a mesma abordagem pode não funcionar em qualquer um. Com vista a auxiliar as organizações e os gestores de projeto e a simplificar esta questão, este estudo tem como objetivo desenvolver uma proposta de modelo comparativo. Para isso será desenvolvido um estudo intensivo das metodologias de gestão de projeto e, de entre as mais utilizadas no setor das TI, foram selecionadas e analisadas cinco metodologias. São ainda identificados modelos de categorização de projetos na literatura e é identificado um dos modelos para adaptação às metodologias de gestão de projeto analisadas. Esta comparação poderá ser utilizada como meio de consultoria para melhoria do posicionamento da organização no que respeita à seleção da metodologia de gestão de projeto mais adequada, tendo em conta as suas necessidades e de acordo com determinadas dimensões. Palavras chave: Comparação de Metodologias de Gestão de Projetos, Gestão de Projetos, Metodologias de Gestão de Projetos, Tecnologias e Sistemas de Informação
viii ABSTRACT Comparison Study of Project Management Methodologies Project management has increasingly assumed a leading role in terms of the success of a project and its development. In this way, the interest in this area has been increasing and has made organizations adopt methodologies or standards that allow them to succeed, adapting them to their needs. Many methodologies can be adapted and customized to the characteristics of each organization. However, each project is unique and there are different types of projects concerning complexity or risk. For this reason, the same approach may not work for every project. To help organizations and project managers deal with this issue, the objective of this study is to develop a comparison model. According to that, an intensive study of the standards will be developed and five methodologies were selected and analyzed, between the most used standards in project management in the IT sector. Some project categorization models are also identified in the literature and one of them is selected to adapt to the project management methodologies. This comparison can be used as a consulting basis to improve the organization's positioning regarding the selection of the most appropriate methodology, considering their needs. Keywords: Project Management, Project Management Methodologies Comparison, Project Management Methodologies, Technologies and Information Systems
ix ÍNDICE Direitos de autor ................................................................................................................................. iv Agradecimentos ................................................................................................................................... v Declaração de integridade .................................................................................................................. vi Resumo............................................................................................................................................. vii Abstract............................................................................................................................................ viii Lista de abreviaturas/Siglas ................................................................................................................ xi Lista de figuras .................................................................................................................................. xii Lista de tabelas ................................................................................................................................ xiii 1. Introdução .................................................................................................................................. 1 1.1 Contextualização e Motivação .............................................................................................. 1 1.2 Finalidade e Objetivos .......................................................................................................... 2 1.3 Estrutura da Dissertação ...................................................................................................... 2 1.4 Abordagem de Investigação ................................................................................................. 3 2. Revisão de Literatura .................................................................................................................. 6 2.1 Gestão de Projetos ............................................................................................................... 6 2.1.1 Contextualização .......................................................................................................... 6 2.1.2 Ciclo de Vida de um Projeto .......................................................................................... 8 2.1.3 Gestão de Projetos em SI/TI ....................................................................................... 10 2.1.4 Abordagens (Tradicional vs. Ágeis) .............................................................................. 12 2.2 Metodologias de Gestão de Projeto ..................................................................................... 14 2.2.1 Contextualização ........................................................................................................ 14 3. Estudo das Metodologias de Gestão de Projeto .......................................................................... 15 3.1.1 PMBOK – 6ª Edição ................................................................................................... 15 3.1.2 PMBOK – 7ª Edição ................................................................................................... 20
3 O primeiro capítulo diz respeito à introdução da dissertação e contempla nas suas subdivisões a contextualização, a finalidade, os objetivos da mesma, a estrutura e a abordagem de investigação utilizada no contexto do estudo a desenvolver. O segundo capítulo trata a revisão de literatura, onde são abordados os conceitos mais relevantes, de forma a contribuir para uma melhor compreensão da temática explorada neste documento e que permitirá também criar a base de conhecimento para as fases subsequentes. O terceiro capítulo contempla o foco primordial da dissertação - o estudo das metodologias, guias e referenciais. Aborda também na sua estrutura o estudo de modelos de categorização de projetos existentes na literatura. O quarto capítulo é suportado pela investigação resultante da revisão de literatura, ou seja, é possível encontrar a proposta de um modelo comparativo tendo por base o referencial de um modelo de categorização de projetos e a respetiva descrição. No quinto capítulo será apresentado um caso real da aplicabilidade do modelo estudado sobre vários projetos da mesma organização e respetivo enquadramento com a proposta de modelo comparativo. Os resultados obtidos são também parte integrante deste capítulo. Seguidamente, no sexto capítulo, consta a conclusão da investigação desenvolvida, assim como uma proposta de trabalho futuro. 1.4 Abordagem de Investigação Nesta secção encontra-se a abordagem de investigação utilizada na dissertação. Após analisar algumas das metodologias propostas na literatura, nomeadamente a Design Science Research , foi utilizada uma abordagem específica e simplificada com base nesta análise. Optou-se por utilizar esta abordagem específica, tendo em conta o objetivo primordial da dissertação e a forma como este estudo se encontra estruturado. Na primeira secção serão apresentadas as guidelines utilizadas para uma maior perceção da temática estudada, para o estudo das metodologias, o desenvolvimento do modelo comparativo e conclusões retiradas. Na Figura 1 é possível representar o processo descrito detalhadamente a seguir.
4 Figura 1 - Método de investigação utilizado 1.4.1 Perceção da temática Para uma maior perceção dos assuntos abordados nesta dissertação, foram reunidos e apresentados alguns conceitos relevantes. Assim, é feita uma revisão de literatura onde são considerados conceitos nomeadamente, conceitos de GP, projeto, ciclo de vida de um projeto, metodologias de GP, entre outros. Assim, obtém-se um conjunto de premissas capazes de fundamentar o modelo a desenvolver. A estratégia de pesquisa utilizada para a revisão de literatura baseou-se em bases de dados tais como: ✓ Scopus; ✓ Google Scholar; ✓ ResearchGate; ✓ Institute of Electrical and Electronics Engineers ; ✓ Science Direct. Durante o processo de seleção de artigos, livros e dissertações foi necessário utilizar keywords relativas ao tema da dissertação, tais como “ Project management ”, “ Information systems ”, “ Project management methodologies ”, “ Project Management Information Systems ”, “ Information technology ”, “ Agile ”, “ Project Categorization ”, entre outros. Após o resultado dos documentos obtidos, o passo seguinte para excluir os artigos menos relevantes foi através do título destes e posteriormente o resumo de cada um. Aquando da identificação dos artigos mais relevantes no contexto da dissertação, a estratégia seguinte passou pela leitura dos documentos selecionados.
5 1.4.2 Estudo e análise das metodologias Nesta fase concentra-se o foco principal do estudo da dissertação. Foram selecionadas cinco metodologias mais destacadas na área das TI e SI e é feita uma leitura integral das mesmas, sendo possível verificar uma síntese de cada uma. Com este estudo e posterior análise, verificou-se que, devido à sua capacidade de adaptação ao contexto organizacional existiria uma dificuldade acrescida em recolher critérios que permitissem compará-las. Neste sentido, foi necessário recorrer à análise e estudo de modelos de categorização de projetos para a sua posterior seleção. 1.4.3 Desenvolvimento do modelo comparativo No presente estudo a proposta de solução consubstanciar-se-á no desenvolvimento de um modelo que permita identificar as divergências e semelhanças entre as metodologias de GP estudadas. Assim, é apresentada uma proposta de solução, tendo por base o referencial de um modelo de categorização, adequado às metodologias em questão. Para esta fase recorreu-se às seguintes atividades: ✓ Enquadramento de cada metodologia às dimensões do modelo; ✓ Justificação da adequação das características da metodologia às características do nível do modelo; ✓ Representação gráfica de cada metodologia no modelo comparativo. 1.4.4 Conclusões Esta fase contempla uma discussão dos resultados obtidos e é apresentado um caso demonstrativo de sucesso e real da utilização do modelo adotado em contexto organizacional. Esta situação real é aplicada ao modelo comparativo desenvolvido no contexto desta dissertação. Adicionalmente, é possível encontrar uma interpretação e discussão das conclusões relativas à solução desenvolvida, à sua aplicabilidade, limitações e nas recomendações para trabalhos futuros.
6 2. REVISÃO DE LITERATURA 2.1 Gestão de Projetos 2.1.1 Contextualização As organizações têm vindo a mudar de uma abordagem hierárquica para GP de forma a tornarem-se mais colaborativa (Fernandez & Fernandez, 2008). A abordagem de GP é caracterizada por métodos de reestruturação e adaptação de técnicas de gestão, com o objetivo de obter um melhor controlo e uso de recursos existentes (Kerzner, 2003). O Project Management Institute (PMI) apresenta a GP no PMBOK como a “aplicação de conhecimentos, capacidades, ferramentas e técnicas às atividades de um projeto de forma a atender aos seus requisitos” (PMI, 2021). PRojects IN Controlled Environments (PRINCE2) define a GP como o “planeamento, atribuição, monitorização e controlo de todos os aspetos do projeto e a motivação dos envolvidos para atingir os objetivos do projeto dentro das metas esperadas em termos de tempo, custo, qualidade, âmbito, benefícios e riscos” (Bennett et al., 2017). A International Organization for Standardization (ISO) define a GP como “atividades coordenadas para dirigir e controlar a realização dos objetivos acordados” (ISO, 2021). Turner salienta cinco princípios de uma boa GP, enunciados a seguir: ✓ Gerir com base numa estrutura subdividida; ✓ Foco nos resultados, o que atingir e não como fazê-lo; ✓ Equilibrar os resultados através da estrutura subdividida; ✓ Organizar o projeto através de um contrato com as partes envolvidas; ✓ Adotar uma estrutura de relatório de gestão clara e simples (Turner, 1996). Segundo Kerzner, os potenciais benefícios da GP, segundo o autor, são: ✓ Identificação de responsabilidades funcionais para garantir que todas as atividades sejam contabilizadas, independentemente da rotatividade; ✓ Minimizar a necessidade de relatórios contínuos; ✓ Identificação dos limites de tempo para agendamento; ✓ Identificação de uma metodologia para análise de trade-off ; ✓ Medição do cumprimento dos planos;
7 ✓ Identificação precoce de problemas de forma a iniciar a ação corretiva; ✓ Capacidade de estimativa melhorada para planeamento do futuro; ✓ Saber quando é que os objetivos não podem ser atingidos ou serão excedidos (Kerzner, 2003). Na GP são definidas diversas áreas e cada uma delas é descrita apresentando o respetivo processo de gestão e definindo as atividades do processo através dos seus inputs , ferramentas, técnicas usadas e outputs (Bērziša & Grabis, 2009). Esta “cobre todos os processos de gestão de projetos relacionados com o planeamento, controlo e coordenação de projetos” (Ahlemann, 2009). No PMBOK, o gestor de projeto é caracterizado como a “pessoa atribuída pela organização para liderar a equipa de projeto que é responsável por atingir os objetivos do projeto. Os gestores de projeto executam uma variedade de funções, tais como facilitar o trabalho da equipa do projeto para alcançar os resultados e gerir os processos para entregar os resultados pretendidos” (PMI, 2021). Segundo Kerzner, o gestor de projeto é “responsável por coordenar e integrar atividades em várias linhas funcionais”. Estas atividades incluem integrar as atividades necessárias de forma a desenvolver um plano de projeto, executar esse plano e fazer alterações no mesmo (Kerzner, 2003). Para isso é necessário que os gestores tomem decisões de forma rápida, aloquem os recursos escassos de forma eficiente e tenham um foco bem definido (Caniëls & Bakens, 2012). Kerzner projetou uma representação da GP, através do recurso aos elementos tempo, custo e execução. O objetivo desta é demonstrar o potencial da GP na gestão dos recursos de uma organização de uma determinada atividade, tendo em conta estes três pilares (Kerzner, 2003). Figura 2 - Visão geral da GP (Kerzner, 2003)
8 No PMBOK um projeto é descrito como um “esforço temporário para criar um produto, serviço ou resultado exclusivo. A natureza temporária dos projetos indica um início e um fim para o trabalho do projeto ou uma fase do trabalho” (PMI, 2021). Segundo Kerzner, um projeto pode ser definido como qualquer série de atividades e tarefas que: ✓ Tem um objetivo específico a ser cumprido com determinadas especificações; ✓ Tem definidas datas de início e fim; ✓ Tem limites financeiros (se aplicável); ✓ Consome recursos humanos e não humanos (por exemplo dinheiro, pessoas, equipamento); ✓ São multifuncionais (Kerzner, 2003). Um projeto é considerado temporário visto que tem um início e fim bem definidos, o seu output é único e pode ser um produto ou um serviço. Assim, os projetos são definidos, planeados e executados sob certas restrições externas que podem estar relacionadas com o cronograma, orçamento, qualidade, mas também ao ambiente organizacional do projeto (European Commission, 2018). Figura 3 - Características de um projeto (European Commission, 2018) 2.1.2 Ciclo de Vida de um Projeto No PMBOK consta que o ciclo de vida de um projeto é uma “série de fases pelas quais um projeto passa desde o seu início até à sua conclusão” (PMI, 2021). Cada uma destas fases permitem aos gestores um melhor controlo dos recursos de forma a atingir os objetivos propostos. Atualmente não existe um consenso no que concerne às fases do ciclo de vida de um projeto devido à complexidade da natureza e à diversidade dos projetos (Kerzner, 2003). Contudo, e segundo Kerzner, as definições teóricas relativas às fases do ciclo de vida de um projeto encontram-se apresentadas na Tabela 1.
9 Tabela 1 - Fases do ciclo de vida de um projeto – Adaptado de Kerzner (2003) Fase do ciclo de vida do projeto Descrição Concetual Avaliação preliminar de uma ideia; Planeamento Refinamento da fase anterior, identificação dos recursos necessários e definição dos parâmetros relativos ao tempo, custo e desempenho; Teste Teste final para que as operações possam ser iniciadas; Implementação Integração do produto ou serviço na organização; Encerramento Encerramento do projeto e realocação dos recursos. Contudo, nem a todos os projetos se podem aplicar estas fases, como por exemplo em projetos de Pesquisa e Desenvolvimento (Kerzner, 2003). Figura 4 - Ciclo de vida de um projeto (Kerzner, 2003) À semelhança da abordagem anterior de Kerzner, também o PM2 utiliza quatro fases do ciclo de vida de um projeto, contemplando nestas os cinco processos, tais como a Iniciação, Planeamento, Execução, Monitorização e Controlo e por fim o Encerramento. ✓ Fase de Iniciação: durante esta fase as informações básicas são recolhidas, avaliadas e decisões são tomadas; ✓ Fase de Planeamento: estabelecer a abordagem a adotar no projeto e planear como alcançar os resultados desejados em termos de âmbito, cronograma e custo; ✓ Fase de Implementação: implementar o plano de projeto de forma a produzir os entregáveis acordados e garantir que as expectativas são cumpridas;
10 ✓ Fase de Encerramento: conclusão do projeto com a garantia de que o mesmo foi entregue de acordo com o esperado e que haja aceitação final para o encerrar (Kerzner, 2010). Esta abordagem de fases do ciclo de vida do projeto fornece uma metodologia de uniformização do planeamento do projeto e permite ter um maior controlo sobre este. Para isso existe, no fim de cada fase, uma reunião para avaliar o que foi cumprido na presente fase e obter aprovação para a seguinte (Kerzner, 2003). Segundo o PMI, no PMBOK, o tipo e número de fases num ciclo de vida de um projeto depende sobretudo da entrega do mesmo e da abordagem de desenvolvimento (PMI, 2021). 2.1.3 Gestão de Projetos em SI/TI O rápido desenvolvimento das TI terá profundas ramificações para a GP, principalmente na forma como os projetos são planeados e geridos no futuro. Não só facilitará a automação e integração de todas as atividades ao longo do ciclo de vida do projeto, como também permitirá que um maior número de opções, produtos e soluções sejam considerados (Ahlemann, 2009). Na última década, devido ao aumento da diversidade de tipos de projetos e complexidade, os SI que suportam a GP, normalmente chamados de Project Management Information Systems (PMIS), têm mudado consideravelmente (Teixeira et al., 2016). Já não se concentram apenas no agendamento e na gestão de recursos e em vez disso, tornaram-se sistemas abrangentes que suportam todo o ciclo de vida, os programas e os portfolios dos projetos (Ahlemann, 2009). Um PMIS é um “sistema que suporta e facilita a entrega de qualquer projeto, principalmente os mais complexos, sujeitos a incerteza, sob pressões de mercado, tempo e dinheiro ou com dificuldades de gestão”. Salienta-se a sua necessidade devido ao fornecimento de informações às equipas de projeto, proporcionando um feedback de desempenho relativo ao tempo, nomeadamente onde é que o projeto se encontra relativamente aos objetivos propostos (Jaafari & Manivong, 1998). Estes consideram-se ferramentas bastante importantes que podem contribuir para o sucesso de um projeto, no sentido em que podem ajudar a planear o trabalho, facilitar o controlo e o desenvolvimento das tarefas, promover a supervisão de todas as atividades e potenciar a execução do trabalho de acordo com as deadlines estabelecidas, envolvendo as pessoas certas e reduzindo os desvios do orçamento
11 (Teixeira et al., 2016). Assim, a utilização de métodos de GP e o seu processamento usando um PMIS ajuda a aumentar a taxa de sucesso de um projeto (Kostalova et al., 2015). Os PMIS devem fornecer aos gestores de projeto apoio na tomada de decisão para planear, organizar e controlar projetos, tendo sidas registadas melhorias na eficácia e eficiência nas tarefas relacionadas com a gestão. Este tipo de sistemas tem um impacto direto no sucesso do mesmo no que concerne ao controlo do orçamento, cumprimento de prazos e especificações técnicas. Para além disto, a qualidade da informação está diretamente relacionada com o uso de PMIS e os impactos do sistema no gestor de projeto (Raymond & Bergeron, 2008). Na figura abaixo está representada a natureza e o papel de um PMIS num sistema de GP, "subserviente ao alcance dos objetivos do projeto e à implementação das estratégias do projeto" (Raymond & Bergeron, 2008). Figura 5 - PMIS num sistema de GP (Raymond & Bergeron, 2007) Existem estudos que têm demonstrado que existem vários fatores importantes que incentivam os gestores de projeto a usar o PMIS. Primeiro, os gestores de projeto usarem-no ou não depende da qualidade das informações geradas pelo mesmo. Em segundo lugar, os gestores de projeto mostram-se mais ansiosos para usar um SI, se este lhes fornecer o nível apropriado de detalhes em relação às suas necessidades. Terceiro, é importante que a informação gerada não seja complexa, seja fácil de entender e fácil para os gestores de projeto partilharem com os membros da equipa do projeto. Quarto, o PMIS facilita a contínua monitorização do progresso (Caniëls & Bakens, 2012).
12 2.1.4 Abordagens (Tradicional vs. Ágeis) A GP tradicional envolve um planeamento disciplinado e deliberado. Nesta abordagem as diferentes fases do ciclo de vida do projeto são facilmente reconhecíveis e as tarefas são completadas de forma sequencial. Assim, sempre que uma fase do projeto termina, assume-se que esta não será mais revisitada (Haughey, 2007). Por exemplo, o modelo Waterfall é caracterizado por uma abordagem de desenvolvimento sequencial seguindo as fases de análise de requisitos, design , implementação, teste e manutenção (Flora & Chande, 2014). Uma das forças da abordagem tradicional é o facto de esta definir todos os passos necessários para o desenvolvimento do projeto e salientar a importância do levantamento dos requisitos. Contudo, nem sempre o cliente define todos os requisitos atempadamente e raramente os projetos seguem um fluxo sequencial (Hass, 2007). Em ambientes complexos e com rápidas mudanças, de acordo com uma abordagem tradicional de GP, os gestores procuram planear e antecipar os detalhes e as necessidades do projeto antes da sua realização. Atualmente, com essas rápidas mudanças, a GP tem alterado devido às falhas que a abordagem tradicional apresenta, de forma a torná-las aceitáveis e gerir projetos dinâmicos com sucesso (Ciric et al., 2019). Para além disso, pode ainda ser ineficiente visto que os requisitos são difíceis de descrever, voláteis e sujeitos a alterações (Hass, 2007). A agilidade de uma organização pode ser definida como a capacidade de esta reagir rapidamente às mudanças num ambiente organizacional dinâmico e, apesar de ser um conceito fortemente presente no desenvolvimento de software e em projetos de TI, atualmente representa uma das vantagens competitivas das organizações contemporâneas. Esta foca-se sobretudo na “flexibilidade, na aceitação da mudança, avanços contínuos e fortes interações” (Ciric et al., 2019). Este é caracterizado como um processo iterativo e incremental onde os stakeholders e os developers do projeto cooperam de forma a entender e identificar necessidades para que as funcionalidades sejam priorizadas (Hass, 2007). Com o aumento da concorrência no mercado de software os investigadores procuram métodos mais flexíveis que possam ser utilizados para se ajustarem a situações onde os requisitos mudam continuamente (Flora & Chande, 2014). Assim, as práticas ágeis, incluindo a GP, surgiram da necessidade de gerir projetos caracterizados pela complexidade e incerteza na capacidade de resposta e adaptabilidade (Fernandez & Fernandez, 2008). Esta metodologia não é um método, é uma filosofia baseada no Agile Manifesto (Amir et al., 2013) e foca-se em quatro valores:
19 • Gerir a qualidade; • Controlar qualidade. Gestão de Recursos do Projeto - Inclui os processos relacionados com a organização, gestão e liderança da equipa do projeto, assim como todo o tipo de recursos. Nesta secção estão contemplados processos, tais como: • Planear a gestão dos recursos; • Estimar recursos necessários para as atividades; • Adquirir recursos; • Preparar a equipa do projeto; • Gerir a equipa do projeto; • Controlar recursos. Gestão das Comunicações do Projeto - Inclui os processos que são necessários para assegurar o planeamento, recolha, criação, distribuição, armazenamento, gestão, controlo, monitorização e disseminação da informação do projeto. Nesta secção estão contemplados processos, tais como: • Planear a gestão da comunicação; • Gerir comunicações; • Monitorizar comunicação. Gestão do Risco do Projeto - Inclui os processos da gestão do risco do projeto, nomeadamente o planeamento, identificação, análise, plano de resposta e controlo. Nesta secção estão contemplados processos, tais como: • Planear a gestão de risco; • Identificar riscos; • Executar análise qualitativa dos riscos; • Executar análise quantitativa dos riscos; • Planear resposta ao risco; • Implementar respostas ao risco; • Monitorizar riscos.
20 Gestão de Aquisições do Projeto - Inclui os processos necessários para compra ou aquisição de produtos, serviços ou resultados externos à equipa do projeto. Nesta secção estão contemplados processos, tais como: • Planear a gestão de aquisições; • Efetuar aquisições; • Controlar aquisições. Gestão dos Stakeholders do Projeto - Inclui os processos necessários para identificar pessoas, grupos ou organizações que podem ter impacto ou serem impactados pela concretização do projeto, para analisar as expectativas dos stakeholders e o seu impacto no projeto e para desenvolver estratégias de gestão apropriadas para envolver os stakeholders nas decisões e execução do projeto. Nesta secção estão contemplados processos, tais como: • Identificar stakeholders ; • Planear a gestão de stakeholders ; • Gerir envolvimento dos stakeholders ; • Controlar envolvimento dos stakeholders . 3.1.2 PMBOK – 7ª Edição A metodologia a seguir apresentada tem como referência os princípios base defendidos pelo Project Management Institute no documento “ The standard for project management and a guide to the project management body of knowledge ”, 7ª edição, publicada em 2021. Esta edição sofreu significativas alterações em comparação com edições anteriores visto que houve uma mudança de um padrão baseado em processos para um baseado em princípios, o que requer uma abordagem diferente para pensar sobre os aspetos da GP. A estrutura da 7ª edição do PMBOK encontrase sintetizada abaixo na Tabela 3 e dividida em duas partes: a primeira Standard para Gestão de Projetos e a segunda, Guia do Conhecimento para a Gestão de Projetos.
21 Tabela 3 - Estrutura PMBOK – Adaptado de PMI (2021) Estrutura PMBOK 7ª Edição Standard para Gestão de Projetos Guia do Conhecimento para a Gestão de Projetos Introdução Domínios de desempenho: • Stakeholders • Equipa • Desenvolver a Abordagem do Projeto e Ciclo de Vida • Planear • Executar Projeto • Entregar • Avaliar • Incerteza Sistema para entrega de valor Adaptação Princípios de Gestão de Projeto: • Administração • Equipa • Stakeholders • Valor • Pensamento sistémico • Liderança • Adaptação • Qualidade • Complexidade • Risco • Adaptabilidade e Resiliência Modelos, Métodos e Artefactos Apêndices, Glossário e Índice A primeira parte, Standard para Gestão de Projetos, permite fornecer um maior entendimento relativamente à temática em estudo, a GP, e o papel desta na concretização dos objetivos. Nesta secção é também possível encontrar doze princípios de GP, que são fundamentais para a formulação da estratégia e solução de problemas. Este standard aplica-se a qualquer projeto, independentemente da indústria, localização ou tamanho do mesmo. As duas partes constituintes deste guia são compostas por princípios e domínios, respetivamente, e estão ambos diretamente conectados sendo que os primeiros influenciam os domínios de desempenho, no sentido em que se atinjam os resultados pretendidos. Assim, os princípios devem orientar os
22 comportamentos dos indivíduos envolvidos, enquanto os domínios apresentam amplas áreas para demonstrar esse comportamento, tal como demonstrado na Figura 7, abaixo representada. Figura 7 - Relação entre os Princípios de Gestão de Projeto e os Domínios de Desempenho do Projeto PMI, 2021) Um dos pontos frisados na primeira parte deste guia é referente à entrega de valor e à forma como esta se torna mais eficaz quando a comunicação das informações e o feedback são partilhados consistentemente e alinhados com a estratégia. Para isso, a liderança partilha informações estratégicas com os portfólios. Os portfólios funcionam como um grupo para atingir os objetivos estratégicos, que por sua vez partilham os resultados, benefícios e valor desejados com os programas e projetos. Os deliverables destes são repassados para as operações juntamente com informações acerca do suporte e manutenção das entregas. Esta esquematização do fluxo de informação poderá ser observada na Figura 8 apresentada a seguir.
23 Figura 8 - Exemplo de fluxo de informação (PMI, 2021) Relativamente às diferentes funções relacionadas com o projeto, estas podem ser cumpridas por uma pessoa, por um grupo de pessoas ou combinadas em papéis definidos. Existem diferentes tipos de coordenação adequados para diferentes contextos, por exemplo, na coordenação descentralizada os elementos da equipa auto organizam-se e gerem o seu trabalho; já na coordenação centralizada, existe a orientação de um gestor de projeto ou uma função similar e da liderança. As funções descritas no PMBOK encontram-se a seguir listadas. ✓ Fornecer supervisão e coordenação – o objetivo é ajudar a equipa a atingir os objetivos do projeto. Esta função inclui monitorizar e melhorar a segurança e o bem-estar geral dos membros da equipa. ✓ Apresentar objetivos e feedback – os responsáveis por esta função contribuem com perspetivas, insights e orientações dos clientes e utilizadores finais, fulcrais não só para os requisitos, como também para os resultados e expectativas do projeto. ✓ Facilitar e dar suporte - esta função pode estar diretamente relacionada com a supervisão e coordenação, dependendo da natureza do projeto. O objetivo é incentivar a equipa do projeto à participação, colaboração e senso de responsabilidade pelo resultado do trabalho desenvolvido. Espera-se ainda ajudar a equipa do projeto a criar consenso em torno de soluções, resolver conflitos e tomar decisões. ✓ Efetuar o trabalho e contribuir com insights – os responsáveis por esta função fornecem o conhecimento, as capacidades e a experiência necessários para produzir o produto ou serviço final e alcançar os resultados do projeto. ✓ Aplicar experiência – o principal objetivo é fornecer o conhecimento e experiência num determinado assunto relativo ao projeto, através de conselhos e suporte. Estes podem ser
24 indivíduos externos à organização ou membros da equipa de projeto, sendo a sua função necessária apenas num período específico ou durante todo o projeto. ✓ Fornecer direções e insights relativos ao negócio – nesta função o objetivo é orientar e clarificar a direção do projeto ou o resultado esperado - isto envolve não só priorizar os requisitos, mas também os riscos operacionais. ✓ Fornecer recursos e direção - esta função está diretamente responsável por promover o projeto e comunicar a sua visão, os objetivos e as expectativas da organização para a equipa do projeto e stakeholders . Assim, o seu papel assenta em assegurar as ligações entre a administração e a equipa, manter os projetos alinhados aos objetivos de negócios, remover obstáculos e tratar de questões não respeitantes à equipa de projeto. ✓ Manter o controlo da governança – os responsáveis por esta função aprovam as recomendações feitas pela equipa e monitorizam o progresso do projeto. Ainda na primeira parte do PMBOK, Standard para Gestão de Projetos, encontram-se presentes doze princípios que servem como diretrizes fundamentais para o alinhamento da estratégia, a tomada de decisão e resolução de problemas. Estes princípios estão também alinhados com os valores identificados no Código de Ética e Conduta Profissional do PMI e são acompanhados de um “rótulo”, presente na tabela apresentada inicialmente, sendo estes: ✓ Seja diligente e respeitoso guardião dos recursos que lhe foram confiados; A administração age de forma a realizar as atividades de forma cuidada e alinhadas com as diretrizes internas (atuar de acordo com a visão, missão, estratégia da organização e supervisão de recursos, por exemplo) e externas (relacionamento com stakeholders , atenção à sustentabilidade ambiental e ao uso de recursos naturais, por exemplo). Demonstram especial atenção aos impactos sociais, ambientais e financeiros dos projetos. ✓ Crie um ambiente colaborativo com a equipa de projeto; As equipas de projeto são compostas por elementos que contêm conhecimentos diversificados e diversas experiências. Um ambiente colaborativo entre os elementos permite não só atingir de forma eficiente e eficaz os objetivos propostos, como também contribuir para o desenvolvimento pessoal.
25 ✓ Crie um envolvimento eficaz com os stakeholders; Envolver os stakeholders é fulcral tanto para o sucesso do projeto como para garantir a satisfação do cliente final. Isto irá influenciar também no desempenho do projeto ao longo do seu desenvolvimento, da equipa e na entrega de valor do projeto, positiva ou negativamente. Os stakeholders podem ter influência nos requisitos do projeto, no âmbito, cronograma, riscos, custos, entre outros aspetos. ✓ Foque na entrega de valor; É necessário avaliar e ajustar continuamente os objetivos do negócio com o projeto pois o seu valor é o principal indicador de sucesso. Tendo em conta as necessidades do negócio, o motivo da realização do projeto e a estratégia, a equipa de projeto consegue absorver informação necessária para tomar decisões relevantes de forma a aumentar o valor do projeto. ✓ Reconheça, avalie e responda a interações com a organização; É necessário ter a capacidade de reconhecer, avaliar e responder às circunstâncias dentro e fora do projeto, para que o seu desempenho seja afetado de forma positiva. À medida que os projetos se desenvolvem, as condições internas e externas mudam continuamente, e apenas uma mudança pode ter vários impactos no cronograma, âmbito, desempenho ou outros. ✓ Demonstre comportamentos de liderança; É necessário adaptar e demonstrar comportamentos de liderança para prestar auxílio em necessidades individuais e da equipa, sendo que uma liderança eficaz promove o sucesso do projeto e contribui para resultados positivos. Salienta-se a importância de líderes eficazes que adaptem o seu estilo de liderança à situação em questão. ✓ Ajuste a metodologia de acordo com o contexto; É essencial fazer o design da abordagem de desenvolvimento do projeto com base no contexto do mesmo, nos seus objetivos, stakeholders e ambiente por forma a alcançar os objetivos desejados. Cada projeto é único e o seu sucesso baseia-se na adaptação ao contexto em que se insere para que se determinem os métodos mais apropriados. A adaptação permite tornar os processos, a abordagem e a liderança mais adequados ao ambiente em questão, sendo esta iterativa e, portanto, contínua ao longo do projeto.
26 ✓ Inclua qualidade nos processos e nos deliverables ; É importante manter o foco na qualidade para produzir os deliverables do projeto que atendem aos requisitos e estão alinhados com as necessidades dos stakeholders . A qualidade do projeto envolve satisfazer essas mesmas expectativas e cumprir os requisitos deste. ✓ Navegue na complexidade; É importante avaliar continuamente a complexidade do projeto para que as abordagens e os planos delineados permitam que a equipa cumpra com sucesso o ciclo de vida do projeto. Esta complexidade pode afetar o valor do projeto, o âmbito, stakeholders , risco, entre outros elementos. ✓ Otimize as respostas ao risco; É importante avaliar continuamente a exposição ao risco, tanto em termos de oportunidades como de ameaças. Isto permitirá maximizar os impactos positivos (que podem ter benefícios como a redução de tempo e custos, melhor desempenho) e minimizar os impactos negativos (que podem causar atrasos, ter custos acrescidos, falhas no desempenho) para o projeto e para os seus resultados. ✓ Seja adaptável e resiliente; É importante criar adaptabilidade e resiliência ao longo do projeto para que seja possível adaptar a equipa e a organização às mudanças inesperadas, recuperar de contratempos e avançar com o projeto. A ideia de que os projetos devem manter os planos e compromissos assumidos na fase inicial do projeto (mesmo após o surgimento de novos fatores ou imprevistos) não é benéfica para os stakeholders , incluindo clientes e utilizadores finais, pois limita o valor que o projeto poderá ter. Podem surgir oportunidades novas durante a execução do projeto que podem ser benéficas para as partes envolvidas, e por este motivo, é necessário que a equipa seja capaz de propor novas soluções e ser resiliente quando confrontada com uma oportunidade de mudança. ✓ Inclua as alterações que o permitam atingir a visão definida; É importante preparar os elementos que irão sofrer impactos para a adoção de comportamentos novos e também por processos necessários à transição do estado atual para
27 o estado futuro pretendido. Esta mudança pode ter origem em influências internas ou externas e pode ser um desafio, dependendo da aceitação das partes interessadas. Poderá também ser um desafio dependendo da cultura da organização, pois uma cultura mais conservadora pode mostrar maior resistência à mudança. A segunda parte diz respeito ao guia PMBOK e encontra-se dividido em três secções: ✓ Domínios de Desempenho do Projeto – são descritos oito domínios que permitem uma entrega bem-sucedida do projeto ( Stakeholders, Equipa, Desenvolver a Abordagem do Projeto e Ciclo de Vida, Planear, Executar Projeto, Entregar, Avaliar, Incerteza); ✓ Adaptação – apresenta uma visão geral do que adaptar e como adaptar os projetos individuais; ✓ Modelos, Métodos e Artefactos – apresenta uma breve descrição dos modelos, métodos e artefactos mais utilizados e que representam opções que podem ser utilizadas pela equipa de trabalho. Domínios de Desempenho Os domínios de desempenho do projeto são áreas de foco interrelacionadas e interdependentes que trabalham em conjunto para alcançar os resultados pretendidos. As atividades executadas em cada um dos domínios são definidas consoante diversos fatores. Os domínios referidos encontram-se abaixo listados. Stakeholders o Aborda as atividades e funções associadas às partes interessadas. Este domínio tem como objetivo atingir determinados resultados, tais como uma relação de trabalho produtiva com os stakeholders ao longo do projeto e um acordo dos principais objetivos do projeto com estes. Isto envolve trabalhar cooperativamente com as partes interessadas para manter o alinhamento com estas e mantê-las envolvidas de forma a promover relacionamentos positivos e a sua satisfação.
28 Relativamente ao envolvimento dos stakeholders , são implementadas estratégias e ações para promover o envolvimento destes. A identificação dos stakeholders pode ser realizada antes da formação da equipa e o seu detalhe é descrito como uma atividade contínua ao longo do projeto. Após isto é necessário entender e analisar as suas crenças e valores, de forma a identificar ameaças ou oportunidades no contexto do projeto. Equipa o Aborda as atividades e funções associadas às pessoas responsáveis pela produção dos deliverables do projeto. Tem como principal resultado uma equipa de alto desempenho e fomentação de skills interpessoais demonstradas pelos elementos. Isto envolve também a criação de um ambiente e cultura que permita aos elementos da equipa evoluir nesse sentido. A gestão da equipa de projeto e a liderança são atividades que envolvem a aplicação de conhecimentos, capacidades, ferramentas e técnicas para o desenvolvimento do projeto, assim como motivar e ouvir os elementos da equipa. Relativamente à liderança, esta pode ser centralizada quando as atividades associadas a esta área são atribuídas a um individuo (como por exemplo o gestor de projeto) ou pode existir uma gestão distribuída, em que a equipa se pode auto-organizar de forma a atingir os resultados pretendidos. A seguir encontram-se listadas algumas atividades associadas a esta função: ✓ Estabelecer a visão do projeto; ✓ Pensamento crítico (é importante identificar as causas dos problemas e questões desafiadoras); ✓ Motivar; ✓ Capacidades interpessoais (utilizadas em projetos que incluam inteligência emocional, tomada de decisão e resolução de conflitos). Desenvolver a Abordagem do Projeto e Ciclo de Vida o Aborda as atividades e funções associadas à abordagem de desenvolvimento adotada, cadência e fases do ciclo de vida do projeto.
35 Matriz de Stakeholders é atualizada e são criados outros planos importantes tais como o Plano de Comunicação, Plano de Transição e o Plano de Implementação do Negócio. Execução – esta é a fase em que a equipa produz os deliverables do projeto definidos no Project Work Plan. Nesta fase o projeto requer mais recursos e são colocados em prática os planos definidos na fase transata. Assim que os deliverables forem aceites pelo Project Owner , o Project Manager pode pedir aprovação para passar à fase seguinte. Encerramento – os entregáveis terminados são transferidos para o Project Owner e o projeto é terminado. Assim, o Project Manager deverá garantir que estes são aceites. São discutidas as experiências e lições retiradas do projeto, de forma a documentar as melhores práticas para projetos futuros. Monitorização e Controlo – estas atividades ocorrem ao longo de todo o ciclo de vida do projeto e são observadas pelo Project Manager . O progresso do projeto é medido de acordo com o planeado e são identificadas e tomadas ações corretivas de forma a contornar problemas ou riscos. Apesar de as melhores práticas deste guia poderem ser aplicadas a qualquer tipo de projeto, para que toda a metodologia seja aplicada, o projeto deverá conter algumas características, sendo algumas delas: ✓ Tem uma duração de mais de 4 a 5 semanas e envolve mais de 2 a 3 pessoas; ✓ Requer aprovação do orçamento e do âmbito do projeto; ✓ Pode exigir a colaboração de várias organizações ou unidades organizacionais; ✓ Requer um certo nível de documentação, transparência e relatórios; ✓ Requer uma estrutura de governança devidamente definida e funções e responsabilidades claramente atribuídas, entre outros. Para que a metodologia satisfaça as necessidades da organização, é necessário que exista uma personalização da mesma. Esta personalização refere-se à mudança de partes específicas da metodologia, de forma a adaptá-la às necessidades específicas da estrutura e cultura da organização. A adaptação faz mais sentido a nível organizacional ou departamental, mas também pode ocorrer ao nível do projeto com base, por exemplo, na sua complexidade, tamanho ou tipo de um projeto. São estas adaptações que são documentadas no Project Handbook . Neste sentido, o Agile tem em consideração a
36 incerteza inerente ao ambiente do projeto e cria uma organização adaptável às mudanças que possam surgir nos requisitos do mesmo, recorrendo a ciclos de feedback curtos. O PM2 tem uma estrutura que providencia auxílio nestes aspetos às equipas, num dos apêndices do guia. Relativamente aos papéis e responsabilidades, os mesmos encontram-se listados a seguir, seguidos de um diagrama desenvolvido do ponto de vista da gestão do projeto, na Figura 11: • Appropriate Governance Body (AGB) – responsável pelo plano estratégico e gestão de portfolio. Entidade que aprova um projeto e aprova os objetivos acordados. • Project Steering Committee (PSC) – compreende uma combinação de representantes tanto do lado do fornecedor, como do cliente. Este é presidido pelo Product Owner e é o principal órgão responsável pela tomada de decisão e resolução de problemas no projeto. • Project Owner (PO) – é o cliente do projeto e tem a responsabilidade de garantir que os resultados do projeto estão alinhados com os objetivos do negócio. • Solution Provider – assume a responsabilidade das entregas do projeto e representa os interesses dos que as desenham e implementam. • Business Manager (BM) – representa o Product Owner diariamente no projeto e presta auxílio na definição dos objetivos de negócio. • Project Manager (PM) – responsável por supervisionar o projeto diariamente, garantir o uso eficaz dos recursos e entregar resultados de alta qualidade. A comunicação, gestão de stakeholders e de riscos também fazem parte das suas responsabilidades. • Business Implementation Group (BIG) – é coordenado pelo Business Manager e é constituído por representantes de grupos de negócios e utilizadores. Este grupo é responsável por planear e implementar as mudanças de negócios que precisam de ser efetuadas ao longo do projeto. • Project Core Team (PCT) – compreende as funções especializadas que estão responsáveis por criar as entregas do projeto. A sua estrutura depende do tamanho e do tipo do projeto. • Project Support Team (PST) – é uma função opcional que consiste em responsáveis por fornecer suporte ao projeto, dependendo a sua estrutura das necessidades do mesmo.
37 Durante a fase de Monitorização e Controlo vários aspetos são tidos em conta, começando pelo cronograma. O objetivo com isto é garantir que as tarefas do projeto sejam executadas conforme o planeado e que os prazos do projeto sejam cumpridos. O Project Manager controla regularmente o cronograma, tendo em atenção o que estava planeado, a realidade e o previsto. Assim como o cronograma exige um determinado controlo durante o projeto, também os custos assim o requerem. Regularmente o Project Manager monitoriza o orçamento e compara o valor orçamentado com o valor real e o esperado. O objetivo aqui é gerir os custos do projeto para que estejam em conformidade com a base de custo/esforço e as restrições gerais do orçamento do projeto. No início do projeto, o custo orçamentado deverá ser aprovado pelo Project Owner . Gerir os stakeholders é também uma tarefa fulcral para o correto desenvolvimento do projeto, desde a fase de Iniciação, onde as expectativas e os requisitos são identificados, até à fase de Encerramento, quando a experiência e a satisfação geral das partes interessadas no projeto são registadas. Mais uma vez, o Project Manager é responsável por esta tarefa, contudo os membros do Project Steering Committee devem também devem estar envolvidos. Os requisitos fazem também parte deste processo de monitorização ao longo de todo o ciclo de vida do projeto. Estes passam por um processo de recolha, documentação e validação, podendo ser adaptados de acordo com as necessidades do projeto. Gerir os riscos que o projeto incorre é um processo contínuo onde são identificados e avaliados para que estejam em conformidade com a aceitação dos mesmos por parte da organização. Assim, é possível aumentar a confiança da equipa no projeto. Normalmente, a documentação relativa aos riscos permite não só identificá-los, como também definir ações mitigantes de resposta aos mesmos. Figura 11 - Organização do Projeto (European Commission, 2018)
38 Para além das componentes identificadas, também outras são monitorizadas ao longo do ciclo de vida do projeto, tais como a qualidade, o desempenho, a aceitação dos entregáveis, entre outras. 3.1.4 ICB O referencial a seguir apresentado tem como referência os princípios base defendidos pela International Project Management Association no documento “ Individual Competence Baseline for Project, Programme and Portfolio Management ” versão 4.0, publicada em 2015. O IPMA Individual Competence Baseline (ICB) é um dos standards mais aceite pelas organizações e permite melhorar a taxa de sucesso dos projetos, aplicando um conjunto de competências (Ghosh et al., 2015). No ICB4 verifica-se uma evolução das áreas de competência para três áreas – Pessoas, Práticas e Perspetivas. A estrutura do ICB encontra-se organizada por essas competências que estão divididas em vinte e nove elementos com os respetivos indicadores: cinco elementos para as competências relativas à Perspetiva, dez elementos para Pessoas e catorze elementos para Prática (IPMA, 2015). Neste seguimento, surge o Eye of Competence , representado na Figura 12, que é aplicável aos três domínios de GP, programa e portfolio. Cada elemento de cada competência é apresentado pela definição, propósito, descrição e conhecimentos gerais e capacidades necessários para demonstrar o domínio desse elemento. Estes elementos são divididos em indicadores que diferem pelo domínio do projeto (com 134 indicadores), do programa (124 indicadores) ou do portfolio (105 indicadores) (Vukomanović et al., 2016). Figura 12 - Eye of Competence (IPMA, 2015)
39 Quanto à Perspetiva, cada projeto é conduzido ou suportado por drivers externos, sendo estes, por exemplo, a estratégia, a governança, estruturas e processos, a regulação, entre outros. A área relativa às Pessoas pretende descrever as competências pessoais e sociais que um indivíduo deverá possuir para ser capaz de atingir o sucesso e são exemplo destas a autorreflexão, comunicação e o trabalho em equipa. Já no que diz respeito às competências relativas à Prática, estas estão associadas aos métodos, ferramentas e técnicas usados em projetos, programas ou portfolios (IPMA, 2015). O foco desta metodologia baseia-se nos indivíduos, sendo que a mesma trata do desenvolvimento de competências individuais, contudo é também referido que não existe uma forma única de desenvolver essas competências. Uma competência individual é descrita como a “aplicação de conhecimentos e capacidades para alcançar os resultados desejados” (IPMA, 2015). O IPMA ICB tem como pilares alguns conceitos tais como: ✓ Domínios – não se foca em funções específicas, tais como gestor de projeto, mas sim em indivíduos que se preocupam em gerir o projeto, ou seja a ideia é que estas funções variem de acordo com indústria, foco e idioma. ✓ Áreas de competências – contém três áreas de competência referidas anteriormente, que formam o Eye of Competence . ✓ KCIs ( Key Competence Indicators ) e medidas – existem diversas competências associadas a cada área, sendo que cada KCI pretende fornecer indicadores de sucesso relativos à GP, programas e portfolios para os domínios. ✓ Projeto – “esforço único, temporário, multi-disciplinar e organizado para efetuar as entregas acordadas de acordo com os requisitos e restrições predefinidos” (IPMA, 2015). ✓ Programa – caracteriza-se por ser uma organização de componentes interrelacionados de modo a atingir um objetivo e permitir a implementação de mudanças e realização de benefícios. ✓ Portfólio – conjunto de projetos e/ou programas que são unidos para otimizar o uso de recursos da organização e atingir os seus objetivos. Desta forma, cada indivíduo deve ter um conjunto de competências que lhe permita atuar com sucesso num projeto. Isto deverá permitir-lhe que competências de perspetiva abordem o contexto de projetos, competências de pessoas que abordem temas pessoais e sociais e competências de prática que abordem competências técnicas específicas para a GP.
40 Competências relativas à Perspetiva Para a execução de um projeto existem diversos drivers que influenciam a sua execução, assim como o contexto político, social e organizacional. Abaixo encontram-se espelhados os elementos de competência referidos, o respetivo significado e os indicadores chave que os caracterizam. Estratégia Neste elemento são definidos objetivos e metas claros que permitem direcionar o projeto rumo ao sucesso. Tem como principal objetivo compreender a estratégia e os processos de alinhamento estratégicos da organização e os seus indicadores chave são: ✓ Alinhamento com a missão e visão; ✓ Identificação de oportunidades que influenciem a estratégia; ✓ Desenvolver e garantir a validade da justificação do projeto; ✓ Determinar, avaliar e rever os fatores críticos de sucesso e os indicadores de desempenho. Governança, estruturas e processos É definido o alinhamento com as estruturas, sistemas e processos estabelecidos na organização que suportam os projetos e influenciam os seus detalhes. O seu objetivo passa por permitir que os indivíduos participem e consigam gerir o impacto da governança, das estruturas e dos processos. Os seus indicadores-chave são: ✓ Conhecer os princípios de GP, gestão de programas e gestão de portfólio e como se implementam; ✓ Alinhar o projeto com funções de suporte; ✓ Alinhar o projeto com as estruturas de tomada de decisão e relatórios da organização e os requisitos de qualidade; ✓ Alinhar o projeto com processos e funções de recursos humanos; ✓ Alinhar o projeto com os processos e funções de finanças e controlo. Conformidade, standards e regulações Contém perspetivas relevantes para o projeto, contemplando leis, regulamentos, normas e ferramentas que refletem as melhores práticas e prioridades, por exemplo interpretando as restrições de uma área, um país ou uma empresa. O seu principal objetivo passa por permitir que um individuo consiga
41 gerir o alinhamento de normas e regulamentos relevantes para a organização, como por exemplo as normas ISO. Os indicadores-chave que o descrevem são: ✓ Garantir que o projeto se encontra em conformidade com a legislação relevante; ✓ Garantir que o projeto se encontra em conformidade com os regulamentos de saúde, segurança e ambientais; ✓ Garantir que o projeto se encontra em conformidade com todos os códigos de conduta e regulamentos profissionais relevantes; ✓ Garantir que o projeto se encontra em conformidade com os princípios e objetivos de sustentabilidade relevantes; ✓ Avaliar, usar e desenvolver padrões e ferramentas; ✓ Avaliar, comparar e melhorar as competências de GP. Poder e interesse Descreve como o individuo reconhece e entende os interesses informais e pessoais resultantes do uso do poder. Podem fazer surtir efeitos no sucesso do projeto, salientando que estes têm também objetivos pessoais, não se regendo apenas pelas metas da organização. O principal objetivo é permitir que o individuo use técnicas associadas ao poder de forma a satisfazer os interesses dos stakeholders . Quanto aos indicadores que o representam, apresentam-se como: ✓ Avaliar as ambições e interesses pessoais dos outros e o seu potencial impacto no projeto; ✓ Avaliar a influência informal dos indivíduos e grupos e o seu impacto no projeto; ✓ Avaliar as personalidades e estilos de trabalho de outros. Cultura e os valores É descrita a abordagem dos indivíduos na forma a influenciar a cultura e os valores da organização. O objetivo deste elemento é permitir ao individuo que este reconheça a influência de aspetos culturais no projeto, nos objetivos, processos e resultados. Os seus indicadores-chave são: ✓ Avaliar a cultura e valores da sociedade e as suas implicações no projeto; ✓ Alinhar o projeto com os valores e a cultura da organização; ✓ Avaliar a cultura e os valores da organização e as suas implicações para o projeto;
42 Competências relativas às Pessoas Esta área tem como objetivo descrever as competências pessoais e sociais que um indivíduo deverá possuir de forma a alcançar o sucesso, encontrando-se estas baixo encontram-se listadas. Autorreflexão e autogestão A autorreflexão define-se como a capacidade de reconhecer e compreender as próprias emoções, comportamentos, preferências e valores, assim como os seus impactos. Já a autogestão caracteriza-se como a capacidade de estabelecer objetivos pessoais e ajustar o seu progresso, lidando com a mudança e situações de maior pressão. O principal objetivo deste elemento é permitir ao individuo que reconheça as suas emoções, preferências e valores e controle os seus comportamentos. Os indicadores-chave para este elemento são: ✓ Identificar e refletir de que forma os próprios valores e experiências influenciam o trabalho; ✓ Construir autoconfiança baseada nos pontos fortes e fracos; ✓ Identificar e refletir sobre motivações pessoais de forma a definir metas; ✓ Organizar o trabalho pessoal dependendo da situação e dos recursos; ✓ Assumir responsabilidades relativas à aprendizagem e desenvolvimento pessoal. Integridade pessoal e fiabilidade Estas são características fundamentais que rumam ao alcance dos resultados pretendidos. Desta forma os indivíduos agem de acordo com os próprios valores e princípios morais e também de forma confiável e de acordo com as expetativas acordadas. O objetivo desta competência é permitir ao individuo que tome decisões consistentes ao longo do desenvolvimento dos projetos. Relativamente aos seus indiciadores-chave os mesmos encontram-se listados a seguir: ✓ Reconhecer e aplicar valores éticos a todas as decisões; ✓ Promover a sustentabilidade dos resultados; ✓ Assumir a responsabilidade das próprias ações; ✓ Agir, tomar decisões e comunicar conscientemente; ✓ Completar as tarefas de forma a construir uma base de confiança com outros.
43 Comunicação pessoal Refere-se à troca de informação relevante com as partes interessadas. O principal objetivo deste elemento é permitir que o individuo comunique eficaz e eficientemente em diversas situações. Os seus indicadores-chave são: ✓ Fornecer informações claras a outros e verificar a respetiva compreensão; ✓ Promover e facilitar a comunicação aberta; ✓ Utilizar os canais de comunicação adequados ao público; ✓ Comunicar com equipas virtuais (diferentes fusos horários, espaços); ✓ Recorrer ao humor e ao senso de perspetiva no momento apropriado. Relações e envolvimento As relações são um ponto fulcral para a colaboração produtiva com os outros reforçando a importância de investir tempo e atenção nas mesmas. O propósito deste elemento é permitir que o individuo tenha a capacidade de se relacionar e de manter esses mesmos relacionamentos pessoais. Os seus indicadores-chave são: ✓ Desenvolver relações pessoais e profissionais; ✓ Contribuir para as redes sociais; ✓ Demonstrar empatia ouvindo, entendendo e dando suporte; ✓ Demonstrar confiança e respeito, incentivando os outros a expressar as suas opiniões; ✓ Partilhar a própria visão e objetivos de forma a promover o envolvimento com os outros. Liderança Para além de fornecer orientação aos indivíduos, a liderança requer também a necessidade de selecionar e aplicar estilos de gestão adequados às diferentes situações. Com isto, o principal objetivo é incentivar o individuo a liderar, motivar os outros por forma a melhorar o desempenho da equipa. Como exemplo de indicadores chave existem: ✓ Oferecer ajuda e aconselhar proactivamente; ✓ Demonstrar compromisso (com os objetivos do projeto); ✓ Fornecer orientação de forma a melhorar o trabalho individual e da equipa; ✓ Ter influência e poder adequados perante os outros; ✓ Tomar e rever decisões.
44 Trabalho em equipa (associado à Liderança) O trabalho em equipa concentra-se na realização de um objetivo comum salientando como aspetos mais importantes a comunicação e os relacionamentos para uma equipa bem-sucedida. Assim, este elemento tem como objetivo permitir que o indivíduo selecione os elementos corretos para a equipa, gerindo-a de forma eficaz. Os seus indicadores-chave de competência são: ✓ Selecionar os membros e construir a equipa; ✓ Promover a colaboração e networking entre os elementos; ✓ Suportar e facilitar o desenvolvimento da equipa; ✓ Atribuir tarefas e responsabilidades; ✓ Reconhecer erros cometidos. Conflitos (associado à Liderança) Este elemento inclui também a resolução dos conflitos que possam surgir e que devem ser contornados de forma a constituírem um processo de aprendizagem para eventos futuros. Assim, é possível o indivíduo tomar medidas quando ocorrem conflitos. Os respetivos indicadores-chave são: ✓ Antecipar e prever conflitos; ✓ Analisar causas e consequências dos conflitos para selecionar respostas adequadas; ✓ Medir os conflitos e os seus impactos; ✓ Identificar e partilhar as aprendizagens obtidas de forma a melhorar as práticas futuras. Criatividade Define-se pela capacidade de aplicar várias técnicas de pensar para definir, analisar e encontrar alternativas para resolver constrangimentos. O objetivo assenta em fomentar a procura sistemática de soluções novas e mais eficazes. Os indicadores-chave que suportam esta competência são: ✓ Estimular um ambiente criativo e de partilha; ✓ Aplicar o pensamento concetual para definir estratégias; ✓ Aplicar técnicas analíticas para analisar situações, dados e tendências organizacionais; ✓ Promover e aplicar técnicas criativas para encontrar alternativas; ✓ Promover uma visão holística do projeto para melhorar a tomada de decisão.
51 O Scrum foi desenvolvido no início dos anos 90 por Ken Schwaber e Jeff Sutherland, tendo sido publicada a sua primeira versão em 2010. Este caracteriza-se por ser uma “estrutura leve que ajuda as pessoas, equipas e organizações a gerar valor através de soluções adaptativas para problemas complexos” (Sutherland & Schwaber, 2020). É constituído com base na inteligência cooperativa e coletiva dos seus utilizadores, criando diretrizes relativas às suas relações e interações. Esta é uma framework baseada no empirismo e no pensamento Lean , onde o conhecimento advém da experiência baseada na observação e no foco naquilo que é essencial e reduzindo o desperdício, respetivamente. Baseia-se ainda numa abordagem iterativa, incremental e rege-se por três pilares fundamentais - transparência, inspeção e adaptação. A transparência simboliza o conhecimento e perceção que toda a equipa deverá ter acerca daquilo que está a ser feito e o que se prevê em termos de trabalho. Só assim é possível permitir a inspeção, que pode detetar problemas potencialmente indesejáveis através das revisões efetuadas em cada iteração. A adaptação a qualquer circunstância que esteja fora dos limites torna-se mais fácil visto que cada evento está suscetível a provocar novas mudanças e é necessário que a equipa se adapte. Papéis A unidade fundamental do Scrum é a Scrum Team que é constituída pelos Developers , pelo Product Owner e pelo Scrum Master . Dentro desta equipa não existem hierarquias e os seus elementos são considerados multifuncionais, onde todos têm as competências necessárias para o desenvolvimento do projeto e autogeridas, permitindo-lhes tomar decisões relativas ao que fazer e quando. Uma equipa desta natureza contém tipicamente dez ou menos elementos, de forma que sejam mais comunicativos e produtivos, estando responsáveis por todas as atividades relacionadas com os produtos finais. Estão assim encarregues pela criação de incrementos em cada Sprint . Os Developers são responsáveis por criar o Sprint Backlog (plano da Sprint ), adaptar o plano a cada dia de acordo com os objetivos do projeto e aderir a uma Definition of Done . O Product Owner é o responsável por maximizar o valor do produto resultante do trabalho da equipa. Este é inteiramente responsável pela gestão do Product Backlog , onde define e comunica claramente o Product Goal e os elementos do Product Backlog , ordena os últimos e assegura a total compreensão do Product Backlog ,
52 Finalmente, o Scrum Master é o responsável pela implementação do Scrum , tentando torná-lo percetível para todos na equipa e na organização. Para além disso, caracteriza-se como um líder e está responsável pela Scrum Team , assim como treiná-la na autogestão, auxiliá-la na criação de incrementos, remover impedimentos que possam surgir e assegurar que todos os eventos são produtivos e de acordo com o tempo previsto. O Scrum Master tem ainda o papel de ajudar o Product Owner a encontrar as melhores técnicas para definição do Product Goal e para a gestão do Product Backlog , assim como facilitar a colaboração dos stakeholders sempre que necessário. Eventos Ao longo do trabalho da equipa existem diversos eventos característicos do Scrum e a sua não realização resulta na perda de oportunidades de inspeção e adaptação. O seu principal objetivo é criar regularidade, sendo que todos estes devem ser realizados à mesma hora e no mesmo local de forma a minimizar a complexidade. Um dos principais eventos deste framework são os Sprints – eventos de duração fixa de um mês ou menos onde todo o trabalho necessário efetuar ocorre dentro destes. Os Sprints permitem assegurar dois dos pilares, a inspeção e a adaptação de forma a garantir a progressão para um Product Goal por mês, diminuindo o risco e a complexidade. Este evento pode apenas ser cancelado pelo Product Owner . O Planeamento do Sprint é o evento que dá início a um novo Sprint onde é determinado todo o trabalho a ser desenvolvido na próxima fase e conta com a colaboração de toda a equipa. Neste evento são abordados aspetos tais como a importância do Sprint que se iniciará para os stakeholders , que itens incluir do Product Backlog para o mesmo Sprint e de que forma o trabalho vai ser planeado (decompondo os itens do Product Backlog em itens mais pequenos). Este evento é limitado a um máximo de oito horas se o Sprint equivaler a um mês, variando a sua duração proporcionalmente à duração do Sprint . O Daily Scrum é um evento cujo objetivo passa por inspecionar o progresso do trabalho efetuado rumo ao Sprint Goal e adaptar o Sprint Backlog conforme necessário. Tem a duração aproximada de quinze minutos onde a Scrum Team e os Developers melhoram as suas comunicações, identificam constrangimentos e tomam decisões, evitando a necessidade de outras reuniões. Tipicamente no final de um Sprint ocorre a Revisão do Sprint onde todos os resultados são analisados e são determinadas possíveis adaptações futuras. Estes resultados são apresentados aos stakeholders
53 do projeto e todos colaboram, contribuindo com sugestões relativas ao trabalho a fazer a seguir. Para um Sprint de um mês, esta reunião tem normalmente uma duração máxima de quatro horas. Finalmente, a Retrospetiva do Sprint tem como objetivo delinear estratégias para aumentar a qualidade e a eficácia das tarefas através de uma análise feita ao Sprint transato, nomeadamente às interações, ferramentas e outros aspetos. A equipa discute os problemas com que se deparou ao longo do Sprint e como foram, ou não, ultrapassados. São ainda identificadas ações necessárias para melhorar a eficácia da equipa e desta forma o Sprint fica concluído. Artefactos Os artefactos no Scrum representam o trabalho e um compromisso, podendo o progresso ser medido através de três artefactos: ✓ Poduct Backlog – representa uma lista ordenada do que é necessário fazer para melhorar o produto. O compromisso deste artefacto é o Product Goal que serve de meta para a equipa delinear o planeamento do trabalho, ou seja, caracteriza-se como o objetivo a longo prazo. ✓ Sprint Backlog – caracteriza-se por ser um plano do trabalho que os Developers planeiam realizar durante o Sprint , de forma a alcançar o objetivo do mesmo. O Sprint Goal é o seu principal compromisso e é responsável por encorajar toda a equipa a trabalhar em conjunto. ✓ Increment – é um passo na direção do Product Goal e cada um destes é acrescentado aos anteriores, verificado e assegurado que todos funcionam em conjunto, sendo já utilizável. Dentro de um Sprint podem ser criados vários destes. O seu compromisso denomina-se Definition of Done , sendo esta uma descrição do Increment quando cumpre as medidas de qualidade exigidas para o produto. Assim, se um item do Product Backlog não cumprir a Definition of Done , não poderá ser lançado. Os autores referem que, apesar de ser possível implementar apenas algumas partes do Scrum , o seu resultado não é considerado como tal. De forma a simplificar o processo descrito anteriormente, a Figura 13, a seguir apresentada, demonstrará um papel representativo deste.
54 Figura 13 - Framework Scrum (Rubin, K., 2013) 3.1.6 Síntese das metodologias estudadas Como resultado do estudo efetuado nesta secção, foi desenvolvida uma tabela onde é possível verificar algumas semelhanças e divergências no que concerne aos aspetos estruturais e comportamentais de cada uma das metodologias analisadas. Tabela 4 - Síntese das metodologias estudadas PMBOK 6 PMBOK 7 PM2 ICB Scrum Classificação Guia de referência Guia de referência Metodologia Referencial de competências Framework Composição 10 áreas de conhecimento, 5 grupos de processos e 49 processos 12 princípios e 8 domínios, ambos focados na entrega de valor House of PM2 – modelo de governança, ciclo de vida do projeto, processos e artefactos 3 Áreas de competências (Perspetiva, Pática, Pessoas) e 29 elementos de competência Artefactos, eventos e papéis Apresentação de processos de gestão Sim Não Não Não Não
55 Comportamento da metodologia Baseado numa GP preditiva e direcionado a um ambiente estável Baseado numa GP orientada para mudanças inesperadas Baseado em atividades de GP, conceitos, contexto no qual um projeto se enquadra (programas, portfólio, estrutura organizacional) e artefactos em cada uma das fases do projeto Direcionado às competências dos indivíduos Baseado numa GP flexível, ambiente cooperativo e autoorganizado. Rege-se em três pilares – transparência, inspeção e adaptação Abordagem Tradicional Tendência ágil Tradicional Adaptável Ágil Apresentação de práticas Descrição dos processos com recurso a inputs , outputs , ferramentas e técnicas Descrição dos domínios e princípios através de diretrizes e boas práticas Descrição de artefactos e atividades a cada fase do projeto Cada área de competência abrange um conjunto de elementos de competência, cada um com propósito, descrição, capacidades e conhecimento Sugestão de valores, princípios e práticas Ciclo de vida do projeto Descrito Não descrito Descrito Não descrito Não descrito
56 3.2 Categorização de projetos Devido à capacidade de adaptação e personalização que as metodologias estudadas possuem, foi necessário fazer uma pesquisa e levantamento de categorizações de projetos existentes na literatura de forma a selecionar um dos modelos e pesquisas analisados e efetuar a comparação do mesmo, em função do estudo das metodologias efetuado. Neste sentido foram analisadas categorizações relacionadas com as áreas de engenharia, tendo obtido os modelos e pesquisas apresentados no Anexo I, juntamente com um quadro síntese comparativo dos modelos estudados. Após analisar os aspetos abordados nas propostas presentes no Anexo I, foi selecionado o modelo apresentado a seguir para posterior utilização do seu referencial. Este modelo foi selecionado devido às várias classificações que contempla e à relevância das suas dimensões para o desenvolvimento de um projeto, fatores considerados relevantes para atingir o sucesso. Shenhar, Dvir – Modelo Diamante (foco na engenharia e tecnologia) Shenhar, em colaboração com outros autores (Shenhar & Dvir, 1996; Shenhar, 1998; Shenhar & Dvir, 2004), tiveram uma forte influência nesta temática através dos seus contributos. Em 2004, Shenhar e Dvir desenvolveram, tendo por base versões anteriores, o modelo NTCP ( Novelty, Technology, Complexity, Pace ), também conhecido como Modelo Diamante. Este é um framework que sofreu algumas evoluções e pode orientar os gestores de projeto na seleção do estilo de gestão durante a fase de iniciação do projeto, no recrutamento de membros da equipa, na determinação de estruturas e processos e na seleção das ferramentas adequadas. Representa uma abordagem de gestão que representa quatro dimensões, onde é projetado um diamante de forma a fornecer uma ferramenta para analisar os benefícios e riscos esperados de um projeto, assim como desenvolver um conjunto de regras e comportamentos para cada tipo de projeto. As dimensões compreendem a Inovação (termo traduzido de Novelty ), Tecnologia (termo traduzido de Technology ), Complexidade (termo traduzido de Complexity ) e Ritmo (termo traduzido de Pace ) e podem ser classificadas em três tipos de projeto diferentes, tal como se encontra abaixo ilustrado na Figura 14 (Shenhar & Dvir, 2004). Este é um framework que pode ser utilizado pelos gestores por forma a tomarem decisões relativas aos projetos e ao modo como devem ser executados. Uma das suas finalidades é também ser utilizado pela gestão para identificar os principais benefícios e riscos associados a um projeto (A. J. Shenhar & Dvir, 2007).
57 Figura 14 - Modelo Diamante (A. J. Shenhar & Dvir, 2007) Inovação - É definido pelo quão novo o produto é para os potenciais utilizadores e diz respeito ao grau de inovação do produto e o respetivo impacto nas atividades de GP. Representa também a incerteza relativa aos objetivos do projeto e/ou ao seu posicionamento no mercado. Isto afetará três questões principais: a confiabilidade da pesquisa de marketing, o tempo necessário para definir os requisitos do produto e as estratégias de marketing a adotar para determinado produto (A. J. Shenhar & Dvir, 2007). É possível desta forma medir o quão novo o produto é para o mercado e assim verificar se os requisitos iniciais foram corretamente definidos. Encontra-se classificado em categorias que determinam a melhor abordagem de marketing e o impacto que terá na GP (A. J. Shenhar & Dvir, 2007). Estes níveis são classificados como: • Derivative : extensões ou melhorias de produtos existentes. Os requisitos são precisos e são definidos com antecedência, onde o risco de falha é baixo. • Plataform : nova geração de produtos que substituem produtos já existentes, por exemplo um novo modelo de carro. A definição final dos requisitos é feita durante a execução do projeto e o risco que incorre é de nível médio. • Breakthrough : novos produtos que transformam um novo conceito ou uma ideia num produto nunca antes visto. Os requisitos devem permanecer flexíveis até à introdução do produto no mercado e é necessária uma alta colaboração com os stakeholders (A. J. Shenhar & Dvir, 2007).
58 Tecnologia – Representa o nível de incerteza tecnológica e é determinado pela necessidade de nova tecnologia. Foram desenvolvidos quatro níveis distintos de incerteza tecnológica associados a diferentes categorias de projetos: • Low-Tech : tecnologia existente e bem definida; os exemplos mais comuns da sua utilização são em projetos de construção e é característica de um estilo de gestão firme; • Medium-Tech: tecnologia existente, contudo incorporam também nova tecnologia ou um novo recurso que não existia ainda em produtos anteriores. Exemplos da sua aplicação incluem produtos em indústrias estáveis, como por exemplo automóveis ou equipamento pesado. • High-Tech : tecnologia nova, contudo já existente e disponível na fase inicial do projeto. São expectáveis muitas alterações e um estilo de gestão flexível; • Super-High-Tech : projetos baseados em nova tecnologia que não existiam na fase inicial do mesmo, sendo exemplo desta categoria uma ida à lua. Característica de uma atmosfera altamente flexível, assim como o estilo de gestão, devido à continua mudança que se “vive” neste tipo de projetos (A. J. Shenhar & Dvir, 2007). Nesta dimensão, os projetos que contêm alto nível de incerteza tecnológica requerem profissionais altamente qualificados (Basgal et al., 2009). Complexidade – Mede a complexidade de um produto, tarefa e organização do projeto. De forma a distinguir entre os diferentes níveis de complexidade, utilizou-se uma estrutura hierárquica de sistemas, denominado system scope . onde um nível mais baixo representa um subsistema do nível superior seguinte (A. J. Shenhar & Dvir, 2007). Segundo Basgal et al. (2009), os projetos que apresentam uma maior complexidade necessitam procedimentos mais formais na sua organização. São distinguidos três níveis: • Assembly : envolve a criação de uma de coleção de componentes e módulos combinados numa única unidade e serve para uma única função. Característica de ferramentas simples, controlo simples e informar, estilo de gestão informar e foco no custo, qualidade, entrega e fabricação. Tipicamente não recorrem a standards neste tipo de classificação. • System : envolve uma coleção de elementos e subsistemas que juntos se dedicam a determinadas funções para atender a uma necessidade operacional. Resultam produtos como
59 computadores, carros ou edifícios. O planeamento é complexo, com várias atividades e o controlo é rígido e formal em questões técnicas, sendo que o estilo de gestão é burocrático. • Array : conjunto de sistemas que juntos colaboram para atingir um objetivo comum, sendo exemplos deste tipo de projetos redes de comunicação nacionais ou redes de distribuição de energia. São projetos de grande escala onde os sistemas são adicionados gradualmente e o controlo é feito por um responsável em cada subprojecto. O estilo de gestão é formal, com várias burocracias e exige conhecimento de políticas (A. J. Shenhar & Dvir, 2007). Ritmo – Esta escala determina a quantidade de tempo disponível para a concretização do projeto. Nesta escala, os projetos diferenciam-se através da sua urgência e do que acontece caso os objetivos não sejam atingidos. Esta dimensão impacta os projetos na autonomia da equipa, na burocracia e no envolvimento da alta gestão (A. J. Shenhar & Dvir, 2007). Os projetos mais urgentes exigem equipas com maior autonomia (Basgal et al., 2009). Foram identificados três níveis diferentes: • Regular : o tempo não é crítico para o sucesso da organização. Não existe uma estrutura única em termos de organização e não existe uma atenção especial a processos e procedimentos. • Fast/competitive : tipicamente concebidos para atingir novas oportunidades de mercado, criar um posicionamento estratégico ou criar novos negócios. São geridos com mentalidade estratégica focada no tempo de mercado e com o apoio da alta administração. • Time-critical : são os mais críticos em termos de urgência e o tempo é um fator crucial para atingir o sucesso. A data alvo é conhecida e existe um planeamento cuidado. Para além disto, ultrapassar os deadlines do projeto significa o fracasso de um projeto. • Blitz : são os projetos mais urgentes e mais críticos relativamente ao tempo. Tipicamente iniciamse em resposta a uma crise ou um evento inesperado, daí não haver tempo para um planeamento detalhado, nem documentação. Os gestores de projeto deverão ter autonomia, assim como as equipas, e deverá existir envolvimento e suporta da alta administração (A. J. Shenhar & Dvir, 2007). Cada dimensão deste modelo pode afetar e impactar a GP de diferentes formas, relembrando que este modelo se concerne apenas nestas quatro dimensões, sendo que cada organização deverá ter em atenção as incertezas que mais as inquietam (A. J. Shenhar & Dvir, 2007). A Figura 15 pretende demonstrar o impacto que estas dimensões têm consoante o seu nível. Por exemplo, um maior nível de
60 Inovação tem disponibilizado um menor número de dados sobre o mercado e a definição dos requisitos é feita tardiamente. Figura 15 - Impacto das dimensões do modelo Diamante na GP (A. J. Shenhar & Dvir, 2007) Este modelo pode demonstrar o nível de risco que uma organização poderá incorrer, dependendo da classificação em que o projeto se deveria enquadrar e na qual se enquadra no momento. Através desta figura, foi possível aferir que os níveis superiores requerem preocupações redobradas. A Inovação afeta a precisão das previsões de mercado, a capacidade de determinar os requisitos e o tempo de congelamento dos mesmos. À medida que a inovação aumenta, menos será possível basear o projeto em pesquisas de marketing , visto que os dados deste ramo serão praticamente inexistentes, daí ser necessária a colaboração com os stakeholders . Na Tecnologia, quanto mais elevado o nível, maior a capacidade de design e atividades de desenvolvimento, maior o número de ciclos de design e o acordo do design final mais tardio. Isto exige também altas qualidades técnicas da equipa e mais revisões do artefacto final. A Complexidade afeta a organização e os procedimentos adotados por esta, sendo que um aumento da complexidade exige uma maior formalidade. Já o Ritmo exige uma maior atenção aos prazos, ou seja, quanto mais rápido o ritmo, maior a autonomia que a equipa deverá ter, assim como mais apoio será necessário por parte da administração de topo (A. J. Shenhar & Dvir, 2007). Abaixo é possível verificar na Tabela 5 os potenciais benefícios e riscos de cada dimensão, no seu nível mais elevado.
67 desempenhados e desenvolvidos no PM2. As restantes classificações não correspondem às fases desta metodologia, na medida em que o “fecho” do design se estende para fases subsequentes. Quanto à Complexidade , o PM2 enquadra-se na classificação System. Aqui os projetos contêm um planeamento complexo e detalhado, assim como várias atividades com principal foco nos requisitos, design e integração do sistema (A. J. Shenhar & Dvir, 2007). Ora, um planeamento detalhado é algo característico desta metodologia, onde se dedica uma das suas fases do projeto exclusivamente a tal e são criados diversos planos que permitem delinear estratégias para diferentes aspetos, tais como a comunicação e implementação de negócio, por exemplo. Existe ainda nesta classificação o foco no controlo rígido relativamente a questões técnicas, financeiras e de cronograma (A. J. Shenhar & Dvir, 2007). Para isto existe a fase de Monitorização e Controlo, que permite ao longo de todo o projeto verificar este tipo de questões, assim como stakeholders , riscos e outros. Relativamente ao Ritmo, o PM2 adequa-se ao nível Time-Critical , onde o foco é centrado especificamente em algo, o tempo de conclusão do projeto é critico e onde os indivíduos são especificamente escolhidos (A. J. Shenhar & Dvir, 2007). Isto deve-se ao facto de existirem vários papéis e responsabilidades claramente definidos e o cronograma ser um dos aspetos fulcrais constituintes da fase de Monitorização e Controlo, controlado pelo Project Manager . Neste tipo de classificação a data alvo é bem conhecida, o que deixa uma margem considerável para o planeamento. ICB A representação correspondente ao ICB classifica-se como Derivative , Platform e Breakthrough , Super-High-Tech, System , Array e Blitz . O foco principal desta metodologia baseia-se nos indivíduos, tratando o desenvolvimento de competências individuais, o que difere de outras metodologias estudadas. Ou seja, deverão ser aplicados conhecimentos de forma a atingir os resultados esperados. Assim, o uso mais apropriado da metodologia ICB é “avaliar e combinar o nível e as capacidades do gestor de projeto com o tamanho e o grau de complexidade do projeto como uma garantia de melhor esforço para o sucesso do projeto e isso é aplicável a quase todos os tipos de projeto” (Al-Maghraby, 2010). Após o estudo realizado da metodologia, foi possível concluir que o ICB foca na avaliação de capacidades do gestor de projeto e da equipa, enfatizando as competências comportamentais dos indivíduos e das suas relações, daí a sua ênfase nas aptidões dos indivíduos.
68 Comparativamente às restantes metodologias estudadas, apresenta-se como uma metodologia complementar, ou seja, apesar de fornecer guidelines relativamente às competências dos gestores, não faz referência a qualquer tipo de sequência de atividades que estes deverão seguir ou ter em consideração. Por este motivo, considera-se complementar e não uma metodologia tradicional ou ágil, podendo ser adaptada em ambas. Assim, foi possível considerar que este é um guia complementar e pode ser transversal a qualquer classificação das quatro dimensões. Neste sentido, relativamente à dimensão Inovação, esta metodologia enquadra-se nos três tipos de classificações apresentadas no modelo Diamante – Derivative , Platform e Breakthrough . Novamente, e sendo esta uma metodologia complementar, em qualquer projeto se adaptaria e adequaria quando se trata de inovação. Tanto na classificação Derivative , onde o nível de risco é baixo e os requisitos são precisos e definidos à priori; como na Platform , onde os requisitos são definidos durante a execução do projeto, geralmente criam novas gerações de linhas de produtos existentes e o risco que incorre é mediano; e também na classificação Breakthrough , característica de ideias inovadoras e onde os requisitos deverão permanecer flexíveis até à introdução do produto/serviço no mercado, daí o risco ser elevado. Aplicando as competências enunciadas no ICB - Perspetiva, Pessoas e Prática – é possível consolidar as competências requeridas para trabalhar em projetos, programas e portefólios. Relativamente à Tecnologia, na classificação Super-High-Tech, o estilo de gestão adotado é bastante flexível em projetos desta natureza, visto que vivencia contínuas mudanças e sendo até referida a expressão “ looking for trouble ”. Salienta-se a importância de recorrer às competências relativas à Prática e às Pessoas, de forma a que as competências centrais do projeto e dos indivíduos sejam asseguradas num ambiente instável associado à tecnologia. Pela sua alta especificidade e minuciosidade nestas competências, um projeto deste tipo, que exige profissionais altamente qualificados, tem a capacidade de ser complementado com uma metodologia como esta.les No que diz respeito à Complexidade, e devido ao facto de o ICB ser tão completo e específico em cada competência nas diferentes vertentes, a classificação System e Array adequa-se ao nível de complexidade exigido pelos indivíduos. Na primeira é exigido um planeamento complexo, com várias atividades e um estilo de gestão burocrático com principal foco nos requisitos, no design do sistema e na integração do mesmo (A. J. Shenhar & Dvir, 2007). Estes aspetos vão de encontro às competências relativas à Prática no ICB e são competências centrais do projeto. Na classificação Array os projetos são de grande escala e onde tipicamente são executados em diferentes locais, combinando várias áreas de conhecimento (A. J. Shenhar & Dvir, 2007). Aqui salientam-se competências assinaladas no ICB tais como as relações, a comunicação pessoal e o trabalho em equipa assegurado também por uma liderança
69 eficaz. O estilo de gestão é formal e requer conhecimento de políticas podendo conter várias burocracias. Neste seguimento, nas competências relativas à Perspetiva é referida a necessidade de garantir que determinado projeto se encontra em conformidade com a legislação relevante, códigos de conduta e regulamentos. Quanto ao Ritmo, a classificação Blitz enquadra-se nesta dimensão na medida em que, possivelmente, é a que mais requer competências dos indivíduos. Projetos do tipo Blitz são desenvolvidos em situações inesperadas, como resposta a uma crise, não requerem um planeamento detalhado e são os projetos mais urgentes. Por estes motivos, são necessários indivíduos qualificados e com capacidade de lidar com projetos neste tipo de situações. É necessário ressalvar competências enunciadas no ICB, tais como a autorreflexão e autogestão, fulcrais para alinhar comportamentos e estabelecer metas. Scrum A representação do Scrum apresenta-se como Breaktrough , High-Tech , Super-High-Tech , Array , Fast/Competitive e Time-Critical. Esta metodologia classifica-se como ágil e é geralmente recomendada para projetos não tão bem definidos à priori, adaptando-se mais a projetos com natureza de alta taxa de mudança (Al-Maghraby, 2010). Assim, relativamente à Inovação esta metodologia classifica-se como Breaktrough devido à sua flexibilidade quanto à definição inicial do produto, visto que esta pode mudar depois de testes iniciais. Para além disto, existe a possibilidade de nesta categoria os requisitos serem fechados depois do feedback necessário, o que é característico das metodologias ágeis. Uma outra característica que faz parte da dimensão Breaktrough é a alta colaboração com os stakeholders (A. J. Shenhar & Dvir, 2007), o que é também uma particularidade do Scrum , visto que a cada iteração existe uma revisão que permite expor os resultados obtidos a estes. Quanto à Tecnologia esta metodologia enquadra-se tanto em High-Tech como em Super-High-Tech , devido à exigência de um nível de gestão altamente flexível. Por este motivo encontra-se representada no esquema com os limites não definidos. É também característica de ambas as categorias um ambiente de contínua mudança, o que se adequa idealmente a uma metodologia ágil como o Scrum , devido à sua abordagem iterativa de recolha de requisitos e entrega faseada do produto ou serviço final ao cliente. Relativamente à dimensão Complexidade, devido ao facto de esta metodologia suportar projetos com elevado grau de complexidade, a classificação Array enquadra-se nesta dimensão. Aqui os projetos são
70 de grande escala e os sistemas são adicionados gradualmente (A. J. Shenhar & Dvir, 2007). De acordo com a metodologia Scrum , cada Sprint permite garantir a progressão para um Product Goal por mês, o que permite também diminuir o risco e a complexidade. Desta forma, e incrementalmente em cada Sprint , é obtido um produto/serviço final. Quanto ao Ritmo poderia ser enquadrada em duas classificações – Fast/Competitive e Time-Critical , no entanto, nos projetos Time-Critical existe uma data alvo de conclusão conhecida (A. J. Shenhar & Dvir, 2007). Visto que o Scrum é característico de projetos com elevada taxa de mudança, em que os requisitos podem estar constantemente a ser alterados, um deadline inalterável poderá não corresponder com esta metodologia. Assim, a classificação Time-Critical manter-se-á com o reparo da questão da data de conclusão abordada. Fast/Competitive é a característica mais adequada, sendo que a alteração desta data de conclusão do projeto não é fatal para o mesmo. Para além disto, exige o apoio da alta administração. Apesar de ser compatível com projetos de elevada complexidade, o Scrum não se enquadra em todas as características das dimensões de elevada complexidade deste modelo. Exemplo disso é o facto de um projeto estratégico, por norma, ter um maior nível de novidade e projetos do tipo Blitz serem realizados em contextos de crise ou eventos inesperados, de forma a responder a uma preocupação instantânea. Ora, uma situação de crise não é compatível com um projeto característico de um produto ou serviço novo para o mercado, à priori. Por este motivo, uma maior complexidade não corresponde à metodologia Scrum de acordo com este modelo.
71 Tabela 6 - Síntese das classificações por metodologia Dimensão Classificação PMBOK 6 PMBOK 7 PM2 ICB Scrum Novelty Derivative X X X Platform X Breakthrough X X X Technology Low-Tech Medium-Tech X X High-Tech X X Super-High-Tech X X X Complexity Assembly System X X X X Array X X Pace Regular Fast/Competitive X X X Time-Critical X X X Blitz X
72 5. DISCUSSÃO E RESULTADOS 5.1 Demonstração de caso de estudo O modelo estudado é utilizado nas organizações no sentido de representar o projeto “ideal” consoante as suas especificações. Eli e Holzmann (2012) aplicaram o modelo mencionado numa empresa especializada em projetos de alta tecnologia de forma a desenvolverem e implementarem as melhores práticas nesta. Foi identificado um projeto utilizado como referência para outros projetos. Inicialmente é analisado um projeto “ideal” segundo o modelo e no final é comparado com os restantes projetos. O DTX360A é um projeto desenvolvido pela ECI Telecom no início dos anos 1990 e é um sistema de comunicação de duplicação de linha telefónica de segunda geração (DCME – Digital Circuit Multiplication Equipment). É característico de requisitos funcionais e âmbito complexos, o que levou a organização a um sucesso financeiro e comercial (Eli & Holzmann, 2012). A representação resultante da aplicação do modelo a este projeto encontra-se abaixo apresentada na Figura 17. Figura 17 - Aplicação do modelo Diamond ao projeto DTX360A (Eli & Holzmann, 2012)
73 Relativamente à Inovação, este conceito de projeto não é novidade para a ECI, visto que este projeto é um redesenho de um sistema DCME. Contudo, como incorpora novos requisitos e exige um software desafiador e outros aspetos novos, foi categorizado como Platform (Eli & Holzmann, 2012). Isto deve-se essencialmente ao facto de, neste tipo de projetos, serem criadas novas gerações de produtos existentes. Este projeto enquadra-se na posição High-Tech na dimensão Tecnologia visto que se baseia principalmente em novas tecnologias (Eli & Holzmann, 2012) bastante específicas para este tipo de projeto. Apesar de novas, não são tecnologias desenvolvidas de raiz, pelo que não é representado no nível mais superior. Devido ao facto de ser um produto construído a partir de subsistemas multidisciplinares e de envolver várias equipas, foi classificado como System na componente da Complexidade e Fast/Competitive quanto ao Ritmo (Eli & Holzmann, 2012). Este projeto tinha de ser lançado antes dos concorrentes da ECI, daí estar enquadrado nesta classificação e o foco ser o tempo de lançamento no mercado. Foram listadas as melhores práticas de gestão deste projeto relativamente a dois níveis: no primeiro nível são abordados os aspetos relacionados com normas de gestão e aspetos operacionais relacionados com planeamento, execução e monitorização; no segundo são abordados aspetos de GP associados à cultura e ao ambiente do projeto, nomeadamente práticas relacionadas com a visão e inspiração. Abaixo serão apresentados os dois níveis de práticas referentes a apenas duas classificações do modelo, na Tabela 7. Tabela 7 – Exemplos de aspetos abordados no projeto DTX360A – Adaptado de Eli & Holzmann (2012) Nível 1 Nível 2 High-Tech Excessos/surpresas esperados; Planeamento antecipado da prova de conceitos. Deteção antecipada de problemas; Liderança técnica; Adotar novas ferramentas que ajudam a facilitar os resultados finais; Estarem precavidos para “surpresas”; Identificar e desenvolver soluções genéricas. Fast/Competitive Forte coordenação das equipas; Integrações parciais e pontos de monitorização e aprovação claros. Representantes dos principais grupos durante as integrações; Sem regras rígidas (“ no by-the-book ”).
74 De seguida, os autores verificaram como é que as melhores práticas observadas no projeto “ideal” foram incorporadas em projetos posteriores. Para isso, recorreram a cinco projetos anteriores e, apesar de observaram que o ambiente envolvente ao projeto alterou significativamente ao longo dos anos, algumas questões permaneceram comuns a todos, tais como: ✓ Os projetos adotaram lições experienciadas no projeto “ideal” da organização; ✓ Cada lição pode ser associada a uma das dimensões do modelo Diamante; ✓ Os projetos cujo modelo Diamante teve o maior desvio do modelo do projeto “ideal” tiveram mais problemas e os seus objetivos não foram totalmente atingidos. A representação da aplicação do modelo Diamante aos cinco projetos pode ser observada a seguir na Figura 18, referenciando também a representação do projeto “ideal” usado como meio de comparação. Figura 18 - Comparação dos modelos Diamante dos projetos na ECI Eli & Holzmann (2012) Resumidamente, com este estudo, os autores concluíram que projetos classificados como significativamente diferentes do projeto “ideal” tiveram problemas e não cumpriram totalmente os objetivos do projeto. Para além disto, se mais atenção tivesse sido prestada à adoção de práticas adequadas às dimensões de cada projeto, possivelmente os resultados poderiam ter sido superiores.
75 Adicionalmente, consideraram que esta é uma ferramenta útil e prática para incorporar as melhores práticas para projetos futuros (Eli & Holzmann, 2012). Após analisar as características do projeto “ideal” e o modelo comparativo apresentado na secção anterior, é possível aplicá-lo de forma a entender qual a metodologia mais adequada para este projeto. Neste sentido, o PMBOK 7 e o ICB seriam, paralelamente, as metodologias que poderiam ser adotadas e adaptadas pela organização. A classificação High-Tech , Fast/Competitive e System são as que, de acordo com as suas características, vão ao encontro deste projeto e da metodologia PMBOK 7. A classificação Platform , pertencente à dimensão Inovação, é propícia à adoção do ICB. Assim, combinando o PMBOK 7 com as competências defendidas pelo ICB, o projeto “ideal” poderia ter sido sustentado pelas práticas destas metodologias. A esquematização da combinação destas metodologias com o projeto “ideal” encontra-se representada a seguir na Figura 19. Projeto “ideal” ICB PMBOK 7 Figura 19 - Aplicação do modelo comparativo ao projeto "ideal" – Adaptado de A. J. Shenhar & Dvir (2007)
76 5.2 Resultados obtidos No seguimento do desenvolvimento do modelo comparativo de metodologias de GP apresentado na secção anterior, é possível concluir que uma metodologia mais ágil enquadra-se numa representação com mais possibilidade de encaixe nas diversas classificações do que uma metodologia com tendência tradicional, como foi possível verificar o caso do Scrum e do PM2. Uma metodologia não se adequa, por vezes, a um só tipo de classificação em cada dimensão, tendo em conta as suas características. Por este motivo, é importante ressalvar que as características de cada classificação no modelo comparativo são bastante ténues, havendo por isso margem para subjetividade relativamente à atribuição de cada metodologia. Deste modo, e tendo em consideração o contexto desta dissertação, apesar de ser um tema com uma vasta variedade de informação disponível na literatura, o domínio da solução poderá ser subjetivo visto que não existem soluções disponíveis semelhantes que abordem estas metodologias. Quando se direciona a atenção para a Inovação, o PMBOK 7 e o Scrum são as metodologias que, devido à sua natureza, são as mais adequadas para projetos cuja inovação é significativa. Já em projetos cuja inovação não aparenta ter um peso substancial no âmbito destes, o PMBOK 6 e o PM2 são as metodologias mais indicadas neste nível. O ICB, representado anteriormente, representa um pilar importante na complementaridade em todo o tipo de projetos, tanto de maior como de menor inovação. O mesmo acontece com esta distribuição referida anteriormente para a Tecnologia – PM2 e PMBOK 6 num nível intermédio de exigência tecnológica e nos dois níveis mais superiores, PMBOK 7 e Scrum. Neste caso, apesar de ser importante aplicar o ICB em variados projetos, nesta dimensão considerou-se especialmente relevante aplicar no nível superior de tecnologia, onde o ambiente é altamente instável e “desconhecido”. No que concerne à Complexidade, o Scrum é uma metodologia com boas práticas e princípios sustentados em projetos de natureza complexa, enunciando neste parâmetro a auto-organização e autonomia dos elementos das equipas. Por este motivo adequa-se a projetos de maior complexidade, estando o ICB também associado a este nível e ao intermédio. Quanto ao Ritmo, todas as metodologias se enquadram nos níveis intermédios, com a exceção do ICB que, em projetos no nível superior caracterizados por situações inesperadas, tem um papel fundamental ao fomentar as capacidades dos indivíduos. Contudo, as metodologias que se encontram em níveis superiores apresentam maior nível de risco incorrido. Por exemplo, relativamente à Inovação, com a adoção de metodologias como o Scrum e o PMBOK 7 existe uma dificuldade acentuada em prever as necessidades do mercado devido à novidade
83 Kerzner, H. (2010). Project management best practices: Achieving global excellence (2nd ed). John Wiley & Sons; International Institute for Learning. Kostalova, J., Tetrevova, L., & Svedik, J. (2015). Support of Project Management Methods by Project Management Information System. Procedia - Social and Behavioral Sciences , 210 , 96–104. https://doi.org/10.1016/j.sbspro.2015.11.333 Lacerda, D. P., Dresch, A., Proença, A., & Antunes Júnior, J. A. V. (2013). Design Science Research: Método de pesquisa para a engenharia de produção. Gestão & Produção , 20 , 741–761. https://doi.org/10.1590/S0104-530X2013005000014 Manson, N. J. (2006). Is operations research really research? ORiON , 22 (2), Art. 2. https://doi.org/10.5784/22-2-40 Muhaise, H., Ejiri, A. H., Wycliffe, J., Muwanga-Zake, F., & Kareyo, M. (2020). The Research Philosophy Dilemma for Postgraduate Student Researchers . https://doi.org/10.13140/RG.2.2.15085.61929 Nahod, M.-M., & Radujkovic, M. (2013). The Impact of ICB 3.0 Competences on Project Management Success. Procedia - Social and Behavioral Sciences , 74 , 244–254. https://doi.org/10.1016/j.sbspro.2013.03.014 Paredes, C., & Ribeiro, P. (2018). Future Trends in Project Management. 2018 International Conference on Intelligent Systems (IS) , 637–644. https://doi.org/10.1109/IS.2018.8710551 PMI. (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide) . Newtown Square, Pennsylvania: Project Management Institute PMI. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) . Newtown Square, Pennsylvania: Project Management Institute.
84 Raymond, L., & Bergeron, F. (2008). Project management information systems: An empirical study of their impact on project managers and project success. International Journal of Project Management , 26 (2), 213–220. https://doi.org/10.1016/j.ijproman.2007.06.002 Retnowardhani, A., & Suroso, J. S. (2019). Project Management Information Systems (PMIS) for Project Management Effectiveness: Comparison of Case Studies. 2019 International Conference on Computer Science, Information Technology, and Electrical Engineering (ICOMITEE) , 160–164. https://doi.org/10.1109/ICOMITEE.2019.8921046 Rosenberger, P., & Tick, J. (2018). Suitability of PMBOK 6th edition for agile-developed IT Projects. 2018 IEEE 18th International Symposium on Computational Intelligence and Informatics (CINTI) , 000241–000246. https://doi.org/10.1109/CINTI.2018.8928226 Shenhar, A., & Dvir, D. (1996). Toward a Typological Theory of Project Management. Research Policy , 25 , 607–632. https://doi.org/10.1016/0048-7333(95)00877-2 Shenhar, A. J. (1998). From theory to practice: Toward a typology of project-management styles. IEEE Transactions on Engineering Management , 45 (1), 33–48. https://doi.org/10.1109/17.658659 Shenhar, A. J., & Dvir, D. (2004). How projects differ and what to do about it (J. K. Pinto & P. W. G. Morris, Eds.). John Wiley & Sons. Shenhar, A. J., & Dvir, D. (2007). Reinventing Project Management: The Diamond Approach To Successful Growth And Innovation . Harvard Business Press. Sutherland, J., & Schwaber, K. (2017). The Definitive Guide to Scrum: The Rules of the Game. Teixeira, L., Xambre, A. R., Figueiredo, J., & Alvelos, H. (2016). Analysis and Design of a Project Management Information System: Practical Case in a Consulting Company. Procedia Computer Science , 100 , 171–178. https://doi.org/10.1016/j.procs.2016.09.137 Turner, J. R. (1996). The project manager as change agent: Leadership, influence and negotiation . McGraw-Hill.
85 Vaishnavi, V., & Kuechler, B. (2004). Design Science Research in Information Systems. Association for Information Systems . http://www.desrist.org/design-research-in-information-systems/ Venable, J., & Baskerville, R. (2012). Eating our own cooking: Toward a more rigorous design science of research methods. Electronic Journal of Business Research Methods , 10 (2), pp141-153. Vukomanović, M., Young, M., & Huynink, S. (2016). IPMA ICB 4.0—A global standard for project, programme and portfolio management competences. International Journal of Project Management , 34 (8), 1703–1705. https://doi.org/10.1016/j.ijproman.2016.09.011
86 ANEXO I Crawford, Hobbs, Turner – Foco nos atributos Crawford, Hobbs e Turner (2006) desenvolveram uma pesquisa em sistemas de categorização de projetos, apoiada pelo Research Program do Project Management Institute (PMI®). Para isso foi realizado um Focus Group com diversas organizações relacionadas com serviços financeiros, departamentos de projetos de engenharia e construção de grandes empresas e consultoria, incluindo um grupo de consultores de sistemas de informação. Isto permitiu obter uma vasta gama de resultados, encontrando-se estes listados a seguir (Crawford et al., 2006). A seguir encontram-se listados os atributos mais comuns e os mais importantes identificados pelos autores. Tabela 8 - Comparação entre os atributos mais comuns e mais importantes – Adaptado de Crawford et al. (2006) Atributos mais comuns Atributos mais importantes Benefícios organizacionais Área de aplicação Custos Natureza do trabalho Cliente, consumidor Cliente, consumidor Área de aplicação Complexidade Complexidade Custos Importância estratégica Tamanho Nível de risco Importância estratégica Natureza do trabalho Nível de risco Recursos Benefícios organizacionais Tamanho Deliverables Wheelwright e Clark – Foco no desenvolvimento do produto Em 1992 Wheelwright e Clark sugeriram três categorias de projetos de desenvolvimento de produto. Os critérios utilizados para classificar os projetos de acordo com este modelo são o grau de mudança do produto e o processo de fabricação. Este sistema é útil para determinar os recursos necessários, sendo que os projetos que contêm mudanças mais significativas, por norma, vinculam mais recursos (Dao, 2011).
87 • Derivative projects : são extensões e melhorias de produtos já existentes sendo que projetos deste tipo incluem redução de custos, melhoria do produto e modificações. Os produtos anteriores estão bem estabelecidos no mercado e a comercialização destes foca-se na vantagem do produto em relação aos modelos anteriores, tentando atingir potenciais novos clientes e atender às necessidades dos atuais. • Plataform projects : projetos deste tipo geralmente servem de impulsionadores aos referidos anteriormente. Aqui as empresas devem realizar pesquisas de mercado exaustivas e elaborar um planeamento de forma cuidada, exigindo assim um trabalho redobrado na fase inicial. Estes oferecem vantagem competitiva para organizações com grande potencial de inserção no mercado. • Breakthroush projects : são considerados os “ new-to-the-world products ” (Shenhar & Dvir, 2004) e introduzem novas ideias e conceitos. Estes produtos oferecem inovação radical ao mercado, revolucionando-o, através da utilização de tecnologias e materiais desconhecidos (Dao, 2011). Figura 20 - Categorização de projetos de desenvolvimento de produto (Wheelwright & Clark, 1992) Howeel, Windahl, Seidal – Modelo UC Este modelo desenvolvido por Howeel, Windahl e Seidal (2010) pode ser utilizado para identificar quais são os modelos de processo mais apropriados para gerir um determinado projeto (Howell et al., 2010). Este modelo baseia-se em dois critérios para classificação de projetos: Uncertainty (U) e Consequences (C), sendo que o primeiro é determinado pela incerteza e está associado à probabilidade de algo inesperado acontecer no projeto e o segundo, associado ao impacto gerado caso algo inesperado aconteça.
88 A figura abaixo descreve a estrutura gráfica do modelo descrito que inclui três exemplos de modelos de processo de GP. Figura 21 - Framework UC (Howell et al., 2010) O primeiro modelo de processo considerado é o modelo Plan Driven que consiste em: • Identificar os objetivos do projeto e as etapas necessárias para os atingir; • Organizar as etapas sequencialmente tendo em conta os recursos e outros, para conceber o plano do projeto; • Seguir o plano, de acordo com as atividades estipuladas e lidar com constrangimentos. Este modelo não depende do eixo C, visto que o seu objetivo é antecipar e evitar acontecimentos inesperados, sendo as consequências irrelevantes. À medida que a incerteza aumenta, as suposições relacionadas com os objetivos, ao esforço requerido, recursos e outras variáveis serão menos válidas. Neste caso, será necessário refazer o planeamento e definir novas respostas a acontecimentos não planeados (Howell et al., 2010). Relativamente ao modelo Problem Structuring , o mesmo assume que: • A questão central de um projeto passa por entender os seus objetivos e o ambiente; • É necessário obter essa informação através da modelação de relações causa-efeito. À semelhança do anterior, este é também independente do eixo C e aqui, caso não exista uma definição adequada ao problema em questão, as consequências não são relevantes. Contudo, se existir alguma alteração no eixo U, isto gerará mudanças na importância relativa ao problema. O último modelo, o Agile , envolve: • Assumir que os objetivos do projeto vão ser definidos na sua fase inicial;
89 • Um processo iterativo que envolve a implementação parcial das metas e a sua redefinição com base em feedbacks. Este modelo depende do eixo U, presumindo um alto nível de incerteza e relativamente ao eixo C, qualquer evento que a equipa não consiga resolver, poderá comprometer o projeto na sua totalidade. Segundo os autores, não existe nenhuma garantia quanto ao surgimento de uma solução, pelo que pode ser uma situação crítica (Howell et al., 2010). A Figura 21 demonstra as zonas de conforto de cada modelo referido e representa um cenário em que um C alto e um U médio não são um apropriados a nenhum modelo de processo, não sendo fácil de gerir perante os modelos apresentados. Turner, Cochrane – Foco nos objetivos do projeto e métodos Turner e Cochrane (1993) desenvolveram uma matriz com dois parâmetros de forma a agrupar os projetos na sua fase inicial – clareza dos objetivos e clareza dos métodos para atingir esses objetivos. Desta forma, a avaliação dos projetos tendo em conta dois eixos resulta numa categorização em quatro tipo de projetos: • Type-l projects: for which the goals and methods of achieving the project are well defined – tipicamente grandes projetos de engenharia. Foram denominados como projetos terra, visto estarem bem definidos e com uma base sólida. • Type-2projects: for which the goals are well defined but the methods are not – geralmente associado a projetos de desenvolvimento de produtos e caracterizados como projetos água, apesar de ter um fluxo com um propósito definido, a água flui de maneira aparentemente aleatória. • Type-3 projects: for which the goals are not well defined but the methods are – associado a projetos de desenvolvimento de software, onde geralmente é difícil especificar os requisitos dos utilizadores. As metas são conhecidas, contudo não podem ser especificadas com precisão até os stakeholders verem o que pode ser produzido. Conhecidos como projetos incêndio visto que muito “calor” pode surgir na definição do trabalho, contudo pode “arder” sem razão aparente. • Type-4 projects: for which neither the goals nor the methods are well defined – tipicamente projetos de desenvolvimento organizacional e são denominados de projetos aéreos.
90 Figura 22 - Matriz dos objetivos e métodos (Turner and Cochrane, 1993) Bērziša – Foco nos atributos Bērziša desenvolveu um conjunto dos principais atributos de classificação de projetos em 2011 e sugere um modelo para qualquer tipo de projeto, cujo objetivo era permitir recuperar conhecimento aplicado em atividades de GP anteriores. O autor faz referência a alguns modelos existentes na literatura e refere que algumas delas são gerais e subjetivas, sendo necessários atributos mais detalhados e específicos para medir a similaridade de projetos (Bērziša, 2011). Fazem parte desta classificação dezoito atributos, divididos por seis grupos, tal como estão representados na Tabela 9. Tabela 9 - Classificação por grupos e atributos – Adaptado de B ē rziša (2011) Grupo Atributo Tipo de projeto Tipo de projeto Cliente Produto do projeto Ação de projeto Produto de projeto Área Tamanho do projeto Complexidade Tamanho da equipa Budget do projeto Duração
91 Organização do projeto Estrutura da organização do projeto Tamanho da organização Área da organização Orientação Metodologias de gestão Regras do governo Standards relacionados com o produto Abordagem de gestão/planeamento Ciclo de vida da GP Abordagem de estimativa Abordagem de custo 6.1.1 Síntese dos modelos de categorização de projetos De forma a sintetizar as informações recolhidas relativas a cada um dos modelos foi desenvolvida uma tabela que simplifica as mesmas por modelo, autores, tipo de projeto, os critérios analisados em cada um deles e o principal objetivo. Tabela 10 - Quadro síntese dos modelos de categorização Pesquisa/Modelo Autores Tipologia Critérios de classificação Objetivo Sem denominação Crawford, Hobbs e Turner (2006) Pesquisa efetuada a empresas de consultoria, SI, engenharia, construção e serviços financeiros - Benefícios organizacionais - Custos - Cliente, consumidor - Área de aplicação - Complexidade - Importância estratégica - Nível de risco - Natureza do trabalho - Recursos - Tamanho Conjunto de critérios recolhidos no contexto de um focus group realizado com diversas organizações – os atributos mais comuns e os mais importantes
92 Modelo NTCP ou Diamante Shenhar e Dvir (2007) Projetos que envolvem tecnologia Novelty - Derivative - Plataform - Breakthrough Technology - Low-Tech - Medium-Tech - High-Tech - Super-High-Tech Complexity - Assembly - System - Array Pace - Regular - Fast/Competitive - Time-Critical - Blitz Classificar os projetos através de quatro dimensões e as respetivas subdivisões Sem denominação Wheelwright e Clark (1992) Projetos de desenvolvimento de produtos - Grau de mudança no produto - Grau de mudança no processo Categorização de projetos de desenvolvimento de produtos: - Projetos derivados - Projetos de plataforma - Projetos de avanço Modelo UC Howeel, Windahl e Seidal (2010) Qualquer tipo de projeto - Consequências (C) - Incerteza (U) Identificar os modelos mais adequados para gerir um determinado projeto: - Plan Driven - Agile - Problem Structuring Sem denominação Turner e Cochrane (1993) Não especificado - Clareza dos objetivos - Clareza dos métodos para atingir os objetivos Classificar os projetos na sua fase inicial: - Projetos Tipo 1 - Projetos Tipo 2 - Projetos Tipo 3 - Projetos Tipo 4