Avaliação da Maturidade Organizacional em Gestão de Projectos de SI/TI - Administração Pública Portuguesa

Tamanho: px
Começar a partir da página:

Download "Avaliação da Maturidade Organizacional em Gestão de Projectos de SI/TI - Administração Pública Portuguesa"

Transcrição

1 Faculdade de Engenharia da Universidade do Porto Mestrado em Gestão de Informação Avaliação da Maturidade Organizacional em Gestão de Projectos de SI/TI - Administração Pública Portuguesa Maria da Conceição Gomes Vilas Boas Abril 2009

2

3 Faculdade de Engenharia da Universidade do Porto Mestrado em Gestão de Informação Avaliação da Maturidade Organizacional em Gestão de Projectos de SI/TI - Administração Pública Portuguesa Dissertação apresentada para a obtenção do grau de Mestre em Gestão de Informação Dissertação apresentada sob a orientação científica de Doutor Ademar Aguiar Professor Auxiliar do Departamento de Engenharia Informática Maria da Conceição Gomes Vilas Boas Abril 2009

4

5 Resumo Hodiernamente há uma tendência para as organizações gerirem a sua actividade de negócio (e realizar o plano estratégico [PMBOK, 2004]) através da implementação de projectos - quer os seus objectivos sejam económicos, financeiros, sociais ou políticos. Embora esta realidade possa parecer mais evidente para o sector privado é, também, um desafio crescente no sector do estado Português: a necessidade do rigor na gestão dos dinheiros públicos e, ao mesmo tempo, a redução do peso da despesa pública no PIB, como condições básicas, para aumentar a qualidade, a eficácia e eficiência dos serviços públicos. Assim, também, é colocado às entidades públicas o desafio de gerirem as suas actividades por projectos. No meio académico e organizacional é discutida a importância das boas práticas de gestão de projectos nas organizações, tais como as ditadas pelo PMI (Project Management Instute) no seu guia PMBok (Project Management Body of Knowledege), pois, se estas não estiverem enraizadas na cultura organizacional, a possibilidade da organização atingir a excelência em gestão de projectos é baixa. Vários estudos empíricos (survey e caso de estudo) e estudos teóricos, publicados desde 1960, apresentam como razões para o pobre desempenho dos projectos de Sistemas e Tecnologias de Informação (SI/TI) factores críticos ligados com a maturidade organizacional em gestão de projectos (por exemplo, como é referenciado pelos seguintes autores: Pinto and Slevin, 1987; Magal e tal., 1988; Pinto e Mantel, 1990; Yap e tal., 1992; Selin and Selin, 1994; The Standish group, 2000; Couillard, 1995; Tan, 1996; Belassi and Tukel, 1996; Kpmg, 1997; Dvir et al., 1998; Kasser and Williams, 1998; Wittaker, 1999; Taylor, 2000; Thite, 2000; Poon and Wager, 2001; Andersen et al., 2002; Yeo, 2002; Avots, 1969; Morris, 1986; Morris and Hough, 1987; McComb and Smith, 1991; Martinez, 1994; Wastell and Newman, 1996; Mcgolpin and Ward, 1997; Jang and Lee, 1998; Cooke-Davies, 2002; Caldeira and Ward, 2002; Westerveld, 2003; Cleland and King (1983); Stoddart-Stones, 1988; Cash and Fox, 1992; Tennant, 1993; Munns and Bjeirmi, 1996; McCormack, 1997; Turner, 1999; Weir, 1999; Turn, 2004; entre outros). Os modelos de maturidade CMM, CMMI, Processo PO10 da Framework CobiT, entre outros - são um instrumento disponível para avaliar, e ao mesmo tempo orientar, as organizações em direcção às melhores práticas e estratégias no que respeita à área de projectos de SI/TI. Nesta dissertação é apresentada a avaliação efectuada à maturidade organizacional em gestão de projectos na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos, com base na Framework CobiT 4.1. Assim, avalia-se a correlação entre a maturidade organizacional em gestão de projectos de SI/TI e, a maturidade organizacional em planeamento estratégico de TI, a percentagem de despesa em TI por despesa global do organismo, a percentagem de recursos humanos de TI por total de recursos humanos. Concluindo-se, assim, que as organizações com maior maturidade em planeamento estratégico de SI/TI possuem maior maturidade em gestão de projectos, tal como sugerido pelo PMI [PMBOK, 2004]. Porém, não se verificou que as organizações que possuem maior Maria da Conceição Gomes Vilas Boas iii

6 percentagem de recursos humanos de TI e as organizações que investem mais em SI/TI, ao longo do tempo, apresentem maior maturidade em gestão de projectos de SI/TI. Palavras-chave: Gestão de Projectos, Desempenho dos Projectos, Maturidade em Gestão de Projectos, Processos em Gestão de Projectos, Modelos de Maturidade, CMMI, CobiT 4.1 iv Maria da Conceição Gomes Vilas Boas

7 Abstract These days, services tend to use a project-oriented approach in order to manage their businesses (and implement their strategic plans [PMBOK, 2004]), wether their goals may lay in the economics, finantial, social or political spheres. Although this reality may seem more patent in the private sector, the Portuguese state could benefit from it as well, especially due to the need for accuracy in public budget management and public spending reduction in GDP as basic assets to public services quality, efficacy and efficiency improvement. Hence, public services are also encouraged to manage their projects in a project-oriented approach. Discussion around project management best practices implementation procedures is held in both academic and company spheres. Examples of these best practices are compiled in PMI s (Project Management Instute) PMBok guide, as the absence of these in the entity s culture may lead to a low probability of project management excellence achieval. Several empirical and academic studies (survey and case study), which have been published since 1960, present hypothesis to the Information Systems and Technology projects (IS/IT) poor performance. These tend to indicate that there are critical assets related to project management company maturity, as described by the following authors: Pinto and Slevin, 1987; Magal et al., 1988; Pinto e Mantel, 1990; Yap et al., 1992; Selin and Selin, 1994; The Standish group, 2000; Couillard, 1995; Tan, 1996; Belassi and Tukel, 1996; Kpmg, 1997; Dvir et al., 1998; Kasser and Williams, 1998; Wittaker, 1999; Taylor, 2000; Thite, 2000; Poon and Wager, 2001; Andersen et al., 2002; Yeo, 2002; Avots, 1969; Morris, 1986; Morris and Hough, 1987; McComb and Smith, 1991; Martinez, 1994; Wastell and Newman, 1996; Mcgolpin and Ward, 1997; Jang and Lee, 1998; Cooke-Davies, 2002; Caldeira and Ward, 2002; Westerveld, 2003; Cleland and King (1983); Stoddart-Stones, 1988; Cash and Fox, 1992; Tennant, 1993; Munns and Bjeirmi, 1996; McCormack, 1997; Turner, 1999; Weir, 1999; Turn, 2004; among other. Maturity models such as CMM, CMMI, PO10 Process from CobiT framework, among other, are available resources to evaluate and lead services towards best practices and strategies as far as IS/IT projects are concerned. In this thesis, we present an evaluation of the project management services maturity in the Portuguese Public Administration, including Integrated Services as well as Authonomous Funds and Services, based on CobiT 4.1 Framework. We evaluate the correlation between IS/IT project management services maturity and IT strategic plan services maturity, the percentage of IT spending in total spending per service and the percentage of IT manpower in total manpower. Hence, we conclude that societies having a higher maturity level in IS/IT strategic planning also have a higher maturity level in project management, as suggested by PMI [PMBOK, 2004]. Still, we could not find any evidence that societies with a higher percentage of IT personnel and those which make greater investments in IS/IT, per timescale, boast a greater maturity level in IS/IT project management. Keywords: Project Management, Project Performance, Project Management Maturity, Project Management Process, Maturity Models, CMMI, CobiT 4.1 Maria da Conceição Gomes Vilas Boas v

8 vi Maria da Conceição Gomes Vilas Boas

9 Dedicatória Aos meus pais Abílio e Amavélia Ao meu marido Avelino Maria da Conceição Gomes Vilas Boas vii

10 viii Maria da Conceição Gomes Vilas Boas

11 Agradecimentos Ao Professor Doutor Ademar Manuel Teixeira de Aguiar pela orientação e disponibilidade para este trabalho de investigação. À Inspecção-Geral de Finanças. Ao Senhor Inspector-Geral José Leite Martins, da Inspecção-Geral de Finanças, pela disponibilização da informação necessária para o Estudo de Caso. Maria da Conceição Gomes Vilas Boas ix

12 x Maria da Conceição Gomes Vilas Boas

13 Abreviaturas ACP AIPM CE CMM CMMI COBIT EDT EUA IGF IGF IPMA ISACA OE OPM3 PIB PLC PMBOK PMI PMO PMP SEI SI SI/TI TI TIC UMIC Áreas Chave de Processo Australian Internacional Project Management Classificador Económico Capability Maturity Model Capability Maturity Model Integration Control Objectives for Information and related Technology Estrutura de Decomposição do Trabalho Estados Unidos da América Inspecção Geral de Finanças Inspecção-Geral de Finanças International Project Management Association Information Systems Audit and Control Association Orçamento de Estado Organization Project Management Maturity Model Produto Interno Bruto Project Life Cycle Project Management Body of Knowledge Project Management Institute Project Management Office Project Management Professional Software Engineering Institute Sistema de Informação Sistema de Informação / Tecnologias de Informação Tecnologias de Informação Tecnologias de Informação e Comunicação Agência para a Sociedade do Conhecimento Maria da Conceição Gomes Vilas Boas xi

14 xii Maria da Conceição Gomes Vilas Boas

15 Lista de Figuras Figura 1 Desempenho dos Projectos de SI/TI 1994 a 2004 (The Standish Group) Figura 2 Estrutura e Capítulos da Dissertação Figura 3 Ciclo de Vida dos Projectos e Processos da Gestão de Projectos Figura 4 Áreas de Conhecimento da Gestão de Projectos Figura 5 Sucesso do Projecto Visão Tradicional Figura 6 Modelo de Sucesso de Projecto de Pinto e Slevin (1986) Figura 7 As Fases do Ciclo de Vida do Projecto e as Partes Interessadas em cada Fase Figura 8 Fases do Ciclo de Vida do Projecto, perspectiva Macro e Micro (Lim e Mohamed, 1999) Figura 9 Sucesso da Gestão de Projecto Extensão da Visão Tradicional Figura 10 Dimensão de Sucesso x Tempo (Shenhar et al., 2001) Figura 11 Importância Relativa das Dimensões de Sucesso x Tempo (Shenhar et al., 2001) Figura 12 Importância Relativa das Dimensões de Sucesso x Incerteza Tecnológica (Shenhar et al., 2001) Figura 13 Modelo Original de DeLone e McLean para Sucesso de Projectos Figura 14 Adaptação do Modelo Original de DeLone e McLean para Sucesso de Projectos Figura 15 Componentes de Sucesso do Projecto Figura 16 A Estrutura do CMM Figura 17 História do CMMs Figura 18 Representação Contínua Figura 19 Representação em Estádios Figura 20 Princípios Básicos do CobiT Figura 21 Framework CobiT Figura 22 Gráfico de Representação dos Níveis de Maturidade Figura 23 Pergunta de Investigação e Ligação às Proposições Figura 24 Amostra Figura 25 Serviços Integrados - Evolução da Despesa em TI por Organismo, 2005 a Figura 26 Serviços e Fundos Autónomos - Evolução da Despesa em TI por Organismo, 2005 a Figura 27 Despesa Média Anual em TI por Organismo 2005 a Figura 28 Serviços Integrados e Serviços e Fundos Autónomos Despesa Média em TI por Despesa Média Global (%) repartida por Organismo, 2005 a Figura 29 Serviços Integrados e Serviços e Fundos Autónomos Recursos Humanos de TI por Recursos Humanos Globais (%) repartidos por Organismo, 2005 a Figura 30 Serviços Integrados e Serviços e Fundos Autónomos Nível de Maturidade Organizacional em Planeamento Estratégico de TI Figura 31 Serviços Integrados e Serviços e Fundos Autónomos - Diagrama de Extremos-e- Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Maria da Conceição Gomes Vilas Boas xiii

16 Figura 32 Serviços Integrados - Diagrama de Extremos-e-Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Figura 33 Serviços e Fundos Autónomos - Diagrama de Extremos-e-Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Figura 34 Serviços Integrados e Serviços e Fundos Autónomos Nível de Maturidade Organizacional em Gestão de Projectos de SI/TI, 2005 a Figura 35 Serviços Integrados e Serviços e Fundos Autónomos - Diagrama de Extremos-e- Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Figura 36 Serviços Integrados - Diagrama de Extremos-e-Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Figura 37 Serviços Integrados - Diagrama de Extremos-e-Quartiz Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) xiv Maria da Conceição Gomes Vilas Boas

17 Lista de Tabelas Tabela 1 - Serviços Integrados e Serviços e Fundos Autónomos, Despesa em TI, Tabela 2 - Top 10 das Razões do Sucesso dos Projecto de SI/TI, 2001 (The Standish Group) Tabela 3 Mapeamento das Áreas de Conhecimento, Processos e Grupos de Processos Tabela 4 Críticos de sucesso de Pinto e Slevin (1986) Tabela 5 Critérios de Sucesso de Turner (1993) Tabela 6 Três Principais Critérios de Sucesso (Frequência de Citações) Segundo a Percepção dos Utilizadores e dos Gestores de Projectos Tabela 7 Cinco Principais Critérios de Sucesso (Frequência de Citações) Segundo a Percepção dos Utilizadores e dos Gestores de Projectos Tabela 8 Dimensões de Sucesso de Projecto, Segundo Dvir et al. (1998) Tabela 9 Critérios de Sucesso de Projecto, Segundo Shenhar et al. (2001) Tabela 10 Factores Críticos de Sucesso Identificados Cruzados em 63 Publicações Tabela 11 Factores Críticos de Sucesso (Yeo, 2002) Tabela 12 Elementos que Afectam, Simultaneamente, a Percepção de Sucesso e de Fracasso (Backer, Murphy e Fisher, 1983) Tabela 13 Elementos que Afectam a Percepção de Sucesso (Backer, Murphy e Fisher, 1983) Tabela 14 Elementos que Afectam a Percepção de Fracasso (Backer, Murphy e Fisher, 1983) Tabela 15 Evolução Histórica do Modelo de Capability Maturity Model for Software Tabela 16 Níveis de Maturidade do CMM Tabela 17 Áreas Chave do Processo por Nível de Maturidade Tabela 18 Comparação da Representação Contínua e Estádios Tabela 19 Comparação dos Níveis de Representação Continua e Estádios Tabela 20 Domínios vs Processos de CobiT Tabela 21 Organismos onde a Inexistência ou Escassez de Pessoal TI tem Condicionado Negativamente o Desenvolvimento das suas Actividades Tabela 22 Recursos Humanos de TI Variáveis e Medidas Tabela 23 Despesa em SI/TI Variáveis e Medidas Tabela 24 Maturidade em Planeamento Estratégico de TI Variáveis e Medidas Tabela 25 Maturidade em Gestão de Projectos Variáveis e Medidas Tabela 26 O que é uma Correlação Elevada? Segundo Cohen e Holliday (1982) Tabela 27 Serviços Integrados e Serviços e Fundos Autónomos Despesa em TI, 2005 a Tabela 28 Serviços Integrados e Serviços Fundos Autónomos Recursos Humanos TI e Recursos Humanos 2005 a Tabela 29 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre a % de Recursos Humanos de TI e a %despesa em TI Tabela 30 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos de SI/TI Tabela 31 Serviços e Fundos Autónomos - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos de SI/TI Maria da Conceição Gomes Vilas Boas xv

18 Tabela 32 Serviços Integrados - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos SI/TI Tabela 33 Organismos Prestadores de Serviços de SI/TI - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos SI/TI Tabela 34 Organismos Prestadores de Serviços de SI/TI - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos de SI/TI (Sem entidade MKS2) Tabela 35 Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos organismos prestadores de Serviços SI/TI - Correlação entre a Maturidade em Planeamento Estratégico TI e a Maturidade em Gestão de Projectos de SI/TI Tabela 36 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre Maturidade em Gestão de Projectos SI/TI e Recursos Humanos TI por Recursos Humanos Globais (%) Tabela 37 Serviços e Fundos Autónomos - Correlação entre Maturidade em Gestão de Projectos SI/TI e Recursos Humanos TI por Recursos Humanos Globais (%) Tabela 38 Serviços Integrados - Correlação entre Maturidade em Gestão de Projectos SI/TI e Recursos Humanos TI por Recursos Humanos Globais (%) Tabela 39 Organismos Prestadores de Serviços de SI/TI - Correlação entre Maturidade Organizacional em Gestão de Projectos e Percentagem de Recursos Humanos de TI Tabela 40 Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos Organismos Prestadores de Serviços SI/TI - Correlação entre Maturidade em Gestão de Projectos e Percentagem de Recursos Humanos de TI Tabela 41 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre a Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%) Tabela 42 Serviços e Fundos Autónomos - Correlação entre Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%) Tabela 43 Serviços Integrados - Correlação entre Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%) Tabela 44 Organismos Prestadores de Serviços SI/TI - Correlação entre Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%) Tabela 45 Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos Organismos Prestadores de Serviços SI/TI - Correlação entre o Nível de Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%) Tabela 46 Correlação entre o Nivel de Maturidade Organizacional em Planeamento Estratégico de TI e Nível de Maturidade Organizacional em Gestão de Projectos SI/TI Tabela 47 Correlação entre a percentagem de Recursos Humanso de TI e Nível de Maturidade Organizacional em Gestão de Projectos SI/TI Tabela 48 Correlação entre a Percentagem a Despesa em TI e Nível de Maturidade Organizacional em Gestão de Projectos SI/TI Tabela 49 Escalonamento da Despesa Média Anual vs Número de Entidades Tabela 50 Escalonamento da % de Recursos Humanos de TI vs Número de Entidades Tabela 51 Tipos de Estudos de Casos (Yin, 1989) Tabela 52 Critérios de Avaliação de Documentos (Scott, 1990) Tabela 53 Unidades de Análise Tabela 54 Recursos Humanos 2005 a xvi Maria da Conceição Gomes Vilas Boas

19 Tabela 55 Recursos Humanos de TI 2005 a Tabela 56 Despesa Global 2005 a Tabela 57 Despesa em TI 2005 a Tabela 58 Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Tabela 59 Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Tabela 60 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre os Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Tabela 61 Serviços Integrados - Correlação entre os Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Tabela 62 Serviços e Fundos Autónomos - Correlação entre Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) Tabela 63 Serviços Integrados e Serviços e Fundos Autónomos - Correlação entre Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Tabela 64 Serviços Integrados - Correlação entre Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Tabela 65 Serviços e Fundos Autónomos - Correlação entre Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos) Maria da Conceição Gomes Vilas Boas xvii

20 xviii Maria da Conceição Gomes Vilas Boas

21 Índice Resumo... iii Abstract... v Dedicatória...vii Agradecimentos... ix Abreviaturas... xi Lista de Figuras... xiii Lista de Tabelas... xv Índice...xix 1. Introdução Contexto e Motivação Objecto de Estudo Metodologia Organização da Dissertação Gestão de Projectos Enquadramento de Gestão de Projectos O que é um Projecto? Quais os Stakeholders do Projecto? O que é um Portfolio, Programa e Subprojecto? O que é a Gestão de Projectos? Quais as Capacidades Requeridas a um Gestor de Projecto? O que é um Escritório de Gestão de Projectos? Selecção e Avaliação de Projectos Selecção Estratégica de Projectos Avaliação Financeira e Técnica do Projecto Metodologia de Gestão de Projectos PMBOK Guide Ciclo de Vida da Gestão de Projectos Processo da Gestão de Projectos Áreas de Conhecimento da Gestão de Projecto Maria da Conceição Gomes Vilas Boas xix

22 2.4. Mapeamento do Processo de Gestão de Projectos Síntese Avaliação de Projectos de SI/TI Conceitos Sistema e Tecnologia de Informação Critério e Factor de Sucesso Avaliação de Projectos Critérios e Factores de Sucesso Critérios de Sucesso Factores Críticos de Sucesso Síntese Modelos de Avaliação da Maturidade Organizacional Enquadramento Capability Maturity Model (CMM) Introdução Organizações Imaturas Vs Organizações Maduras Conceitos Fundamentais Associados ao CMM Níveis de Maturidade e Áreas Chave de Processo Capability Maturity Model Integration (CMMI) Introdução ao Capability Maturity Model Integration Representações do CMMI Níveis de maturidade Control Objectives for Information and related Technologies (CobiT) Enquadramento Conceitos e Definições Fundamentais para a Framework CobiT Princípios da Framework CobiT Modelo de Maturidade Planeamento Estratégico de TI e Gestão de Projectos Avaliação da Maturidade - Síntese O Problema Problema de Investigação Pergunta de Investigação e Proposições Tipo de Estudo Metodologia de Investigação xx Maria da Conceição Gomes Vilas Boas

23 6.1. Escolha das Unidade de Análise Instrumento de Recolha de Informação Recursos Humanos de TI Despesa em SI/TI Maturidade Organizacional em Planeamento Estratégico de TI e Gestão de Projectos de SI/TI Correlação entre as Variáveis do Estudo Estratégia de Recolha de Dados Recolha de Dados e Análise de Dados Estudo de Caso Características da Amostra Resultados da Análise Características da Despesa em TI e Recursos Humanos Características da Maturidade Organizacional Análise das Proposições Síntese dos Resultados do Estudo de Caso Conclusões e Trabalho Futuro Conclusões Limitações e Constrangimentos ao Trabalho Contributos Trabalho Futuro Referências Anexo A: O Método de Estudo de Caso A.1 Definição do Método de Estudo de Caso A.2 O Uso do Método de Estudo de Caso A.3 O Plano de Estudo de Caso A.4 Critérios para Avaliar a Qualidade do Estudo de Caso A.5 Tipos de Estudo de Caso A.6 O Protocolo do Estudo de Caso A.7 Condução do Estudo de Caso Anexo B: Unidades de Análise Anexo C: Análise do Classificador Económico das Despesas SI/TI Maria da Conceição Gomes Vilas Boas xxi

24 Anexo D: Questionário Anexo E: Respostas ao Questionário E.1 Recursos Humanos 2005 A E.2 Recursos Humanos de TI 2005 A E.3 Despesa Global 2005 a E.4 Despesa em TI 2005 a E.5 Planeamento Estratégico de TI E.6 Gestão de Projectos E.7 Correlação entre os Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) E.8 Correlação entre os Objectivos de Controlo do Processo PO10 (Gestão de Projectos) xxii Maria da Conceição Gomes Vilas Boas

25 1. Introdução 1.1. Contexto e Motivação Hodiernamente há uma tendência para as organizações gerirem a sua actividade de negócio (e realizar o plano estratégico [PMBOK, 2004]) através da implementação de projectos - quer os seus objectivos sejam económicos, financeiros, sociais ou políticos. Embora esta realidade possa parecer mais evidente para o sector privado este é, também, um desafio crescente no sector do estado Português: a necessidade do rigor na gestão dos dinheiros públicos e a redução do peso da despesa pública no PIB, como condições básicas, para aumentar a qualidade, a eficácia e eficiência dos serviços públicos. Assim é colocado às entidades públicas também o desafio de gerirem as suas actividades por projectos. Mas por que é tão importante avaliar a maturidade organizacional em gestão de projectos de Sistemas e Tecnologias de Informação (SI/TI)? A resposta é simples: (1) As organizações nas economias mais desenvolvidas investem elevados como crescentes recursos - financeiros, humanos, materiais e tecnológicos - em Sistemas e Tecnologias de Informação (SI/TI 1 ) na perspectiva de melhorar a sua eficiência e eficácia. Investimentos em TI na Administração Pública Portuguesa 2005 a 2007 A realidade da Administração Pública Portuguesa não escapa a esta evidência. De acordo com o recente estudo da Inspecção-Geral de Finanças (2008), no período 2005 a 2007, a Administração Pública Portuguesa, Serviços Integrados e Serviços e Fundos Autónomos, em matéria de despesa em TI assumiu um encargo global anual médio de cerca 432,4 milhões de euros correspondendo aproximadamente: em 2005 a 423,04 milhões de euros; em 2006 a 429,90 milhões de euros e em 2007 a 444,27 milhões de euros (vide tabela 1). Un.: Anos Serviços Integrados (a) Serviços e Fundos Autónomos (b) Total de TI (a+b) , , , , , , , , ,25 Média , , ,02 % 52,8% 47,2% 100% Tabela 1 - Serviços Integrados e Serviços e Fundos Autónomos, Despesa em TI, Fonte: adaptado do relatório nº 1290/2008, da IGF. 1 Ver definição de SI/TI no ponto Maria da Conceição Gomes Vilas Boas 1

26 O sector que mais pesa na execução orçamental das TI é o dos Serviços Integrados, com montantes que representam cerca de 52,8% da média anual da despesa. Os restantes 47,2% dizem respeito aos Serviços e Fundos Autónomos. No mesmo estudo da Inspecção-Geral de Finanças (IGF) relata-se ainda que a maior fatia da despesa em TI, no triénio em análise, refere-se: a comunicações 2 com um valor médio anual aproximado de 200,65 milhões de euros (46,40%); a hardware 3 aproximadamente 122,55 milhões de euros (28,34%); a software informático 4 aproximadamente 97,51 milhões de euros (22,55%); a locação de material de informática 5 aproximadamente 11,28 milhões de euros (2,61%) e material de informática - locação financeira 6 aproximadamente 0,41 milhões de euros (0,09%). Investimentos em TI na Administração Pública Portuguesa Previstos 2009 Não se prevê que nos próximos anos haja um abrandamento nos investimentos. Segundo as contas do Orçamento de Estado (OE) 2009 as empresas do mercado das Tecnologias de Informação e Comunicação vão apresentar ao Estado, Serviços Integrados e Serviços e Fundos Autónomos, uma factura de 574,6 milhões de euros: incluindo fornecedores de serviços de comunicações, equipamentos e software. Dado que uma fatia significativa do orçamento dos organismos Públicos Portugueses é afecto a investimentos em TI, e se estima que venha a crescer num futuro próximo, qual é o nível de maturidade organizacional em gestão de projectos SI/TI? Desempenho dos Projectos de SI/TI a Nível Internacional (2) Muitos projectos de Tecnologias e Sistemas de Informação, dos organismos públicos e privados, têm sido denunciados na literatura como projectos de insucesso. Tendo como referência as estatísticas do Standish Group International, publicadas nas várias edições do relatório The Chaos Report que são uma das publicações mais citadas em artigos da especialidade [Boehm, 2000], verifica-se que, apenas, um número reduzido de projectos pode ser considerado de sucesso vide figura 1. 2 «Despesa em comunicações» compreende o somatório das despesas classificada na rubrica com a CE: «Comunicações». 3 «Despesa em hardware» compreende o somatório das despesas classificadas nas seguintes rubricas com a CE: «Equipamento de informática»; Y0.A0 - «Equipamento administrativo - hardware de comunicações»; Y0.A0 - «Equipamento básico - hardware de comunicações». 4 «Despesa em software informático» compreende o somatório das despesas classificadas na rubrica com a CE: «Software de Informática». 5 «Despesa em locação de material informático» compreende o somatório das despesas classificadas na rubrica com a CE: «Locação de Material de informática». 6 «Despesa em locação de material de informática» compreende o somatório das despesas classificada na rubrica com a CE: «Material de Informática - locação financeira». 2 Maria da Conceição Gomes Vilas Boas

27 60% 50% 40% 30% 20% 10% 0% Sucesso ( Successed ) 16% 27% 26% 28% 29% Insucesso ( Failed ) 31% 40% 28% 23% 18% Sucesso parcial ( Challenged ) 53% 33% 46% 49% 53% Figura 1 Desempenho dos Projectos de SI/TI 1994 a 2004 (The Standish Group). Fonte: Autor. Legenda: O Standish Group classifica o desempenho do projecto em três categorias: a) Sucesso (successfull): O projecto é concluído no prazo, dentro do orçamento, com todos os requisitos e funcionalidades. b) Sucesso parcial (challenged): O projecto está concluído e operacional, mas acima do orçamento, atrasado, com poucos requisitos e funcionalidades especificadas. c) Falhou (failed): O projecto foi cancelado antes da sua conclusão ou nunca foi implementado. Quando olhamos para a definição de sucesso do Standish Group Internacional verifica-se que, apenas, um número reduzido de projectos pode ser considerado de sucesso. Embora a taxa de sucesso tenha melhorado um pouco, as falhas dos projectos situam-se em níveis superiores aos das outras especialidades de engenharia. Porém, o conceito de insucesso e de sucesso do projecto é muito nebuloso [Pinto et al., 1990] existindo uma variedade de definições [Agarwal et al., 2006]. Essas definições de sucesso não se limitam ao prazo, custos e especificações técnicas (como é referenciado pelos seguintes autores: Power e Diskson, 1973; Backer, Murphy e Fisher, 1983; Pinto e Slevin, 1986; Morris e Hough, 1987; Wit, 1988; Pinto e Mantel, 1990; Turner, 1993; Wateridge, 1995 e 1998, entre outros) vide ponto Assim, pode dizer-se que a taxa de insucesso de projectos provavelmente será mais elevada. Refira-se ainda, tal como ilustra o próprio título da pesquisa denominada The Lastest Chaos Report in Project Management [Standish Group International, 2004], os projectos de desenvolvimento de sistemas de informação permanecem, invariavelmente, associados ao insucesso: sendo que a parcela deste mau desempenho é justificada pelo incorrecto e/ou pela inadequação das práticas de gestão de projectos; pela falta de capacidade da gestão em lidar com a complexidade e incerteza inerentes aos projectos e não às dificuldades técnicas vide tabela 2. Maria da Conceição Gomes Vilas Boas 3

28 Razões Valores em % Apoio dos Gestores 18 Envolvimento dos utilizadores 16 Experiência do Gestor de Projectos 14 Objectivos de negócio claros 12 Standard de Infra-estrutura de Software 8 Definição clara dos requisitos 6 Metodologia Formal 6 Estimativas Realistas 5 Outros 5 Tabela 2 - Top 10 das Razões do Sucesso dos Projecto de SI/TI, 2001 (The Standish Group). Fonte: Adaptado do The Standish Group, Chaos Report (2001). Desde 1960 vários autores têm publicado, em estudos empíricos (survey e caso de estudo) e estudos teóricos, as razões do pobre desempenho dos projectos de SI/TI e alertado para um conjunto de factores críticos de sucesso para os projectos (por exemplo, como é referenciado pelos seguintes autores: Pinto and Slevin, 1987; Magal et al., 1988; Pinto e Mantel, 1990; Yap et al., 1992; Selin and Selin, 1994; The Standish group, 2000; Couillard, 1995; Tan, 1996; Belassi and Tukel, 1996; Kpmg, 1997; Dvir et al., 1998; Kasser and Williams, 1998; Wittaker, 1999; Taylor, 2000; Thite, 2000; Poon and Wager, 2001; Andersen et al., 2002; Yeo, 2002; Avots, 1969; Morris, 1986; Morris and Hough, 1987; McComb and Smith, 1991; Martinez, 1994; Wastell and Newman, 1996; Mcgolpin and Ward, 1997; Jang and Lee, 1998; Cooke- Davies, 2002; Caldeira and Ward, 2002; Westerveld, 2003; Cleland and King (1983); Stoddart- Stones, 1988; Cash and Fox, 1992; Tennant, 1993; Munns and Bjeirmi, 1996; McCormack, 1997; Turner, 1999; Weir, 1999; Turn, 2004; entre outros) vide ponto Esses estudos têm mostrado que os problemas dos projectos de SI/TI são de gestão e não técnicos. Isto é, os factores críticos analisados nas diversas publicações evidenciam as carências em gestão de projectos (maturidade da organização em gestão de projecto e a capacidades do gestor de projecto) e numa análise mais profunda as causas pelos maus resultados dos projectos. Também, a publicação Project Manager Competency Development (PMCD) Framework do PMI (páginas 1 a 5) afirma que as competências do gestor do projecto, e maturidade da organização em gestão de projectos, afectam o desempenho dos projectos (sucesso). Para Jeffery K. Pinto (1998) o sucesso dos projectos está directamente relacionado com a capacidade dos gestores dos projectos e os outros stakeholdes. A Maturidade Organizacional em Gestão de Projectos (3) Diversos estudos demonstram que as organizações apresentam diferentes níveis de maturidade em gestão de projectos - e o uso de processos eficazes pode ajudar ao sucesso do projecto. Paulk, Mark C. (1993) afirma que: alguns projectos isoladamente produzem excelentes resultados. Quanto tais projectos são bem-sucedidos, é geralmente graças a esforços heróicos de uma equipa dedicada, e não através de repetição de métodos provados de uma organização com um processo de software maduro. Na ausência de um processo abrangente na organização, a repetição dos resultados depende inteiramente de se ter as pessoas disponíveis para o 4 Maria da Conceição Gomes Vilas Boas

29 próximo projecto. O sucesso, que depende de pessoas específicas, não fornece condições para a melhoria da produtividade e da qualidade na organização por um longo período. Melhoramentos contínuos só podem ocorrer através de esforços focados e sustentados na direcção da construção de uma infra-estrutura de processo de desenvolvimento de software e práticas de gestão efectivas. Os modelos de maturidade de gestão de projectos defendem a ideia de que organizações maduras possuem um desempenho superior. As organizações que possuem um alto nível de maturidade em gestão de projecto devem conseguir, de forma regular, obter resultados superiores nos projectos que desenvolvem. Sendo estes obtidos através de uma estrutura organizacional que sustenta, inclusive, processos de gestão estáveis, alinhados com a estratégia da organização e suportados pela gestão de topo. Preocupação Estratégica em Gestão de Projectos (4) Investir em conhecimento, metodologias e ferramentas de gestão de projecto é uma preocupação estratégica em diversas lideranças empresariais - isto pode ser percebido pelo número de instituições preocupadas em disseminar a disciplina de gestão de projectos e pelo número de profissionais certificados em gestão de projectos vide ponto 2. O interesse em gestão de projectos pode também ser explicado pelo número de modelos de avaliação da maturidade em gestão de projectos existentes como por exemplo: (1) Capability Maturity Model for Software (SW-CMM); (2) Project Management Maturity Model (PMMM); (3) Organization Project Management Maturity Model (OPM3); (4) Control Objectives for Information and related Tecnology (CobiT), em especial o processo designado de PO10 Gestão de Projecto. Em Portugal não se conhecem estudos que demonstram a maturidade organizacional em gestão de projectos na Administração Pública. Porém, é do conhecimento geral, as preocupações com a institucionalização da gestão de projectos nas entidades do Estado Português têm aumentado: devido às possibilidades de bons resultados (eficiência, eficácia e economia) conseguidos pelas boas práticas (sugeridas) das metodologias da gestão de projectos Objecto de Estudo Das considerações anteriormente referidas, considera-se pertinente efectuar uma investigação tendo como objecto de estudo a Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública Portuguesa. Assim, o Problema de Investigação é: Avaliar a Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos. Tendo como Pergunta de Investigação: Qual o actual nível de maturidade organizacional em gestão de projectos de SI/TI na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos e Qual a correlação com: maturidade organizacional em planeamento estratégico de TI; recursos humanos de TI por recursos humanos globais (%) e a despesa em TI por despesa global (%). Maria da Conceição Gomes Vilas Boas 5

30 No capítulo 5, do presente documento, apresenta-se de forma mais detalhada o objecto de estudo, problema de investigação, perguntas de investigação e proposições Metodologia Com o objectivo de avaliar a maturidade em gestão de projectos na Administração Pública - Serviços Integrados e Serviços e Fundos Autónomos - adoptou-se a metodologia de Estudo de Caso, conforme sugerido por Yin (1989). Primeiramente, efectuou-se um levantamento bibliográfico sobre metodologia de gestão de projectos PMBOK e avaliação de projectos de SI/TI, com o objectivo de possibilitar a formulação do problema de investigação, além de delinear o estado da arte relacionado ao problema de pesquisa. A seguir, para responder ao problema de pesquisa, foi feita uma revisão da literatura sobre modelos de avaliação da maturidade organizacional CMM, CMMI e Framework CobiT 4.1. Na segunda fase, dada a natureza da pergunta de investigação apontar para a necessidade de se obterem dados estatísticos, que permitissem caracterizar o panorama da Administração Pública Portuguesa, em termos de adopção de metodologias de gestão de projectos. De acordo com Yin (1989), a metodologia mais adequada para responder a este tipo de questões é o questionário, com uma análise quantitativa dos dados. Para avaliar a maturidade organizacional em gestão de projectos adoptou-se a framework CobiT 4.1. Essa escolha justifica-se pelo facto o CobiT ser adequado também para avaliar a maturidade organizacional em Planeamento Estratégico de TI, bem como proporcionar uma avaliação disciplinada e fácil interpretação. No capítulo 6, do presente documento, apresenta-se de forma mais detalhada a metodologia de investigação Organização da Dissertação Esta dissertação encontra-se estruturada em oito capítulos, conforme ilustra a figura 2. Sendo o capítulo 1 ( Introdução ), o presente, apresenta-se a seguir os restantes sete capítulos. Parte 1: Estado da Arte Revisão da Literatura. Esta primeira parte fornece uma revisão da literatura sobre Gestão de Projectos, Avaliação de Projectos de SI/TI e Modelos de Avaliação da Maturidade em Gestão de Projectos: O capítulo 2, Gestão de Projectos, apresenta os fundamentos teóricos que procuram contextualizar o tema de Gestão de Projectos. Com este propósito, neste capítulo, são analisados (e discutidos) os fundamentais sobre gestão de projectos os conceitos, processos, metodologias, ferramentas e práticas apresentadas estão inteiramente alinhadas com PMBOK Guide (A Guide to the Project Management Body of Knowledge); O capítulo 3, Avaliação de Projectos de SI/TI, apresenta uma revisão da literatura de vários estudos empíricos e estudos teóricos sobre critérios de sucesso dos projectos e dos factores críticos; 6 Maria da Conceição Gomes Vilas Boas

31 O capítulo 4, Modelos de Avaliação da Maturidade Organizacional, apresenta o conceito de maturidade em gestão de projectos. Em seguida, apresenta uma visão geral dos principais modelos de maturidade em gestão de projectos destacando-se os modelos CMM Capability Maturity Model, CMMI Capability Maturity Model Integration e CobiT 4.1 Control Objectives for Information and related Technologies. Parte 2: Problema e Metodologia de Investigação. Esta segunda parte apresenta o problema de investigação e a metodologia seguida na investigação: O capítulo 5, O Problema, apresenta o problema de investigação tendo por base a revisão da literatura efectuada nos capítulos anteriores, a pergunta de investigação, proposições e tipo de estudo; O capítulo 6, Metodologia de Investigação, efectua uma breve revisão da literatura sobre o método de pesquisa escolhido para a investigação o método de Estudo de Caso. Seguindo-se a apresentação da metodologia e procedimentos seguidos na presente investigação que envolveu o levantamento bibliográfico, definição da amostra relativa aos organismos da Administração Pública Portuguesa, que foram alvo de avaliação da maturidade organizacional em gestão de projectos, dos procedimentos estatísticos adoptados para a recolha e tratamento dos dados. Parte 3: Estudo de Caso e Conclusões. A terceira parte apresenta a avaliação efectuada à Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública e as conclusões da investigação: O capítulo 7, Estudo de Caso, apresenta o estudo realizado para avaliar a maturidade organizacional em gestão de projectos de SI/TI na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos; O capítulo 8, Conclusões e Trabalho Futuro, apresenta as conclusões principais que o trabalho desenvolvido permitiu identificar e propostas de trabalho futuro na área temática desta dissertação. Capítulo 1: Introdução Parte 1: Estado da Arte - Revisão da Literatura Parte 2: Problema e Medodologia de Investigação Parte 3: Estudos e Conclusões Capítulo 2: Gestão de Projectos Capítulo 3: Avaliação de Projectos de SI/TI Capítulo 4: Modelos de Avaliação da Maturidade Organizacio nal Capítulo 5: O Problema Capítulo 6: Metodologia de Investigação Capítulo 7: Estudo de Caso Capítulo 8: Conclusões e Trabalho Futuro Figura 2 Estrutura e Capítulos da Dissertação. Fonte: Autor. Maria da Conceição Gomes Vilas Boas 7

32 8 Maria da Conceição Gomes Vilas Boas

33 2. Gestão de Projectos Este capítulo apresenta os fundamentos teóricos que procuram contextualizar o tema de Gestão de Projectos. Com este propósito, neste capítulo, são analisadas e discutidas as noções fundamentais sobre gestão de projectos conceitos, processos, metodologias, ferramentas e práticas apresentadas estão inteiramente alinhadas com o PMBOK Guide (A Guide to the Project Management Body of Knowledge 7 ). Investir em gestão de projectos é uma preocupação estratégica, nas diversas lideranças empresariais - isto pode ser percebido pelo crescimento de interessados em entender e se profissionalizar em gestão de projectos. As instituições preocupadas em disseminar a disciplina de gestão de projectos e promover a profissão de gestão de projectos estão em expansão em todos os Continentes. O número de associados do PMI Project Management Institute - instituição com sede nos EUA, presentemente em mais de 170 países, incluindo em Portugal, que agrega e dissemina informação sobre gestão de projectos - cresce de forma consistente. Na década de 90, o número de sócios individuais do PMI atingiu a marca de 50 mil e a gestão de projectos consolidou-se como uma metodologia. Diversos estudiosos de engenharia e gestão mencionam-na como disciplina obrigatória nas organizações que querem desenvolver e manter vantagens competitivas. No início do ano de 2009, este número chegou à casa dos 256 mil e atingiu a marca de, aproximadamente, 10 mil profissionais, certificados com o título de PMP Project Management Profissional [PMI, 2009]. Percebe-se, também, um crescimento de instituições fora do continente americano; entre elas merece destaque o IPMA Internacional Project Management Association, que agrega os países europeus, da América do Norte e Sul, Ásia, África e Médio Oriente - e o AIPM Australian Internacional Project Management, que representa a Austrália e países vizinhos. 7 A Guide to the Project Management Body of Knowledge é considerado uma Norma ANSI (EUA) sobre Gestão de Projecto, com a Ref. ANS/PMI Maria da Conceição Gomes Vilas Boas 9

34 2.1. Enquadramento de Gestão de Projectos O que é um Projecto? Como ponto essencial de análise, à problemática em causa, é importante podermos definir de forma clara e objectiva o que se entende por projecto. Consultando a literatura poderemos encontrar uma grande variedade de definições, em termos das suas características e condições, algumas das quais são apresentadas a seguir ([PMBOK, 2000], [PMBOK, 2004], [WWPMM, 2002], [Agarwal et al., 2006]): Um projecto é um empreendimento temporário realizado para criar um produto ou serviço únicos. Temporário significa que tem um início e um fim definidos, terminando quando os seus objectivos forem alcançados (ou quando torna-se claro que os objectivos do projecto não serão ou não poderão ser atingidos). Único significado que o produto ou serviço é diferente de alguma forma de todos os outros produtos ou serviços similares [PMBOK, 2000]; Um projecto é de elaboração progressiva. Elaboração progressiva significa desenvolver em etapas e continuar por incrementos [PMBOK, 2004]; Os projectos são realizados em todos os níveis da organização e podem envolver uma única pessoa ou muitas pessoas. Sua duração varia de poucas semanas a vários anos. Os projectos podem envolver uma ou várias unidades organizacionais, como jointventure e parcerias [PMBOK, 2004]; Os projectos são, portanto, frequentemente utilizados como um meio de atingir o plano estratégico de uma organização, seja a equipa do projecto formada por funcionários da organização ou prestadores de serviços contratado. [PMBOK, 2004]; Um projecto pode interagir com outros projectos paralelos [PMBOK, 2004]; Um projecto é um empreendimento no qual estão organizados recursos humanos, materiais e financeiros, para realizar um determinado trabalho, com uma determinada especificação, com restrições de custo e de tempo, de forma a conseguir alterações benéficas, através da obtenção de objectivos quantitativos e qualitativos [PMBOK, 2004]; Os recursos disponíveis para a realização de um projecto são restritos. Estes recursos são essencialmente o capital, os recursos humanos e o equipamento [PMBOK, 2004]; A execução de um projecto pode envolver um grau considerável de incerteza. As principais fontes de incerteza incluem variação no desempenho dos recursos, dados inadequados ou incorrectos, e a incapacidade de prever satisfatoriamente devido à falta de experiência anterior [PMBOK, 2004]; A project is an endeavor in which human, material and financial resources are organized in a novel way, to undertake a unique scope of work, of given specification, within constraints of cost and time, so as to achieve beneficial change defined by quantitative and qualitative objectives. Turned (2003), citado Agarwal (2006); Projects are the building blocks for programs and portfolios. A Project is a temporary endeavour undertaken to create a unique product or service. Project are considered to be tactical since the are shorts term, and do not existed in isolation but are part of program [WWPMM, 2002]. 10 Maria da Conceição Gomes Vilas Boas

35 Tal como observamos nas definições acima apresentadas, não existe uma definição consensual sobre o que é um projecto. No entanto, é de notar que na definição de projecto os autores tentam refugiar-se nas características que evidenciam a actividade do projecto: temporário, único, progressivamente elaborado, com as actividades interligadas e sequenciais, âmbito definido (isto é, objectivos claramente definidos), orçamentado (de acordo com as especificações do cliente) e de acordo com as especificações. Em termos gerais, um projecto pode ser definido como uma actividade ou um conjunto de tarefas que é realizada uma vez, que envolve um certo grau de incertezas, tendo objectivos específicos a ser cumpridos de acordo com os requisitos previamente definidos, obedecendo a datas de início e de fim pré-estabelecidas, e dispondo de um orçamento limitado para a aquisição dos recursos necessários. Estas definições permitem-nos concluir que a execução de um projecto é uma tarefa realmente complexa 8, sendo portanto necessária uma grande preocupação com uma correcta e eficiente gestão de projecto. Todos os projectos envolvem; planeamento; gestão de recursos financeiros; gestão de pessoas e equipamentos; prazos; qualidade e âmbito Quais os Stakeholders do Projecto? Stakeholders (isto é, os intervenientes do projecto) são pessoas e organizações, como clientes, patrocinadores, organizações que desenvolvem os projectos, o público, ou seja que estejam activamente envolvidos no projecto ou cujos interesses possam ser afectados de forma positiva ou negativa pela execução ou término do projecto [Baccarini, 1999]. Eles podem também exercer influências sobre o projecto e as suas entregas [PMBOK, 2004,]. Segundo o PMBOK Guide 2004 os Stakeholders em qualquer projecto incluem, pelo menos, os seguintes elementos: Gestor do projecto/chefe do projecto. Pessoal responsável pela gestão do projecto; Cliente/Utilizador. Indivíduo, ou organização, que irá usar o produto do projecto. Podem existir muitos níveis de clientes. Por exemplo, os clientes de um novo projecto farmacêutico podem incluir os médicos que prescrevem, os pacientes que o usam e as seguradoras que pagam; Organização que desenvolve o projecto. Organização cujos elementos estão mais directamente envolvidos na realização do trabalho do projecto; Equipa de projecto. Grupo que executa o trabalho do projecto; Equipa de Gestão de projecto. Membros da equipa de projecto que estão directamente envolvidos na actividade de gestão de projecto; Patrocinador/Sponsor do projecto. Pessoa que patrocina o projecto, o seu campeão dentro da organização a quem se destina o projecto; Influenciadores. Pessoas ou grupos que estão directamente relacionadas com a aquisição ou uso do produto do projecto. Devido à posição que ocupam na 8 A complex project is not a separately defined item but is a characterization of a Project. A combination of thing such as: size, technology, multiple suppliers, geographically dispersed teams and/or user groups, fixed schedules, fixed cost or price, multiple subprojects, many deliverables, etc. would combine to form a complex project. A complex project still maintains the characteristic of a project by having a definite beginning and end, and producing a unique product or service, with a defined scope [WWPMM, 2002]. Maria da Conceição Gomes Vilas Boas 11

36 organização do cliente, ou da que desenvolve, o projecto podem influenciar positivamente ou negativamente o desenrolar do projecto; Fornecedores. As empresas, ou indivíduos, subcontratados para executar partes do projecto (ou o projecto na totalidade) O que é um Portfolio, Programa e Subprojecto? Também, como ponto essencial à problemática em causa, é importante podermos definir o que se entende por portfolio, programa e subprojecto, apesar de serem termos banalizados na linguagem comum, verifica-se serem conceitos sem entendimento universal, pelo que se julga pertinente apresentar aqui as definições utilizadas ao longo deste trabalho. Programa. É um conjunto de projectos que, pela sua natureza e respectivas inter-relações, devem ser geridos de uma forma coordenada a fim de obter benefícios e controlo não disponíveis se os projectos forem geridos individualmente. Os programas também envolvem uma série de empreendimentos repetitivos e cíclicos [PMBOK, 2004]. A program is a long term endeavor undertaken to implement a strategy or mission to meet business or organizational activity goals. Programs are realized though multiple projects and/or ongoing activity. Programs are considered to be strategic as they are long term with an evolving content [WWPMM, 2002]. Ao contrário da gestão de projectos, a gestão de programas é a gestão centralizada e coordenada de um grupo de projectos para atingir os objectivos (e benefícios) estratégicos do programa. Os projectos podem ser integrados em programas por diversas razões [António Miguel, 2006, pág. 12]: Necessidade de um relato global em todos os projectos; Necessidade de modelar os impactos lógicos que cada projecto tem em outros projectos (dependências inter-projectos); Necessidade de monitorar a utilização de recursos, quando os projectos partilham os mesmos recursos; nesta situação de partilha de recursos, os projectos de cada projecto sobre os outros exerce-se ao nível da disponibilidade de recursos. Portfolio (de projectos). É uma visão do negócio através de projectos e/ou programas que partilha características comuns (ou seja, facilita a gestão eficaz do trabalho a fim de atender aos objectivos estratégicos do negócio). As organizações gerem os seus portfolios com base em metas específicas. Os portfolios são constituídos frequentemente por projectos similares que usam o mesmo conjunto de recursos. Com a gestão do portfolio uma organização optimiza o conjunto de projectos em função dos recursos escassos de que dispõe [PMBOK, 2004] e [WWPMM, 2002]. Subprojecto. Os projectos são frequentemente divididos em componentes mais fáceis de gerir ou subprojectos - embora os subprojectos individuais possam ser chamados de projectos e geridos como tal [PMBOK, 2004]. 12 Maria da Conceição Gomes Vilas Boas

37 O que é a Gestão de Projectos? Evolução Histórica. Os conceitos de gestão de projecto têm evoluído consideravelmente, o que se deve às emergentes necessidades das organizações em fazerem face às exigências a nível de tempo, recursos e especificações, de maneira a responderem às necessidades cada vez mais rápida e eficazmente, para assim se demarcarem de uma concorrência com crescente índice de competitividade. Até 1940 os projectos eram implementados à sorte. Durante a 2ª Guerra Mundial as exigências da guerra forçaram os governantes a perseguir formas mais sistemáticas de levar a cabo os projectos. A gestão de projectos emergiu como uma disciplina em 1950, primeiramente, na construção e em sectores da economia. Hoje, virtualmente todas as organizações empregam gestores de projectos; o crescimento mais explosivo está a ocorrer nas organizações baseadas em conhecimento, como as tecnologias de informação, finanças e farmacêutico. A gestão de projectos tornou-se na abordagem mais utilizada para gerir negócios, afirmandose por volta da década de 90, muitas organizações começaram a ter consciência de que a implementação da gestão de projectos era uma necessidade, não uma opção. Embora até aí se tenham levado a cabo milhares de projectos é nesta altura que a gestão de projectos se torna reconhecida como uma disciplina de gestão. A gestão de projecto pode então afirmar-se que é uma abordagem relacionada com a obtenção de trabalho feito a tempo, respeitando o orçamento e cumprindo com as especificações [PMBOK, 2004]. De acordo com a PMI a gestão de projectos é a aplicação de conhecimentos, capacidades, ferramentas e técnicas às actividades do projecto a fim de atender aos requisitos. A gestão de projectos é realizada através da aplicação e interacção dos seguintes processos de gestão de projectos: iniciação, planeamento, execução, monitorização e controle, e encerramento [PMBOK, 2004], conforme descrito no ponto Ou seja, o principal centro de interesse está nos resultados obtidos. Quando os profissionais desenvolvem projectos tentam direccionar os seus esforços para atingir resultados claramente definidos. No entanto, hoje em dia, dada a acelerada competitividade, as organizações confrontam-se com a necessidade de realizar os seus trabalhos rapidamente, cada vez mais rapidamente. Isto leva a que os gestores de projectos tenham de fazer mais com menos: as restrições orçamentais e as restrições de especificação limitam a capacidade discricionária que os grupos de projecto podem empregar na produção de deliverables. Dessa forma, a disciplina de gestão de projectos vem ganhando destaque dentro dos modelos de gestão. Ela tem-se transformado num factor relevante para prover velocidade, robustez, consistência e excelência operacional na consecução de projectos. Essencialmente, o trabalho desenvolvido sob uma abordagem de gestão de projectos difere, radicalmente, do trabalho executado nas organizações com um funcionamento tradicional. Nas organizações tradicionais os profissionais fazem o trabalho num ambiente em que as funções são facilmente definidas e em que a gestão de controlo está enraizada sem sequência de comando. Maria da Conceição Gomes Vilas Boas 13

38 Conceito de Gestão de Projectos. Como ponto essencial de análise à problemática em causa é importante podermos definir, de forma clara e objectiva, o que se entende por gestão de projectos. Consultada a literatura poderemos encontrar uma grande variedade de definições, em termos das suas características e condições, algumas das quais são apresentadas a seguir: A gestão de projectos é a aplicação de conhecimentos, das competências e de um conjunto de ferramentas e técnicas às actividades do projecto a fim de atender aos requisitos. A gestão de projectos é realizada através da aplicação e interacção dos seguintes processos de gestão de projectos: iniciação, planeamento, execução, monitorização e controle, e encerramento [PMBOK, 2004, pág. 8]; A gestão de projectos pode então afirmar-se que é uma abordagem relacionada com a obtenção de trabalho feito a tempo, respeitando o orçamento e cumprindo com as especificações [PMBOK, 2004]; Gestão de projectos é uma forma sistematizada de trabalho que permite planear, executar, controlar e coordenar as acções necessárias para a criação da obra única. Promove a optimização dos recursos com o objectivo de conseguir criar a obra única: nos melhores tempo, qualidade e custo; Cumprindo o âmbito e os objectivos definidos [INA, 2007]; Project management is one of the main organizational activities performed within industrial organizations [Lipovetsky et al., 1997]; Gestão de projectos é proporcionar uma metodologia sistematizada de trabalho que permita desenvolver uma acção planeada e concertada [INA, 2007]; Project management is a formalised and structured method of managing change in a rigorous manner. It focuses on developing specifically defined outputs that are to be delivered by a certain time, to a defined quality and with a given level of resources so that planned outcomes/benefits are achieved. Effective project management is essential for the success of a project. The application of any general project management methodology requires an appropriate consideration of the corporate and business culture that forms a particular project s environment [Tasmanian, 2005]. Gestão de projectos é a aplicação de uma colecção de ferramentas e técnicas (como o CPM - Método do Caminho Critico 9 e da matriz organizacional) para direccionar a utilização de diversos recursos em direcção à realização de uma única, complexa tarefa - dentro do tempo, custo, qualidade e constrangimentos. Cada tarefa requer uma combinação especial de ferramentas (e técnicas) estruturadas para a tarefa ambiente e do ciclo de vida (desde a concepção até a conclusão) da tarefa [Atkinson, 1999]. Tal como observamos, nas definições acima apresentadas, não existe uma definição consensual sobre o que é a gestão de projectos. No entanto, é de notar que na definição de gestão de projectos, os autores tentam refugiar-se em quatro factores/ideias cruciais: pessoas, produto, processos e projecto. Em termos gerais, a gestão de projectos pode ser definida como a aplicação de conhecimento, capacidades e técnicas (isto é, metodologia sistematizada), a fim de satisfazer ou exceder as necessidades como as expectativas dos stakeholders (interessados e envolvidos) o que envolve 9 Critical Path Method. 14 Maria da Conceição Gomes Vilas Boas

39 manter em equilibro o âmbito, custo, prazo e qualidade Quais as Capacidades Requeridas a um Gestor de Projecto? O gestor de projecto é o responsável por administrar um conjunto de processos de trabalho, aplicar as ferramentas e as técnicas adequadas, para executar as actividades do projecto. A gestão de projectos implica, pois, o aperfeiçoamento de várias capacidades e requer a aplicação de diversas técnicas. De acordo com a metodologia PMBOK a gestão de projectos é a aplicação do conhecimento, das competências e de um conjunto de ferramentas (e técnicas) às actividades de um projecto, de forma a responder aos requisitos e exigências desse mesmo projecto. O gestor de projecto é responsável por assegurar que tais técnicas sejam sistematicamente utilizadas. A própria metodologia PMBOK destaca a necessidade de o gestor e a equipa de projecto aperfeiçoarem, pelo menos, sete capacidades [INA, 2007]: Capacidade de comunicação com os outros. Um dos atributos mais importantes de um gestor de projectos é a comunicação. Assegurar que as informações sejam explícitas, claras e completas, para que ninguém tenha dificuldades em entender o que está a ser transmitido (documentos do projecto, actas de reunião, relatório de progresso, etc.). Para tal deve: (1) determinar as necessidades de informação e comunicação dos stakeholders do projecto; (2) disponibilizar a informação necessária e de um modo oportuno; (3) recolher e distribuir a informação sobre o desempenho do projecto, incluindo relatórios de situação, medidas do progresso e previsões; (4) gerir as comunicações para satisfazer as necessidades dos stakeholders e resolver eventuais problemas. Mais ainda, ouvir cuidadosamente os outros e deixando-os falar; reservar tempo para dialogar com a equipa de projectos e não ignorar as partes interessadas no projecto isto é, envolvimento dos utilizadores; Capacidade para planear e Gerir. O planeamento é, na maior parte dos casos, o acto de gestão mais importante para um gestor de projectos depois da comunicação [INA, 2007]. Capacidade de planear. Implica: (1) desenvolver um estudo preliminar, com a equipa de projecto, identificando os problemas de negócio, requisitos, âmbito e benefícios do projecto; (2) identificar os resultados e os marcos do projecto (milestones); (3) desenvolver o plano de projecto e a Estrutura de Decomposição do Trabalho (EDT) 10, comunicar ao cliente e à equipa; (4) determinar as necessidades de recursos, incluindo o envolvimento do cliente; (5) estimar prazos e custos; (6) influenciar a selecção dos membros da equipa; (7) atribuir responsabilidades no projecto com base na avaliação das aptidões e necessidades de desenvolvimento individuais; (8) definir papéis individuais claros e objectivos de desempenho; (9) estabelecer critérios de aceitação (do cliente) para o projecto; (10) determinar os riscos do projecto e a forma de os mitigar; (11) determinar a abordagem tecnológica adequada; 10 Estrutura de decomposição do trabalho (WBS - Work Brakdown Structure) processo de dividir o projecto em tarefas manuseáveis e de ordenar logicamente, como o objectivo de assegurar uma evolução suave entre tarefas. Representação da organização do projecto disposta de modo a relacionar pacotes de trabalho com unidades organizacionais [PMBOK, 2004]. Maria da Conceição Gomes Vilas Boas 15

40 Capacidade de gestão. Implica: (1) avaliar continuamente a situação do projecto; (2) rever o trabalho realizado, com base em critérios definidos para os resultados chave; (3) usar um método sistemático de registo da situação do projecto com verificação face ao planeado; (4) usar procedimentos de controlo dos pedidos de alterações; (5) usar as reuniões de situação do projecto para medir o progresso face ao plano, bem como para comunicar alterações e problemas; (6) avaliar a documentação necessária para as reuniões, trabalho e decisões; (7) medir a qualidade através de testes face aos requisitos; (8) conduzir revisões do projecto e walkthroughs 11 (com o adequado envolvimento do cliente/utilizador); Capacidade para elaborar orçamentos. O gestor de projecto estabelece e administra orçamentos e, por conseguinte, precisa de ter conhecimentos básicos na área de contabilidade e financeira [INA, 2007], para: (1) estimar os custos desenvolver uma aproximação dos custos dos recursos necessários para concluir as actividades do projecto; (2) orçamentar os custos agregar os custos estimados para as actividades, ou pacotes de trabalho individuais, para estabelecer a baseline do custo; (3) controlar os custos influenciar os factores que criam desvios no custo e controlar as alterações ao orçamento do projecto; Capacidade para resolução de problemas. Em todos os projectos ocorrem problemas [INA, 2007]. Em primeiro lugar definir o problema. Posteriormente, o gestor deve identificar, analisar as alternativas e tomar às decisões; Capacidade para negociar e influenciar. Uma resolução de problemas eficaz requer a capacidade de negociar e influenciar [INA, 2007]. A negociação nos projectos é necessária em quase todas as áreas, desde a definição da abrangência do projecto até à negociação de orçamentos, contratos, afectação de recursos e muito mais. Influenciar é a capacidade de convencer as pessoas a assumirem atitudes e comportamentos que, de outra forma, não assumiriam. Influenciar implica também ser capaz de alterar o rumo dos acontecimentos, influenciando os resultados [INA, 2007]; Liderança. Para além de se concentrarem nos resultados e na conclusão dos trabalhos, os gestores de projecto devem procurar aperfeiçoar competências associadas à liderança. Os líderes definem a visão, obtêm consensos para as metas estratégicas, estabelecem directrizes e inspiram e motivam outras pessoas. Embora os termos líder e gestor não tenham o mesmo significado, o gestor de projecto deve ambicionar aperfeiçoar as características inerentes a ambos, em diferentes etapas do projecto [INA, 2007]; Capacidade para criar equipa e gerir recursos humanos. O gestor de projecto depende muito das suas competências para constituir a equipa e gerir os seus elementos. Geralmente, as equipas são formadas por pessoas de diferentes áreas da organização que até já podem ter trabalhado juntas anteriormente. O gestor de projecto é responsável pela motivação dos membros da equipa que não são seus subordinados directos. Esta situação cria um conjunto de desafios para os quais o gestor de projecto deve estar preparado [INA, 2007]. 11 Grupo de pares que se reúne para verificar a correcção e aceitabilidade da interface de utilizador de um produto. As pessoas do grupo incluem analistas, programadores e sujeitos de teste. Como ainda não há código operacional, a interface de utilizador é examinada percorrendo ( walking through ) a documentação. Esta documentação inclui tipicamente as especificações do produto [António Miguel, 2003]. 16 Maria da Conceição Gomes Vilas Boas

41 O que é um Escritório de Gestão de Projectos? Um escritório de projectos (Project Managment Office, abreviatura PMO) é uma estrutura organizacional, centralizada, constituída por profissionais de gestão de projectos que servem as necessidades da organização em termos de gestão de projectos e programas. Um escritório de gestão de projectos também pode ser designado por escritório de gestão de programas ou escritório de programas. Actualmente, os PMOs desempenham algumas das seguintes funções ou mesmo todas [PMBOK, 2004]: Recursos compartilhados e coordenados em todos os projectos geridos pelo PMO; Identificação e desenvolvimento de metodologia, melhores práticas e normas de gestão de projectos; Centralização e gestão das informações para políticas, procedimentos, modelos e outras documentações compartilhadas do projecto; Gestão de configuração centralizada em todos os projectos geridos pelo PMO; Repositório e gestão centralizada para riscos compartilhados e exclusivos para todos os projectos; Escritório central para operação e gestão de ferramentas do projecto, como software de gestão de projectos para toda a organização; Coordenação central de gestão das comunicações entre projectos; Uma plataforma de aconselhamento para gestão de projectos; Monitorização central de todos os prazos e orçamentos do projecto do PMO, geralmente no nível da organização; Coordenação dos padrões de qualidade globais do projecto, entre gestão de projectos, e qualquer pessoal interno ou externo de qualidade ou organização de normalização. As diferenças entre os gestores de projectos e um PMO podem incluir [PMBOK, 2004]: o Os gestores de projectos e PMO buscam objectivos diferentes e, por isso, são orientados por requisitos diferentes. Todos os esforços, no entanto, estão alinhados com as necessidades estratégicas da organização; o Um gestor de projectos é responsável pelo fornecimento de objectivos específicos dos projectos; enquanto o PMO gere as principais mudanças de âmbito do programa e pode encará-las como possíveis oportunidades para melhor alcançar os objectivos de negócio(s); O gestor de projectos controla os recursos atribuídos ao projecto, para atender da melhor forma possível aos objectivos do projecto; enquanto o PMO optimiza o uso dos recursos organizacionais compartilhados entre todos os projectos; O gestor de projecto gere o âmbito, cronograma, o custo e a qualidade dos produtos dos pacotes de trabalho; enquanto o PMO gere o risco global, a oportunidade global e as interdependências entre os projectos; Maria da Conceição Gomes Vilas Boas 17

42 O gestor de projecto informa sobre o progresso do projecto e outras informações específicas do projecto, enquanto o PMO fornece relatórios consolidados e visão empresarial de projecto sob sua supervisão Selecção e Avaliação de Projectos Selecção Estratégica de Projectos Muitos projectos emergiram ou evoluíram de forma isolada ao longo dos anos, em muitas organizações, sem constituírem uma parte integrante de qualquer plano estratégico de SI/TI. Isto conduziu a um conjunto de dificuldades: custos elevados, benefícios mínimos ou não quantificados, incapacidade de resposta a mudanças no mercado ou na tecnologia, restrições à integração de sistemas [António Miguel, 2003, pág. 57]. Para O Connor (1993) empresas com planos estratégicos para os sistemas de informação, bem integrados com a gestão, conseguem sistematicamente melhores resultados do que aquelas que não os têm. Também, Teo e Ang (1999) identificaram como dimensão para o sucesso dos projectos o alinhamento dos projectos com os planos de negócio. Também, para Amaral (1994) o planeamento estratégico de SI/TI traz vantagens competitivas à organização. O planeamento estratégico de SI/TI traz vantagens competitivas à organização [Amaral, 1994]. Embora o planeamento estratégico de SI/TI não seja actividade simples, a maioria dos gestores está de acordo em que o seu desempenho será superior às organizações que não o desenvolvem [Amaral, 1994]. A estratégia é a direcção que uma organização deverá adoptar para se desenvolver, tendo sempre em vista vários níveis de decisão estratégica e sua envolvente externa e interna (para cada nível de decisão), de modo a alcançar a sua visão e missão. Sendo um processo implementado de forma faseada e controlada, que deverá resultar num plano estratégico, num mapa de actividades e recursos adstrito, que leva à existência de um orçamento. Saliente-se ainda que, a estratégia de TI deve estar alinhada com a estratégia de negócio. O conceito define que a gestão deverá [ITIG, 20007]: Gerir o Valor do Negócio. Garantir que o portfolio de investimentos é constituído por programas sólidos para o negócio; Alinhamento do Negócio com a TI. Estabelecer processos bidireccionais, recíprocos, envolvendo o planeamento estratégico, para alcançar os objectivos do negócio e o alinhamento com o planeamento da organização; Avaliação de desempenho e capacidade actual. Avaliar o desempenho e capacidade dos actuais serviços: para estabelecer uma linha a partir da qual futuras exigências possam ser comparadas. Definir o desempenho do negócio em termos da contribuição para os objectivos de negócio, funcionalidade, estabilidade, complexidade, custos, pontos fortes e fracos; Plano Estratégico. Criar um plano estratégico, em cooperação com os principais stakeholders, que defina os objectivos estratégicos, custos e riscos relacionados. O plano estratégico deverá abranger investimentos, orçamento, fontes de financiamento, estratégia de contratação e de aquisição, bem como as exigências legais e reguladoras; 18 Maria da Conceição Gomes Vilas Boas

43 Planos Tácticos. Criar um portfolio de planos tácticos que são obtidos a partir do plano estratégico. Os planos tácticos devem abordar o programa de investimentos, de serviços a prestar e activos. Os planos tácticos deverão descrever as iniciativas e requisitos, recursos necessários, os recursos que são utilizados, como os benefícios são controlados e geridos. Os planos tácticos devem ser suficientemente pormenorizados para permitir a definição de planos de projectos. Gerir de forma activa o conjunto de planos tácticos de TI, através da análise do portfolio de projectos e serviços. A selecção dos projectos de SI/TI a implementar devem resultar do plano estratégico de SI/TI, obtendo assim vantagem competitiva para a organização. Todos os projectos devem ser apoio para os objectivos estratégicos das organizações o plano estratégico da organização a executar deve ser considerado como um factor das decisões do projecto [PMBOK, 2000] Avaliação Financeira e Técnica do Projecto A justificação do projecto é obtida pela realização de um estudo de exequibilidade 12, que consta de duas análises: a viabilidade financeira e a viabilidade técnica (risco). [António Miguel, 2003]. O objectivo da avaliação técnica do projecto análise do risco é obter uma compreensão da capacidade da organização em construir o sistema proposto Metodologia de Gestão de Projectos PMBOK Guide 2004 O PMBOK Guide 2004 (Project Management Body of Knowledge) é o resultado do esforço do PMI em registar e documentar uma base de conhecimentos para a actividade de Gestão de Projectos. O PMI é a maior e mais respeitada associação de gestores de projectos a nível mundial que publicou em 1986 a 1ª versão do PMBOK Guide, que tem sido permanentemente actualizada (em 1996, 2000 e 2004). A Guide to the Project Management Body of Knowledge já vai na sua 3ª edição (publicada em Dezembro de 2004). Os processos, metodologias, práticas, nele preconizadas, são já considerados padrões e normas da profissão de gestão de projectos a nível mundial. O corpo de conhecimento da gestão de projectos constitui pela globalidade do conhecimento dentro da profissão, inclui práticas tradicionais provadas que são amplamente aplicadas, bem como práticas inovadoras emergentes na profissão, e está em permanente evolução. O objectivo do PMBOK Guide é a identificação do subconjunto do corpo de conhecimentos da gestão de projectos que é geralmente conhecidos como boas práticas. O conceito de boa prática significa a existência de um acordo generalizado para a aplicação das aptidões, ferramentas e técnicas em questão. Estas boas práticas levam a aumentar a possibilidade de sucesso de um grande número de diferentes projectos. Boa prática não significa que o conhecimento descrito deva ser sempre aplicado, de modo uniforme, para todos os projectos 12 Estudo de exequibilidade (Feasibility Study) análise, orientada-para-o-utilizador, do objectivo e da viabilidade financeira e técnica de um projecto, proposta [António Miguel, 2006]. Maria da Conceição Gomes Vilas Boas 19

44 a equipa de gestão do projecto é responsável pela determinação daquilo que é adequado para o seu projecto. Cada organização ou equipa de projecto deve decidir quais das actividades, metodologias, ferramentas e técnicas expressas no PMBOK Guide devem ser aplicadas, para o sucesso do projecto [PMBOK, 2004] Ciclo de Vida da Gestão de Projectos Uma vez que um projecto tem um início e um fim (PMBOK, 2000) podemos associar-lhe um ciclo de vida, normalmente, designado por PCL Project Life Cycle. O ciclo de vida do projecto consiste num conjunto sequencial [Stuckenbruck, 1981] de fases que visam melhorar o controlo do projecto a partir das necessidades da organização ou das organizações envolvidas e assim, a sua gestão [PMBOK, 2000]. A divisão das fases de um projecto varia de indústria para indústria e de projecto para projecto [Stuckenbruck, 1981], ou seja não existe uma única maneira para definir um ciclo de vida ideal do projecto. [PMBOK, 2004]. Porém, durante a vida de um projecto há várias fases de desenvolvimento que são idênticas à maior parte dos projectos. Uma compreensão destas fases ajuda os gestores a melhor controlar os recursos, os tempos e as performances, para alcançar mais eficientemente os objectivos pretendidos. Uma fase de um projecto é caracterizada pela conclusão e aprovação de uma ou mais deliverables (entregas 13 ). As fases são parte de um processo geralmente sequencial, desenhado de modo a assegurar o controlo adequado do projecto, para garantir a obtenção do produto ou serviço desejado, que constitui o objectivo do projecto. Por motivos de dimensão, complexidade, nível de risco e restrições de cash flow, num projecto específico as fases podem ser decompostas em subfases, em que cada uma está alinhada com um ou mais deliverables específicos, por motivos de monitorização e controlo. O final de uma fase do projecto é marcado, regra geral, por uma revisão técnica ou desenho do trabalho concluído e dos deliverables, para decidir a respectiva aceitação, a eventual necessidade de trabalho extra, ou o encerramento da fase. Cada programa, projecto ou produto possui fases de desenvolvimento conhecidas como fases do ciclo de vida. Uma clara compreensão destas fases permitirá aos gestores executivos controlar os recursos, de um modo mais eficaz, e alcançar os objectivos de uma forma mais segura. Os projectos e a gestão de projectos são realizados num ambiente mais amplo e abrangente que os próprios projectos em si. O chefe de projecto e a sua equipa devem possuir uma boa compreensão deste ambiente mais abrangente, de modo a poderem seleccionar as fases, processos, ferramentas e técnicas do ciclo de vida adequada a cada projecto. Mais ainda, o desenvolvimento de um sistema de informação requer normalmente um entendimento relativo ao modelo de gestão e ao modelo de processo [Cunha, J.; 2007], ou seja todos os projectos de engenharia (incluindo os projectos de desenvolvimento de software/sistemas de informação) têm de lidar basicamente com duas vertentes: uma técnica e outra de gestão. Os sistemas de informação tem requisitos próprios no referente à forma de organizar, planear e controlar os projectos [Cunha J., 2007], ou seja apresentam uma filosofia de desenvolvimento de software diferente. O modelo particular de processo varia com o tipo de 13 Deliverable (entrega) é um produto resultante do trabalho do projecto. 20 Maria da Conceição Gomes Vilas Boas

45 sistema de informação a desenvolver [Cunha, J.; 2007]. O ciclo de vida do projecto varia conforme o modelo de desenvolvimento seleccionado (como por exemplo: modelo de desenvolvimento em cascata; modelo de desenvolvimento incrementar; modelo de prototipagem espiral; modelo ágeis; modelo RUP, entre outros). Um projecto de software apresenta duas dimensões fundamentais: engenharia de software e gestão de projectos. A dimensão da engenharia trata da construção do sistema de software e centra-se nas questões técnicas como o desenhar, codificar, testar, etc. A dimensão da gestão do projecto trata do modo de planear e controlar adequadamente as actividades de engenharia, para cumprir os objectivos do projecto em termos de custo, prazo e qualidade. Um processo de software (ou metodologia de desenvolvimento de software) é um conjunto de actividades (isto é, uma sequência de passos que deverão ser seguidos para executar uma tarefa) com a finalidade de obter um produto de software. Dentre as várias actividades associadas existem, por exemplo, a análise de requisitos e a codificação. O resultado do processo é um produto que reflecte a forma como o processo foi conduzido Processo da Gestão de Projectos Segundo o PMI a gestão de cada projecto passa por 5 grupos de processos 14 distintos: a iniciação, o planeamento, a execução, o controlo e o encerramento conforme se pode verificar na figura 3. Figura 3 Ciclo de Vida dos Projectos e Processos da Gestão de Projectos. Fonte: Autor. Quando um projecto está dividido em fases os grupos de processos são normalmente repetidos dentro de cada fase, ao longo da vida do projecto, de modo a conduzir, de forma eficaz, o projecto à sua conclusão. A aplicação dos processos de gestão de projectos é interactiva, muito dos processos são 14 Isto é, processo é um conjunto de actividades que se complementam e se interligam, em termos de uma sequência lógica, para a concretização de um objectivo. Maria da Conceição Gomes Vilas Boas 21

46 repetitivos e revistos durante o projecto. O chefe de projecto e a sua equipa são responsáveis por determinar quais os processos a empregar, por quem e qual o grau de rigor a aplicar a esses processos, para atingir o objectivo para o projecto. Quando um projecto está dividido em fases os grupos de processos são, normalmente, os seguintes: Processos de Iniciação É na fase de iniciação (definição) do projecto que a ideia do projecto é delineada. Numa empresa a ideia pode surgir pela identificação de uma necessidade interna ou por um pedido de um cliente. Essa ideia é normalmente vaga. O primeiro tipo de objectivo, apesar de ser vago, deixa mais possibilidades de solução o que pode ser vantajoso. Nesta fase não existe uma definição clara do que se pretende fazer. Daí a necessidade de proceder a uma análise de viabilidade do projecto, conjuntamente com uma análise económica e uma análise de risco. Em algumas organizações um projecto é formalmente iniciado somente depois da conclusão de um estudo de viabilidade, de um plano preliminar ou de qualquer outra forma equivalente de análise que foi iniciada separadamente [PMBOK, 2000, pág. 49]. O ciclo de vida do projecto determina se o estudo de viabilidade constituirá a primeira fase do projecto ou se deve ser tratada como um projecto à parte [PMBOK, 2000]. O resultado desta análise irá permitir decidir sobre a implementação do projecto. (...) reconhecer que um projecto ou fase deve começar e se comprometer para executá-lo(s) [PMBOK, 2000, pág. 28]. Obter o comprometimento da organização para o início da próxima fase do projecto [PMBOK, 2000, pág. 28]. É nesta fase que os objectivos devem ser mais detalhados, especificando claramente os requisitos, bem como a abordagem global que irá ser usada para alcançar os objectivos. É também nesta fase que se define a organização das pessoas envolvidas no projecto - com a necessária nomeação de um gestor do projecto Processos de Planeamento Os grupos de processos de planeamento tem como objectivo permitir à equipa de gestão do projecto planear e gerir, de forma correcta e com sucesso, o projecto para a organização. No processo de planeamento são desenvolvidos planos detalhados, com identificação das tarefas necessárias e respectivas durações. É também definido o custo e os recursos necessários para levar a cabo cada tarefa ou actividade. Para além das características de cada actividade são também estabelecidas as relações de precedência entre as actividades. Com todas estas informações é então possível construir um plano de execução do projecto (project schedule). O que nem sempre é tarefa fácil devido às inúmeras restrições de precedências, recursos e custos, que por vezes existem. São também estabelecidas metas ou marcos que irão servir para controlar a execução do projecto. O planeamento é de fundamental importância num projecto: executar um projecto implica realizar algo que não tinha sido feito antes. Por ser possível que um projecto seja único, como tal nunca ter sido executado anteriormente, o planeamento deve abranger todas as actividades a realizar: considerar os orçamentos necessários à sua execução; a definição das tarefas; o planeamento da abrangência; o desenvolvimento do cronograma; a identificação dos riscos; o recrutamento da equipa; o planeamento de aquisições, etc. 22 Maria da Conceição Gomes Vilas Boas

47 À medida que se descobrem novas informações ou características sobre o projecto deverão ser identificadas ou resolvidas dependências, requisitos, riscos, oportunidades, pressupostos e restrições adicionais. A natureza multidimensional da gestão de projecto provoca ocorrência de repetidos ciclos de informação de retorno para análise adicional. Alterações significativas ocorridas ao longo do ciclo de vida do projecto desencadearão a necessidade de rever, um ou mais, processos de planeamento e, eventualmente, alguns dos processos de iniciação do projecto Processos de Execução A execução consiste, basicamente, em fazer o trabalho e comunicar resultados. A execução do trabalho deve seguir o plano estabelecido, sendo necessário garantir isso mesmo, através de uma monitorização constante que esteja atenta às metas predefinidas, aos custos, aos recursos humanos, bem como à qualidade do produto que vai sendo obtido. Ou seja, este grupo de processos envolve a coordenação de pessoas, recursos, a integração e a execução das actividades do projecto em conformidade com o respectivo plano. Trata igualmente do âmbito definido no documento de Descrição do Âmbito do Projecto e implementa as relações com os outros grupos de processos. Os desvios normais nas durações das actividades, na produtividade, disponibilidade dos recursos e em riscos não previstos, surgidos durante a execução, implicam a aprovação de replaneamento. Esses desvios poderão afectar, ou não, o plano de gestão do projecto, mas exigindo sempre uma análise. Os resultados dessas análises poderão desencadear um pedido de alteração que, se for aprovado, modificará o plano de gestão do projecto e exigirá eventualmente o estabelecimento de um novo plano base (baseline do projecto). Se o desvio for muito grande as consequências podem ser um atraso na conclusão do projecto e um aumento do custo global. Nos casos mais graves pode ser necessário abortar a execução do projecto. O que não é de todo desejável pois já terão sido comprometidos muitos recursos humanos e materiais Processos de Monitorização e Controlo Este grupo de processos integra todos os processos realizados com o objectivo de observar a execução do projecto. Assim os potenciais problemas podem ser oportunamente identificados e as necessárias acções correctivas podem ser realizadas: se for necessário e quando necessário. Os benefícios chave deste grupo de processos é o desempenho do projecto, que é observado e medido de forma regular, para detectar desvios face ao plano de gestão do projecto. Este grupo de processos inclui igualmente o controlo das alterações e a recomendação de acções preventivas em antecipação a possíveis problemas. Esta monitorização contínua proporciona à equipa de projecto informação sobre a saúde do projecto e põe em evidência quaisquer áreas que necessitem de atenção adicional. A execução deste grupo de processos inclui a monitorização e o controlo não apenas do trabalho a ser realizado, dentro de um grupo de processos, mas também do trabalho do projecto inteiro. Nos projecto com múltiplas fases o grupo de processos de monitorização e controlo proporciona igualmente informação de retorno, entre as fases do projecto, a fim de permitir a implementação de acções preventivas ou correctivas que permitam trazer o projecto de volta aos parâmetros definidos no seu plano. Quando os desvios põem em causa os objectivos do Maria da Conceição Gomes Vilas Boas 23

48 projecto, deve-se rever os processos adequados, dentro do grupo de processos de planeamento e efectuar eventuais actualizações ao plano do projecto. Na fase de controlo realizam-se e analisam-se as avaliações de desempenho para se identificar se o projecto está a decorrer de acordo com o planeado. Se forem detectados desvios serão aplicadas as acções correctivas para se ajustarem as actividades ao plano do projecto. É possível que este procedimento exija a revisão do processo de planeamento para reajustar os objectivos definidos Processos de Encerramento Este grupo de processos integra os processos usados para concluir formalmente todas as actividades de um projecto ou de uma fase do projecto: entregar o produto/serviço concluído a terceiros ou encerrar um projecto cancelado. Ou seja, uma vez alcançados os objectivos do projecto i.e. entra-se no encerramento, deve ser feita a aceitação do produto do projecto pelo cliente (interno e/ou externo) e avaliado o percurso do projecto. A informação mais importante a reter será a duração real do projecto, o custo das actividades, a utilização dos recursos e também o grau de satisfação do cliente perante o resultado final. Esta informação deve ser armazenada para servir de futura referência a outros projectos. Finalmente o projecto tem que ser desmantelado, repondo o equipamento e as instalações num estado apropriado à próxima utilização, e redistribuído o pessoal conforme necessário. Depois de obtido o produto final do projecto este não se pode simplesmente dar por concluído. Algum tempo depois deve ser feito uma revisão cuidada do projecto. Numa primeira fase deve ser avaliado os objectivos que foram cumpridos. Daí a necessidade, como já foi referido anteriormente, de uma definição cuidadosa dos objectivos do projecto. Cabe salientar que, toda a aprendizagem que um projecto proporciona a uma organização deve servir de base ao seu processo de melhoria contínua. Uma organização poderá (e terá todo o interesse em fazê-lo) avaliar um projecto de SI/TI após a fase de conclusão: a melhoria de desempenho de uma organização na execução de projectos consiste na sua capacidade de aprendizagem (conceito da Learming Organization de Peter Senge em The Fifth Discipline) Áreas de Conhecimento da Gestão de Projecto O PMBOK Guide 2004 organiza os processos de gestão de projectos, que integram os 5 grupos de processos anteriormente referidos no ponto 2.3.3, em 9 áreas de conhecimento definidas na figura 4. Gestão de Âmbito Gestão da Qualidade Gestão da Comunicação Gestão do Custo Gestão da Integração Gestão do Risco Gestão de Prazo Gestão dos Recursos Humanos Gestão das Aquisições Figura 4 Áreas de Conhecimento da Gestão de Projectos. Fonte: Autor. 24 Maria da Conceição Gomes Vilas Boas

49 A gestão de todos os processos de trabalho e actividades a executar num projecto devem sustentar-se em áreas de conhecimento, que o gestor e a equipa de projecto devem dominar, para que o projecto se concretize com sucesso. As 9 áreas de conhecimento são descritas nos pontos seguintes Gestão da Integração Esta área do conhecimento descreve os processos e as actividades que suportam os vários elementos da gestão de projectos, os quais são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos. Os processos de gestão integrada de projectos incluem: Desenvolver o termo de abertura do projecto documento que autoriza formalmente a abertura do projecto ou uma fase do projecto; Desenvolver a descrição preliminar do âmbito desenvolvimento da declaração do âmbito preliminar do projecto que fornece uma descrição de alto nível do âmbito; Desenvolver o plano de gestão de projectos documentação das acções necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares num plano de gestão do projecto; Orientar a gestão e execução do projecto execução do trabalho definido no plano de gestão do projecto para atingir os requisitos do projecto definidos na declaração do âmbito do projecto; Monitorizar e controlar o trabalho do projecto monitorização e controlo dos processos necessários para iniciar, planear, executar e encerrar um projecto para atender aos objectivos de desempenho definidos no plano de gestão do projecto; Controlo Integrado de mudanças revisão de todas as solicitações de mudança, aprovação de mudanças e controlo de mudança, nas entregas e nos activos de processos organizacionais; Encerramento do projecto finalização de todas as actividades, entre todos os grupos do projecto, para encerrar formalmente o projecto Gestão do Âmbito Esta área de conhecimento descreve os processos destinados a garantir que o projecto inclui todo o trabalho requerido, e somente o trabalho requerido, para garantir o sucesso do projecto. Os processos de gestão de âmbito do projecto incluem: Planeamento do âmbito criação de um plano de gestão do projecto que documenta como o âmbito do projecto será definido, verificado e controlado e como a estrutura decomposição do trabalho (EDT) será criada e definida; Definição do âmbito desenvolvimento de uma declaração do âmbito detalhada do projecto como a base para futuras decisões do projecto; Criação do EDT subdivisão das principais entregas do trabalho do projecto em componentes menores e mais facilmente estimáveis; Maria da Conceição Gomes Vilas Boas 25

50 Verificação do âmbito formalização da aceitação das entregas do projecto terminadas; Controlo do âmbito controlo das mudanças do âmbito do projecto Gestão do Prazo Esta área de conhecimento descreve os processos destinados a garantir que o projecto é concluído nos prazos acordados. Os projectos de gestão do prazo incluem: Definição das actividades identificação das actividades específicas do cronograma que precisam ser realizadas para produzir as várias entregas do projecto; Sequenciamento de actividades identificação e documentação das dependências entre as actividades do cronograma; Estimativas de recurso da actividade estimativa do tipo e das quantidades de recursos necessários para realizar cada actividade do cronograma; Estimativa de duração da actividade estimativa do número de períodos de trabalho que serão necessários para terminar as actividades individuais do cronograma; Desenvolvimento do cronograma análise dos recursos necessários, restrições do cronograma, durações e sequências de actividades para criar o cronograma do projecto; Controlo do cronograma controlo das mudanças no cronograma do projecto Gestão do Custos Esta área descreve os processos necessários para assegurar que o projecto é concluído dentro do orçamento aprovado. Consiste: Estimativa de custos desenvolvimento de uma aproximação dos custos dos recursos necessários para terminar as actividades do projecto; Orçamentação agregação dos custos estimados de actividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos; Controlo dos custos controlo dos factores que criam as variações de custos e controlo das mudanças no orçamento do projecto Gestão da Qualidade Esta área de conhecimento descreve os processos destinados a garantir que o projecto satisfará as necessidades para que foi destinado. Consiste: Planeamento da qualidade identificação dos padrões de qualidade relevantes para o projecto e determinação de como satisfazê-los; Realizar a garantia da qualidade aplicação das actividades de qualidade planeadas para garantir que o projecto emprega todos os processos necessários para atender aos requisitos; 26 Maria da Conceição Gomes Vilas Boas

51 Realizar o controlo da qualidade monitorização dos resultados específicos do projecto, a fim de determinar se estão de acordo com os padrões relevantes de qualidade, e identificação de maneiras de eliminar as causas de um desempenho insatisfatório Gestão dos Recursos Humanos Esta área de conhecimento descreve os processos destinados a fazer um uso mais eficaz das pessoas envolvidas no projecto. Consiste: Planeamento de recursos humanos identificação e documentação de funções, responsabilidades e relações hierárquicas do projecto, além da criação do plano de gestão de pessoal; Contratar ou mobilizar a equipa do projecto obtenção dos recursos humanos necessários para terminar o projecto; Desenvolver a equipa do projecto melhoria de competências e interacção de membros da equipa para aprimorar o desempenho do projecto; Gestão da equipa de projecto acompanhamento do desempenho de membros da equipa, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projecto Gestão da Comunicação Esta área de conhecimento descreve os processos necessários para garantir a adequada (e oportuna) geração, recolha, disseminação, armazenamento e disponibilização da informação relativa ao projecto. Consiste: Planeamento das comunicações determinação das necessidades de informação e comunicações das partes interessadas no projecto; Distribuição das informações colocação das informações necessárias à disposição das partes interessadas no projecto no momento oportuno; Relatório de desempenho colecta e distribuição das informações sobre o desempenho, inclusive relatório de andamento, medição do progresso e previsão; Gestão das partes interessadas gestão das comunicações para satisfazer os requisitos das partes interessadas no projecto e resolver problemas Gestão do Risco Esta área de conhecimento descreve os processos respeitantes à identificação, análise e resposta aos riscos do projecto. Consiste: Planeamento da gestão do risco - decisão de como abordar, planear e executar as actividades de gestão do risco de um projecto; Identificação de risco determinação dos riscos que podem afectar o projecto e documentação das suas características; Maria da Conceição Gomes Vilas Boas 27

52 Análise qualitativa de riscos priorização dos riscos para análise ou acção adicional subsequente através de avaliação, combinação da sua probabilidade de ocorrência e impacto; Análise quantitativa de riscos análise numérica do efeito dos riscos identificados nos objectos gerais do projecto; Planeamento de respostas ao risco desenvolvimento de opções (e acções) para aumentar as oportunidades e reduzir as ameaças aos objectivos do projecto; Monitorização e controlo de riscos acompanhamento dos riscos identificados, monitorizar os riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação da sua eficácia durante todo o ciclo de vida do projecto Gestão das Aquisições Esta área de conhecimento descreve os processos destinados à compra ou aquisição de material, produtos, bens e serviços, bem como os processos de gestão de contratos. Consiste: Planeamento de compras e aquisições determinação do que comprar ou adquirir, de quando e como fazer isso; Planeamento de contratações documentação dos requisitos de produtos, serviços e resultados, e identificação de possíveis fornecedores; Solicitar respostas de fornecedores obtenção de informações, cotações, preços, ofertas ou propostas, conforme adequado; Gestão do contrato gestão do contrato e da relação entre o comprador e o fornecedor, análise e documentação do desempenho actual ou passado de um fornecedor, a fim de estabelecer acções correctivas necessárias e fornecer uma base para futuras relações com o fornecedor, gestão de mudanças relacionadas ao contrato e, quando adequado, gestão da relação contratual com o comprador externo do projecto. 28 Maria da Conceição Gomes Vilas Boas

53 2.4. Mapeamento do Processo de Gestão de Projectos A tabela 3 mostra o mapeamento dos 44 processos de gestão de projectos, nos 5 grupos de processos de gestão de projectos e nas 9 áreas de conhecimento da gestão de projectos, conforme definido no PMBOK Guide Áreas de Conhecimentos Gestão da Integração Gestão do Âmbito Gestão do Prazo Gestão do Custo Gestão da Qualidade Gestão do Recursos Humanos Gestão da Comunicação Gestão do Risco Gestão das aquisições Iniciação Planeamento Execução - Criar o Termo de Abertura - Desenvolver a descrição do âmbito - Desenvolver o plano de gestão do projecto - Planear e definir o âmbito do projecto - Criar a EDT - Definir e sequenciar as actividades - Estimar os recursos - Estimar a duração das actividades - Desenvolver o cronograma do projecto - Estimar e orçamentar o custo do projecto - Planear a qualidade - Planear os recursos humanos - Planear as comunicações - Planear a gestão do risco - Identificar os riscos - Efectuar a análise qualitativa e quantitativa dos riscos do projecto - Planear a resposta aos riscos - Planear as compras - Planear a contratações - Dirigir e gerir a execução do projecto - Executar a garantia da qualidade - Recrutar a equipa de projecto - Desenvolver a equipa de projecto - Distribuir a informação - Pedir proposta seleccionar fornecedores e Monitorização e controlo - Monitorizar e controlar o trabalho do projecto - Verificar e controlar o âmbito do projecto - Controlar o cronograma do projecto - Controlar o custo do projecto - Realizar o controlo da qualidade - Gerir a equipa de projecto - Relatar o desempenho do projecto - Gerir os stakeholders - Monitorizar e controlar os riscos do projecto - Administrar os contratos Tabela 3 Mapeamento das Áreas de Conhecimento, Processos e Grupos de Processos. Fonte: Adaptação do PMBoK, Encerramento - Encerrar o projecto - Encerrar os contratos Maria da Conceição Gomes Vilas Boas 29

54 2.5. Síntese A gestão de projectos é a aplicação de conhecimento, capacidades, ferramentas e técnicas para que as actividades dos projectos consigam alcançar os seus requisitos, através da utilização de processos de iniciação, planeamento, execução, controlo e conclusão inerentes a cada fase do projecto [PMBOK, 2004] conforme explicitado no ponto e O alinhamento dos projectos com a estratégia de SI/TI da organização contribui para melhorar o seu sucesso [PMBOK, 2004; António Miguel, 2003; O Connor, 1993; Teo e Ang, 1999; Amaral, 1994]. Assim a excelência na gestão de projectos só pode ser alcançada com um planeamento estratégico da SI/TI, conforme é explicitado a seguir. Os projectos são utilizados como meio de atingir o plano estratégico de uma organização, seja a equipa do projecto formada por funcionários da organização ou prestadores de serviços contratados [PMBOK, 2004]. Porém, em muitas organizações, muitos projectos emergiram ou evoluíram de forma isolada ao longo dos anos sem constituírem uma parte integrante de qualquer plano estratégico de SI/TI. Isto conduziu a um conjunto de dificuldades: custos elevados, benefícios mínimos ou não quantificados, incapacidade de resposta a mudanças no mercado ou na tecnologia, restrições à integração de sistemas [António Miguel, 2003, pág. 57]. Para O Connor (1993) empresas com planos estratégicos para os sistemas de informação, bem integrados com a gestão, conseguem sistematicamente melhores resultados do que aquelas que não os têm. Teo e Ang (1999) identificaram como dimensão para o sucesso dos projectos o alinhamento dos projectos com os planos de negócio. Também, para Amaral (1994) o planeamento estratégico de SI/TI traz vantagens competitivas à organização. De acordo com o PMI o sucesso de um projecto depende em grande parte: Da qualidade do plano inicial de trabalho O desenvolvimento deste plano requer um processo estruturado, de natureza interactiva, o qual começa com uma perspectiva top-down do problema e mais tarde valida a solução através duma perspectiva bottow-up. Uma implementação bem-sucedida deste processo requer a consideração cuidada de vários aspectos específicos, tanto na perspectiva da organização e como do projecto (e.g. cultura organizacional, disponibilidade de dados). Técnicas de Estimação de Tempos, Custos e Recursos Um dos problemas mais críticos no planeamento de um projecto consiste na produção de estimativas fiáveis para os prazos, custos e recursos necessários, antes de um plano detalhado ter sido desenvolvido ou estar disponível. A técnica mais utilizada para este fim (e com maior validade cientifica) consiste nos modelos paramétricos de estimação, que requerem a recolha e análise estatística de dados no seio da organização. As organizações que praticam esta técnica tendem a produzir estimativas cada vez mais fiáveis, ao longo de vários projectos, aumentando desta forma a probabilidade de sucesso em projectos futuros. Planeamento e Gestão do Risco do Projecto A gestão do risco num projecto constitui uma prática essencial a uma gestão proactiva, capaz de antecipar e resolver problemas sérios, antes de estes se manifestarem. Num ambiente incerto e de crescente mudança a gestão de risco tem vindo a assumir um papel cada vez mais importante na gestão de projectos de SI. Existe todo um conjunto de 30 Maria da Conceição Gomes Vilas Boas

55 técnicas e processos bem definidos para o planeamento e execução da actividade de risco. Contudo, estas técnicas e processos necessitam de ser bem ajustadas às especificações da organização. Planeamento da Gestão do Custo do Projecto O custo constitui um dos objectivos operacionais do projecto mais importantes para o sucesso estratégico do projecto. A decisão de se implementar um projecto passa quase sempre por uma fase de avaliação económica, na qual é definida uma expectativa de custo, a qual, de algum modo, justifica a decisão de implementação. É, por isso, fundamental que no decorrer do projecto o custo incorrido seja monitorizado com o máximo de rigor e comparado com esta expectativa. Para além dos benefícios directos que traz ao projecto, um controlo rigoroso do custo, permite à organização saber quanto custam efectivamente os seus projectos, podendo desta forma: estimar como gerir o orçamento dos projectos futuros; diagnosticar as causas de desvios orçamentais; prioritizar a afectação de recursos aos seus projectos, e, em última análise, alinhar melhor as suas decisões quanto à selecção e implementação dos projectos com os objectivos estratégicos do negócio. Infelizmente, poucas organizações controlam correctamente os custos dos seus projectos. A principal razão tem a ver com o facto desta importante função estar quase sempre sob a responsabilidade da contabilidade tradicional, a qual não é orientada aos projectos mas às actividades funcionais e de produção. O controlo do custo de um projecto exige um sistema de planeamento e controlo contabilístico orientado à sua estrutura. O mercado carece de metodologias e ferramentas apropriadas a este fim. Avaliação e Controlo de Progressos Um bom plano inicial constitui um factor crítico de sucesso para o projecto. Contudo, não menos importante, a monitorização e o replaneamento do projecto asseguram que o mesmo é capaz de se adaptar aos desvios que sempre ocorrem, bem como a novas condições estratégicas do negócio. Ou seja, a gestão de projecto é um factor crítico de sucesso dos projectos de sistemas e tecnologias de informação. Maria da Conceição Gomes Vilas Boas 31

56 32 Maria da Conceição Gomes Vilas Boas

57 3. Avaliação de Projectos de SI/TI Project success is a topic that is frequently discussed and yet rarely agreed upon. The concept of project success has remained ambiguously defined. It is a concept which can mean so much to so many different people because of varying perceptions, and leads to disagreements about whether a Project is successful or not (Liu & walker, 1998, citado por David Baccarine, 1999). Neste capítulo é apresentada uma revisão da literatura de vários estudos empíricos (survey e caso de estudo) e estudos teóricos sobre os critérios que permitem avaliar o sucesso (insucesso) dos projectos e os factores críticos que contribuem para o sucesso (insucesso) dos projectos. A revisão da literatura sobre gestão de projecto não fornece uma interpretação consistente sobre o termo de projecto de sucesso. Observa que não existe uma definição padronizada de projecto de sucesso nem uma metodologia aceite para medição. Wateridge (1998) observa que muito poucas pessoas no passado tinham pensado seriamente sobre os critérios de sucesso Conceitos Sistema e Tecnologia de Informação Como ponto essencial à problemática em causa é importante podermos definir o que se entende por Sistema e Tecnologia de Informação, isto apesar de serem termos banalizados na linguagem comum. Assim, verifica-se que é conceito sem entendimento universal por isso, pertinente apresentar aqui as definições utilizadas ao longo deste trabalho. Sistema de Informação. É uma combinação de procedimentos, informação, pessoas e Tecnologia de Informação, organizadas para o alcance de objectivos de uma organização (Alter, 1992, citada por Amaral, 1994). Tecnologia de Informação. Consiste (Ward (1990), citado por Amaral (1994): Hardware Sistemas de computação, computadores pessoais, estações de trabalho, impressoras, digitalizadores, discos, etc. ; Software de sistema Sistemas operativos, monitores de teleprocessamento, sistemas Maria da Conceição Gomes Vilas Boas 33

58 de gestão de bases de dados, compiladores e interpretadores de linguagens de programação, etc. ; Comunicações Hardware, software e serviços de comunicações ; Ferramentas de desenvolvimento Geradores de aplicações, linguagens de 4ª geração, ferramentas CASE (Computer Aided Software/Systems Engineering), ferramentas de prototipagem, etc. ; Software de aplicação Sistemas periciais, sistemas baseados em conhecimento, automação do escritório, processamento de texto, correio electrónico, CAD-CAM (Computer Aided Design - Computer Aided Manufacturing), Sistemas de Informação de Gestão, Sistemas de Informação Executivos, Sistemas de Apoio à Decisão, Aplicações genéricas (Folhas de cálculo, etc.), aplicações específicas (salários, contabilidade, etc.), etc Critério e Factor de Sucesso Critério de Sucesso. É a medida que permite avaliar o sucesso ou insucesso do projecto [Cooke-Davis, 2002] e o conjunto de princípios ou normas pelos quais o sucesso do projecto é ou pode ser julgada [Lim e Mohamed, 1999]. Factor de Sucesso. É um input no sistema de gestão que directa ou indirectamente gera o sucesso ou o insucesso do Projecto [Cooke-Davis, 2002]. São um conjunto de circunstâncias, factos, ou nuances que contribuem para os resultados dos projectos [Lim e Mohamed, 1999] Avaliação de Projectos Critérios e Factores de Sucesso Desde 1960 que a definição de sucesso e insucesso dos projectos tem sido objecto de muitos estudos. A definição de insucesso e de sucesso do projecto é muito nebulosa [Pinto, Jeffery k. e Manterl, Samuel J., 1990] existindo uma variedade de definições [Agarwal et al., 2006]. Wateridge (1995) narra que não existe um grande consenso entre os stakeholders de projecto de SI/TI sobre o conceito de sucesso de projecto. Para Lim e Mohamed (1999) o sucesso de um projecto deve ser visto de diferentes perspectivas conforme os stakeholders (dono, fabricante, utilizador, público em geral, e assim por diante). Estas diferentes perspectivas irão explicar a razão pela qual o mesmo projecto pode ser considerado um sucesso por uns stakeholders e por outros stakeholders de insucesso. Para os envolvidos no projecto, um projecto sucesso é normalmente pensado como a realização de alguns dos objectivos predeterminados, que comummente inclui vários parâmetros como tempo, custo, desempenho, qualidade e segurança. Freeman e Beale (citado por Shenhar et al., 2001) considera que: Success means different things to different people. An architect may consider success in terms of aesthetic appearance, an engineer in terms of technical competence, an accountant in terms of dollars spent under budget, a human resources manager in terms of employee satisfaction. Chief executive officers rate their success in the stock market. Também, o Project Manager Competency Development (PMCD) Framework considera que a percepção de sucesso do projecto pode variar, dependendo das perspectivas dos diferentes stakeholders do projecto. Mais concretamente, os stakeholders do projecto (como por exemplo o 34 Maria da Conceição Gomes Vilas Boas

59 gestor de projecto, patrocinadores, clientes e utilizadores, equipa de projecto) vêem o sucesso do projecto de diferente maneira. Por isso, o sucesso do projecto torna-se matéria que usa filtro de diferentes stakeholders. Mais ainda, Baker, Murphy e Fisher (1983) e Wateridge (1995) perceberam que os factores que afectam a percepção de sucesso não são (exactamente) os mesmos que afectam a percepção de insucesso Critérios de Sucesso Há mais de uma maneira de avaliar o sucesso do projecto e se a mesma regra é aplicável a todos os projectos? Visão tradicional de sucesso de projecto Tradicionalmente, o grau de sucesso de um projecto seria medido através do grau em que os objectivos iniciais de custo, prazo e especificações são atingidos (ou seja, qualidade e especificações funcionais), os gestores do projecto tem de se preocupar satisfazer estes três critérios para alcançar o sucesso ver figura 5. Figura 5 Sucesso do Projecto Visão Tradicional. Fonte: adaptada de Westhuizen et al. Estas três dimensões indicam o grau de eficiência da gestão do projecto é designado por Atkison (1999), citado por Chan et al. (2004), como iron triangule. Evolução do conceito de sucesso e critérios de avaliação Contudo, vários estudos teóricos e empíricos survey e casos de estudo - têm demonstrado que o conceito de sucesso não se encontra estritamente ligado ao cumprimento do prazo, custo e qualidade. Embora isso possa parecer verdadeiro, em alguns casos, - existem muitos exemplos em que esta abordagem simplesmente não é suficiente. Muitas vezes, aquilo que parecia ser um agitado projecto, com extensos atrasos e derrapagens, saiu mais tarde para ser um grande sucesso empresarial [Yeo, 2002] Powers e Diskson (1973), citado por Wateridge (1998), consideram um projecto de sucesso desde que garanta o tempo, custos, satisfação dos utilizadores (isto é, ir de encontro às necessidades) e o impacto nas operações dos utilizadores Backer, Murphy e Fisher (1983), citado por Agarwal et al. (2006), definem o sucesso do projecto: Maria da Conceição Gomes Vilas Boas 35

60 The project is considered an overall success if the project meets the technical performance specification and/or mission to be performed, and if there is a high level of satisfaction concerning the project outcome among key people in the parent organization, key people in the project team and key users or clientele of the project effort. Ou seja, Backer, Murphy e Fisher (1983) incorporam ao conceito o desempenho técnico do projecto e a satisfação dos stakeholders do projecto: clientes, equipa do projecto e utilizadores Pinto e Slevin (1986), citado por Santos e al. (2006), define o sucesso do projecto segundo duas perspectivas: projecto (considerado factores internos) e cliente (considerado factores externos) - como ilustra a figura 6 e tabela 4. Outro aspecto a considerar é que para os autores do conceito de sucesso varia ao longo do tempo. Figura 6 Modelo de Sucesso de Projecto de Pinto e Slevin (1986). Fonte: Pinto e Slevin (1986), citado por Santos e al. (2006). Factores Internos Custo grau de cumprimento do orçamento inicial do projecto. Prazo cumprimento dos prazos inicialmente estabelecidos. Desempenho técnico grau em que o projecto atende às especificações técnicas implícitas e explícitas. Factores Externos Uso se o projecto é usado de acordo com sua proposta original. Satisfação a satisfação com o processo pelo qual o projecto está sendo foi realizado. Eficácia o projecto irá beneficiar directamente os seus utilizadores. Tabela 4 Críticos de sucesso de Pinto e Slevin (1986). Fonte: Pinto e Slevin (1986), citado por Santos e al. (2006) Morris e Hough (1987), citado com Wateridge (1995 e 1998), consideram que um projecto pode ser considerado de sucesso, mesmo que ultrapasse 2 vezes o tempo e 4 vezes o orçamento inicial, mas desde que forneça um ganho superior para o adjudicatário. Menciona ainda que o projecto pode ser medido em diversos degraus de sucesso, tendo identificado quatro critérios para avaliar o sucesso: O projecto é entregue com as funcionalidades; O projecto é implementado dentro do custo, prazo e especificações técnicas; O projecto é comercialmente vantajoso para o adjudicatário; 36 Maria da Conceição Gomes Vilas Boas

61 No caso do projecto cancelado, este é cancelado pelas razões básicas e o projecto é terminado com eficiência De Wit 1988 (citado Cooke-Davis 2002) faz a distinção entre sucesso da gestão do produto (medido através do grau de consecução dos objectivos globais do projecto) e sucesso da gestão do projecto (cuja medição é feita com indicadores de cumprimento de prazos, orçamentos e conformidade com os padrões de qualidade estabelecidos para o projecto) Pinto e Mantel (1990), citado por Dvir (1998), identificaram 3 aspectos de desempenho do projecto com Benchmarks para medir o sucesso e insucesso do projecto: (1) a implementação do processo; (2) compreender o valor do projecto e (3) a satisfação do cliente com o produto final Turner (1993), citado por Wateridge (1995 e 1998), identifica o tempo, orçamento e especificações como a mnemónica primária para medir o sucesso do projecto do ponto de vista do adjudicatário. Tendo identificado mais 6 critérios para avaliar o sucesso da implementação de projecto de SI/TI (vide tabela 5). Critérios de Sucesso Atingir o objectivo declarado das empresas Fornecer vantagem para o proprietário Satisfazer as necessidades do proprietário, utilizadores e stakeholders Satisfazer os objectivos para efectuar a instalação Instalação feita dentro do prazo, no orçamente e com as especificações O projecto satisfaz as necessidades da equipa do projecto e de apoio Tabela 5 Critérios de Sucesso de Turner (1993). Fonte: Wateridge, e Wateridge (1995) examinou mais de 100 projectos para verificar quais os critérios e factores de sucesso utilizados em projectos de tecnologia de informação (TI). O trabalho envolveu contacto com gestores de projectos, patrocinadores, utilizadores, analistas de sistemas e equipas de suporte, em que era pedido que apresentassem a sua visão sobre o sucesso de projectos de TI. O autor afirma não ter encontrado grande consenso entre os stakeholders de projectos de TI conforme se verifica na tabela 6. Contudo, existe uma certa unanimidade em relação à inclusão do cumprimento de prazos e orçamentos dentro de uma definição de critério de sucesso. O autor observou que houve uma variação nos critérios utilizados de desempenho: projectos considerados de sucesso e os considerados fracassados. Tipos de Projectos Percepção dos Utilizadores % Percepção dos Gestores de projectos % Atender aos requisitos dos utilizadores 96 Atender aos requisitos dos utilizadores 82 Todos os projectos Satisfação dos utilizadores 71 Cumprimento do orçamento 72 Cumprimento do orçamento 67 Cumprimento dos prazos 69 Atender aos requisitos dos utilizadores 96 Atender aos requisitos dos utilizadores 86 Projectos de Sucesso Satisfação dos utilizadores 71 Sucesso comercial 71 Cumprimento do orçamento 71 Cumprimento das metas de qualidade 67 Atender aos requisitos dos utilizadores 100 Cumprimento do orçamento 83 Projectos Atender ao seu propósito 100 Cumprimento dos prazos 78 Fracassados Satisfação dos utilizadores 67 Atender aos requisitos dos utilizadores 78 Tabela 6 Três Principais Critérios de Sucesso (Frequência de Citações) Segundo a Percepção dos Utilizadores e dos Gestores de Projectos. Fonte: Wateridge, Maria da Conceição Gomes Vilas Boas 37

62 Wateridge (1995), também, destaca a importância de se estabelecer, a priori, os critérios de avaliação de desempenho dos projectos entre stakeholders. Mais tarde, Wateridge (1998) em trabalho posterior identifica um conjunto de critérios de desempenho frequentemente utilizados em projectos de TI os critérios e resultados utilizados para avaliar o desempenho sofrem ligeiras modificações vide tabela 7. Tipo de Projectos Percepção dos utilizadores % Percepção dos Gestores de projectos % Atender aos requisitos dos utilizadores 96 Atender aos requisitos dos utilizadores 81 Satisfação dos utilizadores 69 Cumprimento do orçamento 71 Todos os projectos Atender ao seu propósito 65 Cumprimento dos prazos 71 Cumprimento do orçamento 62 Sucesso comercial 60 Cumprimento dos prazos 58 Atender ao seu propósito 60 Atender aos requisitos dos utilizadores 96 Atender aos requisitos dos utilizadores 86 Satisfação dos utilizadores 71 Sucesso comercial 71 Projectos de Sucesso Cumprimento do orçamento 71 Cumprimento das metas de qualidade 67 Cumprimentos dos prazos 67 Cumprimento do orçamento 62 Atender ao seu propósito 57 Atender ao seu propósito 62 Atender aos requisitos dos utilizadores 100 Cumprimento do orçamento 83 Atender ao seu propósito 100 Cumprimento dos prazos 78 Projectos Fracassados Satisfação dos utilizadores 67 Atender aos requisitos dos utilizadores 78 Satisfação da equipa 67 Sucesso Comercial 61 Sucesso comercial 67 Atingir as metas de qualidade 56 Tabela 7 Cinco Principais Critérios de Sucesso (Frequência de Citações) Segundo a Percepção dos Utilizadores e dos Gestores de Projectos. Fonte: Wateridge, Muns e Bejeirmi (1996) separam os conceitos de sucesso da gestão do projecto do sucesso de projecto. Aqui estes conceitos não são complementares. O sucesso da gestão do projecto é apenas uma parte do sucesso como ilustra a figura 7. A equipa de projecto está envolvida, apenas, com as fases 2, 3 e 4 do projecto enquanto os clientes estarão interessados nas fases 1 à 6. Assim, a equipa está, naturalmente, mais atenta ao êxito até à conclusão da fase 4 em que termina o seu envolvimento com o projecto. Os clientes (ou utilizadores) estarão interessados nos resultados finais advindos da completa utilização até a última fase. Os autores sugerem que a avaliação de desempenho pode ser feita utilizando três ópticas distintas: a) Implementação: considera as fases 2 a 4 focada nas técnicas de gestão de projectos e com a sua implementação; b) Valores percebidos: a visão dos utilizadores que irão interagir com o projecto durante os estágios de utilização; c) Satisfação do cliente: no encerramento do projecto quando o cliente pode examinar todas as influências: a avaliação do cumprimento dos objectivos globais e dos benefícios podem ser feitas. 38 Maria da Conceição Gomes Vilas Boas

63 Figura 7 As Fases do Ciclo de Vida do Projecto e as Partes Interessadas em cada Fase. Fonte: Munns e Bjeirmi (1996) O conceito de sucesso utilizado por Dvir et al. (1998) possui duas dimensões (vide tabela 8): benefícios percebidos pelo consumidor - que só podem ser avaliados após algum tempo de uso do produto e cumprimento de metas do projecto - que pode ser avaliado durante o desenvolvimento e ao término do projecto. Dimensão do sucesso Cumprimento de metas do projecto Benefícios percebidos pelo consumidor Variáveis utilizadas Especificações funcionais Especificações técnicas Prazo Orçamento Cumprimento das metas de aquisição Cumprimento dos requisitos operacionais Produto entrou em operação Chegou em tempo aos utilizadores finais O produto foi utilizado durante um período substancial de tempo O produto melhorou substancialmente o nível de operação do utilizador Utilizadores satisfeitos com o produto Tabela 8 Dimensões de Sucesso de Projecto, Segundo Dvir et al. (1998). Fonte: Dvir et al., Lim e Mohamed (1999) pensam que o sucesso do projecto pode ser visto de diferentes perspectivas dependendo dos stakeholders dono do projecto, utilizador, construtor e público em geral. Essas perspectivas diferentes explicam-se a razão por que muitos projectos são considerados por uns de sucesso e outros de insucesso. Os autores propõem que o sucesso seja avaliado nas duas perspectivas (vide figura 8): (1) Do ponto de vista macro o sucesso pode ser analisado da fase conceptual à operacional mais concretamente na fase operacional, quanto do uso e utilidade do produto resultante. Sendo a conclusão e a satisfação duas condições para o sucesso. Do ponto de vista macro é analisado do ponto de vista dos utilizadores e stakeholders; (2) Do ponto de vista micro o sucesso pode ser analisado na fase de construção isto é da execução das tarefas. Os desenvolvedores e os fornecedores analisam o sucesso do ponto de vista micro. Sendo a conclusão no tempo, custo, qualidade, performance e segurança condições para o sucesso do projecto. Maria da Conceição Gomes Vilas Boas 39

64 Figura 8 Fases do Ciclo de Vida do Projecto, perspectiva Macro e Micro (Lim e Mohamed, 1999). Fonte: Lim e Mohamed (1999). Esta divisão de micro e macro volta-se para a avaliação de processo e de produto (mais concretamente para a satisfação do utilizador) Para Baccarini (1999, p. 25) o sucesso do projecto consiste em duas componentes distintas 15, designadas por: Sucesso da gestão do projecto (visão de processo) foca-se nos processos de gestão de projectos, especialmente, sobre o êxito da realização do projecto no que diz respeito aos custos, tempo e qualidade - estas três dimensões indicam o grau de eficiência do projecto. Contudo, para medir o sucesso de gestão de projectos a dimensão, a satisfação dos stakeholder, o desenvolvimento do projecto e qualidade dos processos de gestão também necessitam ser considerados. O triângulo tradicional alarga-se para proporcionar uma visão mais completa sobre o sucesso da gestão do projecto (vide figura 9); Sucesso do produto (visão de produto) prende-se com o efeito do projecto no final (produto). Assim, na sequência de Baccarini (1999), em termos simplistas projecto de sucesso pode ser resumido na seguinte fórmula: sucesso da gestão de projectos + sucesso do produto. Figura 9 Sucesso da Gestão de Projecto Extensão da Visão Tradicional. Fonte: Westhuizen, D, et. Al. 15 De acordo com David Baccarini (1999) é comum na literatura de gestão de projectos existir uma confusão entre estas duas componentes distintas - sucesso do projecto e o sucesso do produto - e apresentá-las como um único grupo homogéneo. De forma adequada para definir e avaliar o sucesso do projecto deve ser feita uma distinção entre o sucesso do produto e sucesso da gestão do projecto uma vez que não são os mesmos. 40 Maria da Conceição Gomes Vilas Boas

65 Apesar de reconhecer a importância última do sucesso do produto, Baccarini (1999) lembra que o sucesso da gestão do projecto (processo) tende a influenciar (positivamente) o sucesso do produto. Ele destaca que a avaliação do desempenho depende de quem avalia e do instante da avaliação, e, assim, é importante estabelecer, a priori, os critérios de sucesso que serão utilizados num projecto em particular Shenhar et al. (2001) propõem que o sucesso do projecto seja medido em quatro dimensões, conforme definido na tabela 9: Critério do sucesso Variáveis utilizadas Eficiência do projecto Meta de prazo Meta de orçamento Impacto no cliente Desempenho funcional Conformidade às especificações técnicas Preenchimento das necessidades do cliente Resolução dos problemas do cliente Uso do produto pelo cliente Satisfação do cliente Sucesso do negócio Sucesso comercial Aumento ou criação de participação de mercado Preparação para o futuro Criação de novo mercado Criação de nova linha de produto Desenvolvimento de nova tecnologia Tabela 9 Critérios de Sucesso de Projecto, Segundo Shenhar et al. (2001). Fonte: Shenhar et al. (2001). Os autores reconhecem que a avaliação, da cada uma das dimensões supracitada, está dependente do tempo, isto, têm horizontes de tempo diferentes vide figura 10. Figura 10 Dimensão de Sucesso x Tempo (Shenhar et al., 2001). Fonte: Shenhar et al. (2001). Conforme se pode verificar, na figura supra, a dimensão eficiência do projecto pode ser avaliada no período de execução do projecto e logo após a conclusão do projecto. A segunda dimensão impacto nos clientes pode ser avaliada pouco tempo depois quando o projecto for entregue aos clientes. A terceira dimensão sucesso no negócio - pode ser avaliada após Maria da Conceição Gomes Vilas Boas 41

66 aproximadamente 1-2 anos da utilização do sistema. Finalmente, a quarta dimensão preparação para o futuro - só pode ser apreciada 3-5 anos após a conclusão do projecto. As importâncias relativas a cada uma destas dimensões encontram-se evidenciadas nas figuras seguintes: Figura 11 Importância Relativa das Dimensões de Sucesso x Tempo (Shenhar et al., 2001). Fonte: Shenhar et al. (2001). Figura 12 Importância Relativa das Dimensões de Sucesso x Incerteza Tecnológica (Shenhar et al., 2001). Fonte: Shenhar et al. (2001) Flores, citado por Yeo (2002), define um sistema de informação como um fracasso se quaisquer destas situações seguintes ocorrerem: (1) quando o sistema, como um todo, não funciona como esperado e o seu desempenho global é sub-óptimo; (2) se na execução não se realizar, tal como inicialmente previsto, ou se é tão hostil de utilizar que é rejeitado pelos utilizadores em funcionamento; (3) se o custo do desenvolvimento ultrapassar qualquer benefício que o sistema possa trazer ao longo da sua vida útil; ou (4) devido a problemas com a complexidade do sistema, ou a gestão do projecto, o sistema de informação em desenvolvimento é abandonado antes que ele seja concluído. 42 Maria da Conceição Gomes Vilas Boas

67 2003. Extensão do Modelo de avaliação DeLone e McLean Em 1992, DeLone e McLean tomaram consciência da dificuldade da definição da variável dependente sucesso de SI. Após realizarem uma série de estudos criaram um modelo (definidos pelos próprios como uma tentativa de reflectirem a natureza processual e interdependente do sucesso dos SI) constituído por seis dimensões: Sistema de qualidade: a medida do próprio sistema de tratamento da informação; Informação de qualidade: a medida do sistema de informação de saída; Usar informação: medida do consumo do destinatário à saída de um sistema de informação; Satisfação do utilizador: medida de resposta ao destinatário à saída de um sistema de informação; Satisfação do utilizador: medida de resposta ao destinatário no uso da produção de um sistema de informação; Impacto individual: medir o efeito das informações sobre o desempenho organizacional. Figura 13 Modelo Original de DeLone e McLean para Sucesso de Projectos. Fonte: DeLone e McLean, Ao longo dos anos, o modelo de DeLone e McLean tem sido testado e estudado o que naturalmente originou algumas críticas e propostas para a sua alteração. No entanto, continua a ser o modelo de referência utilizado nas avaliações de sucesso de um SI. O modelo de DeLone e McLean propõe que a qualidade dos sistemas e a qualidade da informação afecte, de forma singular e conjunta, a usabilidade e a satisfação do utilizador. Adicionalmente, a usabilidade pode afectar o grau de satisfação do utilizador e vice-versa. A usabilidade e a satisfação do utilizador são antecedentes directos do impacto individual e, por último, este impacto no desempenho individual deve originar um impacto organizacional (figura 13). A Qualidade dos Sistemas e a Qualidade da Informação devem ser medidas separadamente porque poderão afectar subsequentemente e de forma independente, ou não, as categorias Usabilidade e Satisfação do Utilizador. Estas últimas estão fortemente relacionadas. Em termos processuais a Usabilidade deve preceder a Satisfação do Utilizador, mas uma experiência positiva de usabilidade pode, de forma causal, originar um aumento de satisfação do utilizador. Ambas as categorias irão originar um impacto no indivíduo que irá também originar, por sua vez, um impacto na organização. Maria da Conceição Gomes Vilas Boas 43

68 Para cada uma destas categorias existem várias métricas que podem ser aplicadas. Segundo DeLone e McLean deve ser feita uma tentativa para reduzir significativamente o número de métricas utilizadas: para que os resultados das investigações possam ser comparados e as conclusões validadas. Extensão do Modelo Figura 14 Adaptação do Modelo Original de DeLone e McLean para Sucesso de Projectos. Fonte: DeLone e McLean, Dez anos mais tarde (2002) os autores publicaram a reformulação do seu modelo. As principais mudanças são as seguintes vide figura 14: A dimensão qualidade de serviço foi adicionada a qualidade (de informação e sistemas); A dimensão de intenção de uso é um alongamento do uso; A dimensão benefícios líquidos substitui o impacto individual e o impacto organizacional Factores Críticos de Sucesso A publicação Project Manager Competency Development (PMCD) Framework do PMI (páginas 1 a 5) afirma que as competências do gestor do projecto e a maturidade da organização em gestão de projectos contribuem para o sucesso do projecto vide figura 15. Figura 15 Componentes de Sucesso do Projecto. Fonte: "Project Manager Competency Development (PMCD) Framework", pág Maria da Conceição Gomes Vilas Boas

69 Afirma ainda que as competências do gestor de projecto por si só não garantem o sucesso do projecto. O PMI acredita que o sucesso do projecto exige competências em gestão de projecto, bem como maturidade e capacidade em gestão de projectos o desempenho organizacional não pode ser ignorado. Por outras palavras ter um gestor com competência não assegura o sucesso. Centra-se, exclusivamente, nas competências do gestor de projecto independente do desempenho da organização e, assim, é demasiado simplista. Factores críticos de sucesso identificados em 63 publicações Desde 1960 muitos autores têm publicado, em estudos empíricos (survey e caso de estudo) e estudos teóricos, um conjunto de factores críticos de sucesso para os projectos. Fortune e White (2006) revelam e cruzaram 63 publicações que focavam os factores críticos de sucesso: identificados 27 factores críticos de sucesso, listados na tabela 10, e ordenados pela frequência de ocorrências. FCS Apoio da alta administração Definição realista dos objectivos Plano de trabalho mantido actualizado Boa comunicação Estudos Empíricos - Survey Pinto and Slevin (1987); Magal e tal (1988); Pinto e Mantel (1990); Yap et al. (1992); Pallalis and frieze (1993); Selin and selin (1994); The Standish group (2000); Couillard (1995); Tan (1996); Belassi and Tukel (1996); Kpmg (1997); Dvir et al. (1998); Kasser and Williams (1998); Wittaker (1999); Taylor (2000); Thite (2000); Poon and Wager (2001); Andersen et al. (2002); Yeo (2002). Baker et al. (1983); Pinto and Slevin (1987); Pinto e Mantel (1990); Selin and Selin (1994); Couillard (1994); Wateridge (1995); The Standish Group (2000); Tan (1996); Dvir et al. (1998); Kasser and Williams (1998); Clarke (1999); Taylor (2000); Thite (2000); Poon and Wagner (2002); Anderson et al. (2002); Yeo (2002). Baker et al. (1983); Pinto and Mantel (1990); Pollalis and Frieze (1993); The Standish Group (2000); Watweidge (1999); Courillard (1995); Smart (1995); Belassi and Tukel (1996); KPMG (1997); Dvir et al. (1998); Kasser and Wiliams (1998); Whittaker (1999); Clarke (1999); Taylor (1995); Andersen et al. (2002); Yeo (2002). Pinto and Slevin (1987); Curis e al. (1998); Magal e al. (1988); Pinto e Mantel (1990); Curtis e tal. (1988); Pollalis and frieze (1993); Wateridge (1995); Couillard (1995); Tan (1996); Dvir et al. (1998); Kasser and Estudos Empíricos Caso de estudo Avots (1969); Morris (1986); Morris and Hough (1987); McComb and Smith (1991); Martinez (1994); Wastell and Newman (1996); Mcgolpin and Ward (1997); Jang and Lee (1998); Cooke-Davies (2002); Caldeira and Ward (2002); Westerveld (2003). Morris (1986); Yeo (1995); Beare (1995); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003). Avots (1969); Morris (1986); Morris and Hough (1987); Martinez (1994); McGolpin and Ward (1997); Westerveld (2003). Avots (1969); Morris (1986); McComb and smith (1991); Gowan and Mathieu (1996); Cooke- Davies (2002); Westerveld (2003). Estudos Teóricos Cleland and King (1983); Stoddart-Stones (1988); Cash and Fox (1992); Tennant (1993); Munns and Bjeirmi (1996); McCormack (1997); Turner (1999); Weir (1999); Turn (2004) Hughes (1986); Tennant (1993); Harding (1995); Munns and Bjeirmi (1996); Spinelli (1997); Cicmil (1997); Glass (1998); Weir (1999); Turner (2004). Cleland and King (1983); Williams (1995); Spinelli (1997); McCormack (1997); Glass (1998); Turner (1999); Turner (2004). Cleland and King (1983); Hughes (1986); Cash and Fox (1992); Hilderbrand (1996); Spinelli (1997); Turner (1999); Turner (2004). C Maria da Conceição Gomes Vilas Boas 45

70 FCS Envolvimento dos utilizadores e clientes Qualificações adequadas da equipa do projecto Gestão efectiva da mudança Competência do gestor do projecto Forte motivação comercial / conhecimentos sólidos para os projectos Boa alocação dos recursos Estudos Empíricos - Survey Williams (1998); Clarke (1999); Thite (2000); Andersen et al. (2002); Yeo (2002). Pinto and Slevin (1987); Curtis et al. (1988); Magal et al. (1988); Pinto and Mantel (1990); Yap et al. (1992); Pallalis and frieze (1993); Wateridge (1995); Smart (1995); Bellassi and Tukel (1996); Dvir et al. (1998); Yeo (2002). Baker et al. (1983); Pinto and Slevin (1987); Curtis et al. (1988); Magal et al. (1988); Pinto and Mantel (1990); Pollalis and Frieze (1993); The Standish Group (2000); Dvir et al. (1998); Poon and Wagner (2001). Pinto e Mantel (1990); Pollalis and frieze (1993); Smart (1995); The Standish Group (2000); Dvir et al. (1998); Taylor (2000); Thite (2000); Poon and Wagner (2001); Yeo (2002) Pinto and Slevin (1987); Baker et. al. (1983); Pollalis and Frieze (1993); Couillard (1995); Balassi and Tukel (1996); Dvir et. al. (1998); Taylor (2000); Andersen et al. (2002). Pollalis and Frieze (1993); Smart (1995); KPMG (1997); Dvir et al. (1998); Whittaker (1999); Poon and Wagner (2001); Andersen et al. (2002); Yeo (2002). Pinto and Slevin (1987); Yap et al. (1992); Pollalis and frieze (1993); The Standish group (2000); Belassi and Tukel (1996); Dvir et al. (1998); Kasser and Williams (1998). Boa liderança Pollalis and frieze (1993); Smart (1995); Dvier et al. (1998); Thite (2000); Andersen et al. (2002). Tecnologia comprovada familiar e Pinto e Mantel (1990); Pollalis and Frieze (1993); Tan (1996); KPMG (1997); Dvir et al. (1998); Poon and Wagner (2001); Yeo (2002). Estudos Empíricos Caso de estudo Morris (1986); McComb and Smith (1991); Beare (1995); Wastell and Newman (1996); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003). Morris (1986); Mccomb and Smith (1991); Martinez (1994); Willcocks and Griffiths (1994); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003). Avots (1969); Mccomb and Smith (1991); Martinez (1994); Willcocks and Griffiths (1994); Hougham (1996); McGolpin and Ward (1997); Cooke- Davies (2002). Avots (1969); Morris (1986); Martinez (1994); Cannon (1994); Pinto and kharbanda (1996); Westerveld (2003). Avots (1969); Pinto and Kharbanda (1996); McGolpin and Ward (1997); Cooke-Davies (2002); Caldeira and Ward (2002); Westerveld (2003). Morris (1986); Morris and Hough (1987); Gowan and Mathieu (1996); Caldeira and Ward (2002); Westerveld (2003). Morris and Hough (1987); Martinez (1994); Gowam and Mathieu (1996); Pinto and Kharbanda (1996); Caldeira and Ward (2002); Westerveld (2003). Morris (1986); McComb and smith (1991); Cannon (1994); Yeo (1995); Caldeira and Ward (2002). Estudos Teóricos Munns and Bjeirmi (1996); Cicmil (1997); Spinelli (1997); McCormack (1997); Turner (1999); Turner (2004). Cash and Fox (1992); Tenant (1993); Glass (1998); Weir (1999). Cash and Fox (1992); Cicmil (1997); Weir (1999). Munns and Bjeirmi (1996); Spinelli (1997); Glass (1998); Weir (1999); Turner (2004). Munns and Bjeirmi (1996); Turner (2004). Tennant (1993); McCormack (1997); Turner (1999); Turner (2004). Cash and Fox (1992); Tennant (1993); Turner (1999); Turner (2004). Williams (1995); Glass (1998). Cronograma Pinto e Mantel (1990); Selin Morris (1986); Morris and Cleland and King (1983); 14 C Maria da Conceição Gomes Vilas Boas

71 realista FCS Gestão do risco Campeão / Pratocionador do projecto Efectiva monitorização controlo Custos adequado e Adaptação organizacional/cul tural e estrutural Bom desempenho por parte dos fornecedores/con strutores/consulto res Planeamento encerrado / revisto/ aceite como um possível fracasso Oferta formação de A estabilidade política Escolha correcta / experiência anterior em metodologias da gestão do projecto / ferramentas Influência do desenvolvimento Estudos Empíricos - Survey and selin (1994); Dvir et al. (1998); Kasser and Williams (1998); Yeo (2002). Selin and Selin (1994); Smart (1995); KPMG (1997); Dvir et al. (1998); Whittaker (1999); Yeo (2002). Yap et al. (1992); Thite (2000); Poon and Wagner (2001); Yeo (2002). Pollalis and Frieze (1993); Selin and Selin (1994); Dvir et al. (1998); Thite (2000); Poon and Wagner (2000). Baker et al. (1983); Dvir et al. (1998) ; Pollalis and Frieze (1993). Pollalis and Frieze (1993); Couillard (1995); Taylor (2000); Thite (2000). Pollalis and frieze (1993); kpmg (1997); Yeo (2002). Estudos Empíricos Caso de estudo Hough (1987); McComb and Smith (1991); Westerveld (2003). Moriris (1997); Beare (1995); Cooke-Davis (2002); Westerveld (2003). Morris (1986); Morris and Hough (1987); Martinez (1994); MCGolpin and Ward (1997); Jang and Lee (1998); Caldeira and Ward (2002). McComb and Smith (1991); Cooke-Davies (2002); Westerveld (2003). Morris and Hough (1987); McComb and Smith (1991); Caldeira and Ward (2002); Westerveld (2003). Cahnon (1994); Willcocks and Griffiths (1994); Martinez (1994); Hougham (1996); Gowan and Mathieu (1996); Cooke- Davies (2002). Morris and Hough (1987); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003). Dvir et al. (1998) Avots (1969); Sauer (1993); Beare (1995); Pinto and Kharbanda (1996); McGolpin and Ward (1997). Magal e tal (1988); Yap et al. (1992); Pinto and Kharbanda (1995); Dvir et al. (1998). Pinto and Kharbanda (1996); Caldeira and Ward (2002). Pollalis and Frieze (1993). Morris and hough (1987); Sauer (1993); Yeo (1995); Pinto and Kharbanda (1996). Estudos Teóricos Tennant (1993); Glass (1998); Weir (1999); Turner (2004). Williams (1995); Baldry (1998); Weir (1999). Cash and Fox (1992); Baldry (1998) Cash and Fox (1992); Cicmil (1997); Weir (1999); Turner (2004). Cleland and king (1983); Tennant (1993); Glass (1998); Turner (2004). McCormack (1997); Glass (1997); Turner (2004). Cleland and king (1983); Munns and Bjeirmi (1996); McCormack (1997). McCormack (1997) 7 Tennant (1993) 6 Dvier et al. (1998). Jang and lee (1998). Hughes (1986); Munns and Bjeirmi (1996); Glass (1998); Turner (2004). Morris (1986); Pinto and kharbanda (1996); Caldeira and Ward (2002); Westerveld (2003). Cleland and King (1983); Archibald (1992). Experiência Yap et al. (1992); Dvir et al. Jordan et al. (1988); Sauer 5 C Maria da Conceição Gomes Vilas Boas 47

72 FCS Estudos Empíricos - Survey Estudos Empíricos Caso de estudo passada (1998). (1993); Cooke-Davies (2002). Projecto tamanho (grande) / nível de complexidade (alta) / número de pessoas envolvidas (muitos) / duração (mais de 3 anos) Diferente ponto de vista /apreciações Selin and Selin (1994). Curtis et al. (1988); Pinto and Kharbanda (1995). Cannon (1994); Cooke- Davies (2002). Estudos Teóricos Hughes (1986) 4 Tabela 10 Factores Críticos de Sucesso Identificados Cruzados em 63 Publicações. Fonte: Fortune e White (2006). C Turner (2004) 3 Da análise aos factores críticos de sucesso supramencionados permite concluir-se que estão associados com as competências do gestor do projecto e com a maturidade organizacional em gestão de projectos. Alinhamento do plano estratégico com o plano estratégico de SI/TI, como factor crítico de sucesso dos projectos de SI/TI Teo e Ang (1999) estudaram os factores críticos do alinhamento entre os planos de SI e os planos de negócio. O alinhamento com os planos de negócio é uma das dimensões de sucesso dos projectos de sistemas de informação. Os principais factores críticos de sucesso encontram-se em baixo listados ordem decrescente de importância: 1. Alta administração comprometida com o uso estratégico da tecnologia da informação (TI); 2. A gestão de sistemas de informação (SI) possui formação na área de negócio; 3. A alta administração tem confiança no departamento de SI; 4. O departamento de SI presta serviços eficientes e confiáveis aos departamentos utilizadores; 5. Existem comunicações frequentes entre o departamento de SI e os outros departamentos; 6. O pessoal de SI mantém-se actualizado em relação aos avanços tecnológicos na área de TI; 7. A gestão de SI e de negócios trabalham em parceria na priorização das aplicações em desenvolvimento; 8. As metas e os objectivos do negócio são conhecidos da gestão de sistemas de informação; 9. O departamento de SI é sensível às necessidades dos utilizadores; 10. A alta administração conhece TI; 11. O departamento de SI, frequentemente, propõe ideias críticas para o uso da estratégia de TI; 12. O plano corporativo do negócio está disponível para a gestão de SI. 48 Maria da Conceição Gomes Vilas Boas

73 Factor de insucesso a ausência de um plano estratégico de TI Yeo (2002) ao estudar os factores de insucesso dos projectos de sistemas de informação identificou os 3 factores seguintes: Factores ligados ao planeamento estratégico dos sistemas de informação estão relacionados: ao planeamento do negócio; ao planeamento do projecto; à gestão e ao controlo do projecto; Factores ligados ao contexto organizacional estão relacionados: à cultura corporativa; à gestão da organização; utilizadores e políticas; Factores ligados à formalização dos SI estão relacionados: à tecnologia da informação; aos processos de negócio; aos projectos de sistemas e à capacidade em TI/SI. Os factores críticos de insucesso identificados por Yeo (2002) encontram-se descritos na tabela 11. Factores críticos de sucesso Variáveis utilizadas Planeamento estratégico dos Estimativas de prazos projectos de SI Fraca definição de requisitos e de âmbito Análise de risco inadequada Suposições incorrectas em relação à análise de risco Necessidades confusas do negócio e visão nebulosa da organização Contexto organizacional do SI Falta de envolvimento do utilizador Estilo da alta administração Comunicação interna pobre Ausência de um campeão do projecto ou de um agente de mudança Tratamento reactivo dos problemas Formalização dos SI Autor do projecto subestimou a complexidade ou âmbito do projecto Especificação incompleta quando o projecto começou Escolha de software inadequada Mudanças na especificação do projecto em fases finais Factores críticos de sucesso e insucesso Tabela 11 Factores Críticos de Sucesso (Yeo, 2002). Fonte: Yeo, Baker, Murphy e Fisher (1983) analisaram o conceito de desempenho (sucesso/fracasso) e afirmam que os factores críticos de sucesso não são os factores críticos de fracasso (insucesso). A tabela, abaixo representada, ilustra elementos que pela sua presença aumentam a percepção de sucesso e fracasso: Maria da Conceição Gomes Vilas Boas 49

74 Elementos que afectam a percepção de sucesso e de fracasso Comprometimento da equipa com as metas Estimativas iniciais de custo precisas Competências da equipa de projecto adequadas Disponibilidade de recursos financeiros adequados para a conclusão Técnicas de planeamento e controlo adequadas Mínimas dificuldades de inicialização Orientação à tarefa Ausência de burocracia Gestão de projectos presente Critérios de sucesso claramente estabelecidos Tabela 12 Elementos que Afectam, Simultaneamente, a Percepção de Sucesso e de Fracasso (Backer, Murphy e Fisher, 1983). Fonte: Backer, Murphy e Fisher (1983). A tabela, seguinte representada, ilustra elementos que pela sua presença aumentam a percepção de sucesso: Elementos que afectam a percepção de sucesso Feedback frequente da organização Feedback frequente do cliente Uso sensato de técnicas de rede Disponibilidade de estratégias de reserva Estrutura organizacional adequada à equipa de projecto Procedimentos de controlo adequados, especialmente para tratar com as mudanças Participação da equipa de projecto na elaboração dos cronogramas e dos orçamentos Organização flexível Organização comprometida com os prazos estabelecidos Entusiasmos da organização Organização comprometida com os orçamentos estabelecidos Organização comprometida com as metas técnicas estabelecidas Interesse da organização com o desenvolvimento de competências internas Gestores de projectos comprometidos com os prazos estabelecidos Gestores de projectos comprometidos com os orçamentos estabelecidos Gestores de projectos comprometidos com as metas técnicas estabelecidas Cliente comprometido com os prazos estabelecidos Clientes comprometidos com os orçamentos estabelecidos Cliente comprometido com as metas técnicas estabelecidas Apoio público entusiasmado Ausência de obstáculos legais Numero reduzido de agentes públicos e governamentais Tabela 13 Elementos que Afectam a Percepção de Sucesso (Backer, Murphy e Fisher, 1983). Fonte: Backer, Murphy e Fisher (1983). 50 Maria da Conceição Gomes Vilas Boas

75 A tabela, abaixo representada, ilustra elementos que pela sua presença aumentam a percepção de fracasso: Elementos que afectam a percepção de fracasso Insuficiente uso de relatório de posição e progresso Uso superficial de relatórios de posição e progresso Gestores de projecto com capacidades de gestão inadequadas Gestores de projecto com capacidades humanas inadequadas Gestores de projecto com capacidades técnicas inadequadas Gestores de projectos com autoridade insuficiente Clientes com poder de influenciar insuficiente Baixa coordenação com o cliente Falta de apoio do cliente Desinteresse do cliente com critérios orçamentais Falta de participação da equipa do projecto no processo e decisão Falta de participação da equipa do projecto na resolução dos principais problemas. Estrutura excessivamente rígida dentro da equipa de projecto Insegurança com o cargo dentro da equipa Falta de espírito de equipa e comprometimento da equipa de projecto Organização executante instável, dinâmica, falta de mudança estratégica Má coordenação Tabela 14 Elementos que Afectam a Percepção de Fracasso (Backer, Murphy e Fisher, 1983). Fonte: Backer, Murphy e Fisher (1983) Síntese O tema do sucesso dos projectos foi durante várias décadas assunto recorrente mas, concomitantemente foi-se verificando uma gradual evolução do conceito. Saliente-se que, a definição de insucesso e de sucesso do projecto é muito nebulosa [Pinto, Jeffery K. e Mantel, Samuel J.; 1990], existindo uma variedade de definições [Agarwal et al., 2006]. Wateridge (1995) narra que não existe um grande consenso entre os stakeholders do projecto de SI/TI sobre o conceito de sucesso de projecto o que o torna um conceito multidimensional chegando até, segundo vários autores, a ser dividido em dois conceitos distintos: um associado ao processo de desenvolvimento e outro ao produto do desenvolvimento. Apesar dessa divergência entre os autores um único conceito ou dois conceitos distintos as definições de desempenho de projectos são, sem grandes dificuldades, conciliáveis. Enquanto alguns (Lim e Mohamed, 1999; Cooke-Davis, 2000; Baccarini, 1999; Munn, 1997) referem-se a dois conceitos distintos sucesso da gestão de projecto (foco no processo de desenvolvimento) e sucesso do produto (foco no produto resultante do projecto; outros (Sherar et al., 2001; Baker et al., 1983; Pinto and Slevin, 1998) entendem que existe um elemento único em discussão que possui características multidimensionais, em que a relevância de cada dimensão varia com o tempo. De acordo com Shenhar o sucesso do projecto varia ao longo do tempo. O sucesso da gestão de projecto influencia o sucesso do produto. Uma boa gestão de projecto pode influenciar o sucesso do produto, mas é improvável que seja capaz de impedir o fracasso do produto [Baccarini, 1999]. Maria da Conceição Gomes Vilas Boas 51

76 Mas, os vários estudos empíricos e estudos teóricos, publicados desde 1960, apresentam como razões para o pobre desempenho dos projectos de sistemas e tecnologias de informação os factores críticos ligados com a maturidade organizacional em gestão de projectos e com as competências em gestão de projectos. 52 Maria da Conceição Gomes Vilas Boas

77 4. Modelos de Avaliação da Maturidade Organizacional Este capítulo apresenta uma investigação e compreensão do conceito de maturidade em gestão de projectos. Em seguida, apresenta uma visão geral dos principais modelos de maturidade em gestão de projectos destacando-se os modelos CMM Capability Maturity Model, CMMI Capability Maturity Model Integration e CobiT Control Objectives for Information and Related Technologies Enquadramento Todas as organizações desejam a excelência na gestão de projectos; no entanto, muitas não reconhecem a necessidade de estabelecer um plano estratégico de TI, para a gestão dos mesmos, como forma de alcançar essa excelência. O simples uso da gestão de projectos, mesmo que realizado durante um grande período de tempo, não conduz à excelência. Pelo contrário, pode resultar na repetição sistemática dos mesmos erros. Destaque-se ainda que mesmo em organizações carentes de disciplina: alguns projectos isoladamente produzem excelentes resultados. Quando tais projectos são bem-sucedidos, é geralmente graças a esforços heróicos de uma equipa dedicada, e não através de repetição de métodos provados de uma organização com um processo de software maduro. Na ausência de um processo abrangente na organização, a repetição dos resultados depende inteiramente de se ter as pessoas disponíveis para o próximo projecto. O sucesso, que depende de pessoas específicas, não fornece condições para a melhoria da produtividade e da qualidade na organização por um longo período. Melhoramentos contínuos só podem ocorrer através de esforços focados e sustentados na direcção da construção de uma infra-estrutura de processo de desenvolvimento de software e práticas de gestão efectivas [Paulk, Mark C., 1993]. Os modelos de maturidade são um instrumento disponível para avaliar, ao mesmo tempo orientar, as organizações em direcção às melhores políticas e estratégias no que respeita à área de sistemas de informação. Ao longo do tempo, diversos modelos de maturidade da gestão de projectos foram publicados por organizações de grande prestígio: Maria da Conceição Gomes Vilas Boas 53

78 Software Engineering Institute (SEI) da Camegie Mellon desenvolveu em 1986 o Capability Maturity Model for Software, conhecido como CMM ou SW-CMM. Trata-se de um modelo destinado apoiar as organizações de desenvolvimento de software; a identificar e implementar as melhores práticas para ajudar a aumentar a maturidade dos seus processos. O CMM descreve o modo como uma organização de engenharia de software deve evoluir (em determinadas condições). Foi desenvolvido como uma norma progressiva destinada a ajudar as organizações a melhorarem continuamente as suas práticas de desenvolvimento de software. Um pouco antes, em 1987, o PMI tinha desenvolvido a primeira versão do PMBOK Guide. Em 2000, o SW-CMM foi substituído pelo Capability Maturity Model Integration [CMMI, 2006]; Em 2001 e 2003, diversos modelos de avaliação e desenvolvimento da maturidade organizacional foram desenvolvidos por reputadas organizações de consultoria internacionais, nomeadamente, como o ESI Internacional e a PMSolutions. Estes modelos baseiam-se no modelo original apresentado pelo SEI, incorporam as recomendações e conceitos apresentados pelo PMBOK Guide, nomeadamente, um conjunto de objectivos de desempenho para cada uma das nove áreas de conhecimento da gestão de projectos. Estes modelos são conhecidos com PMMM Project Management Maturity Models; Também, em 2003, o PMI publicou uma norma designada por Organization Project Management Maturity Model (OPM3). Este documento normativo define o conceito de gestão organizacional de projectos: significando com isto a aplicação do conhecimento, aptidões, ferramentas e técnicas da gestão de projectos. Em Abril de 1996, o ISACA (Information Systems Audit and Control Association) publicou pela primeira vez o Control Objectives for Information and related Tecnology (CobiT). É um Framework de Governança e uma ferramenta de suporte à tecnologia de informação (TI) que permite aos gestores encurtar as distâncias entre os requisitos de controlo, questões técnicas e riscos de negócio. O CobiT permite desenvolver políticas claras e boas práticas de controlo de TI nas organizações. Saliente-se ainda que o CobiT foi desenvolvido para ser utilizado por 4 diferentes públicos: - Direcção executiva - para obter valor dos investimentos de TI, equilibrar os riscos e controlar os investimentos no ambiente frequentemente imprevisível de TI; - Gestores do negócio - para garantir a gestão e controlo dos serviços de TI prestados internamente ou por terceiros; - Gestores de TI - para prover os serviços de TI requeridos para suportar a estratégia do negócio de uma maneira controlada e gerida; - Auditores - para subsidiar seus pareceres e aconselhar a administração sobre o controlo interno. A Framework CobiT é influenciada pelos modelos CMM e CMMI; por esse motivo será efectuada uma breve descrição destes modelos. 54 Maria da Conceição Gomes Vilas Boas

79 4.2. Capability Maturity Model (CMM) Introdução O modelo Capability Maturity Model for Software (também conhecido como o SW-CMM e CMM) foi lançado pelo Software Engineering Institute (SEI) da Carnegie Mellon University, em 1986, para dar resposta às necessidades do Departamento de Defesa dos EUA. A evolução histórica do modelo Capability Maturity Model for Software é apresentada na tabela 15: Data Entidade Descrição Nov./1986 SEI com a assistência Começa a desenvolver a estrutura de maturidade do processo que do Mitre Corporation ajudaria as organizações a melhorar os seus processos de software. Set./1987 SEI Publica uma breve descrição da estrutura de maturidade de software e um questionário de maturidade - para fornecer uma ferramenta simples para identificar as áreas onde um processo de software da organização precisava de melhoria SEI Publica a versão nº 1.0 do CMM para software SEI Publica a versão nº 1.1 do CMM para software. Tabela 15 Evolução Histórica do Modelo de Capability Maturity Model for Software. Fonte: [Paulk, Mark C., 1993]. O Capability Maturity Model for Software (CMM) cujos fundamentos foram baseados no trabalho de Watts Humphrey: É um modelo que descreve os elementos chave para um processo de software; Descreve os princípios e práticas subjacentes à maturidade do processo - pretende ajudar as organizações a melhorar esse processo através de um caminho evolutivo dividido em cinco níveis de maturidade, que vai desde um processo ad hoc e caótico até um processo de software maduro e disciplinado; Pode ser usado para avaliar e melhorar a maturidade dos processos de desenvolvimento de software; Cobre as práticas para planeamento, engenharia, gestão de desenvolvimento e manutenção de software. As práticas chaves melhoram a capacidades das organizações para atingir as suas metas de custo, cronograma, funcionalidade e qualidade do produto Organizações Imaturas Vs Organizações Maduras A definição de metas sensatas, para o melhoramento do processo, exige um entendimento das diferenças entre as organizações de software imaturas e as organizações de software maduras. Numa organização imatura os processos de software geralmente são improvisados por pessoas experientes, em conjunto com seus gestores, durante o curso do projecto. Mesmo que tenha sido especificado, o processo de software não é rigorosamente seguido ou não é obrigatório. A organização de software imatura é reaccionária e os gestores geralmente estão focados na solução de problemas imediatos (acção mais conhecida como apagar incêndios ). Os cronogramas e os orçamentos são por rotina ultrapassados porque não estão baseados em estimativas realistas. Quando são impostos prazos, que não podem ser ultrapassados, a funcionalidade e a qualidade do produto são frequentemente comprometidas para que o cronograma seja cumprido. Maria da Conceição Gomes Vilas Boas 55

80 Numa organização imatura não há bases objectivas para a avaliação da qualidade do produto e nem para a resolução de problemas associados a ele ou ao processo utilizado. Sendo assim, é difícil antever a qualidade do produto. As actividades que objectivam aumentar a qualidade, tais como revisões e testes, são frequentemente reduzidas ou eliminadas em função dos atrasos ocorridos no andamento do projecto. Por outro lado, uma organização de software madura possui habilidade para gerir o desenvolvimento de software e os processos de manutenção em toda a organização. O processo de software é cuidadosamente comunicado à equipa já existente e aos novos funcionários, sendo que as actividades são realizadas de acordo com os processos de planeamento. Os processos obrigatórios estão voltados para o uso, sendo consistentes com a forma natural de se fazer as coisas. Esses processos definidos são actualizados sempre que necessário e as melhorias são implementadas através de testes-piloto e/ou análise de custobenefício. As regras e as responsabilidades no processo definido são claras em toda a parte do projecto e da organização. Numa organização madura os gestores monitorizam a qualidade dos produtos de software e a satisfação do cliente. Há uma referência objectiva (e quantitativa) para avaliar a qualidade do produto, para analisar os problemas relacionados a ele e ao processo. Os cronogramas e os orçamentos estão baseados em desempenho histórico e são realistas; os resultados esperados para custo, cronograma, funcionalidade e qualidade do produto são quase sempre alcançados. Em geral, um processo disciplinado é seguido de forma consistente porque todos os participantes compreendem a importância disso. Além disso, existe infra-estrutura necessária para dar suporte ao processo. Para tirar proveito dessas observações, sobre as organizações de software maduras e imaturas, é necessário que se construa uma estrutura de maturidade de processo de software. Essa estrutura descreve um caminho evolutivo, desde os processos caóticos, ad hoc, até aos processos maduros e disciplinados. Sem essa estrutura, os programas de melhoria podem mostrar-se ineficientes porque não são estabelecidos os fundamentos necessários para dar suporte às sucessivas melhorias. A estrutura de maturidade de processo de software emerge da integração dos conceitos de processo, capability, desempenho e maturidade de processo de software, todos definidos nos parágrafos seguintes [Paulk, Mark C., 1993] Conceitos Fundamentais Associados ao CMM Processo. De acordo com o dicionário Westerns, um processo é um sistema de operações que produz alguma coisa... uma série de acções, mudanças ou funções que atinge um fim ou resultado [Paulk, Mark C., 1993]. O IEEE define um processo como: uma sequência de passos realizados com um dado propósito. Um processo de software pode ser definido como um conjunto de actividades, métodos, práticas e transformações - que as pessoas utilizam para desenvolver e manter um software - e os seus produtos associados (por exemplo: planos e documentos de projecto, código, casos de teste e manuais de utilizadores). À medida que uma organização vai se tornando madura o processo de software vai ficando mais definido, possibilitando que o mesmo seja implementado de modo mais consistente em toda a organização [Paulk, Mark C., 1993]. Capacidade (Capability) do processo de software. Descreve a gama de resultados esperados que podem ser alcançados com a aplicação do processo de software. A capacidade do processo de software de uma organização fornece um meio de se prever os resultados mais 56 Maria da Conceição Gomes Vilas Boas

81 prováveis a serem esperados no próximo projecto a ser empreendido pela organização [Paulk, Mark C., 1993]. Desempenho do processo. São os resultados reais alcançados mediante a prossecução de um processo de software. O desempenho de um processo de software concentra-se nos resultados alcançados (ao contrário da aptidão do processo, que se concentra nos resultados esperados). Baseados nos atributos de um projecto específico e no contexto em que este é conduzido, o desempenho real do projecto pode não reflectir a aptidão total do processo da organização, ou seja, a aptidão do projecto é restringida pelo seu ambiente. Por exemplo, alterações radicais na aplicação ou na tecnologia podem fazer com que a aptidão e o desempenho do projecto sejam inferiores à aptidão do processo total da organização [Paulk, Mark C., 1993]. Maturidade do processo de software. É a medida em que um processo específico é explicitamente definido, gerido, medido, controlado e eficaz. A maturidade implica um potencial para crescimento em aptidão e indica a riqueza do processo de software da organização e a consistência com que ele é aplicado em projectos ao longo da organização. O processo do software é bem compreendido ao longo de toda uma organização madura, geralmente através de documentação e formação, e o processo são continuamente monitorizados e melhorado pelos seus utilizadores. A maturidade do processo do software implica que a produtividade e a qualidade resultante do processo de software de uma organização podem ser melhoradas ao longo do tempo através de ganhos consistentes na disciplina alcançada no uso do seu processo de software [Paulk, Mark C., 1993] Níveis de Maturidade e Áreas Chave de Processo O modelo CMM fundamenta-se numa hierarquia de cinco níveis de maturidade, nos processos de desenvolvimento de software, conforme definido na tabela 16 [Paulk, Mark C., 1993]. Níveis de Maturidade Nível 1. Inicial Nível 2. Repetível Nível 3. Definido Nível 4. Gerido Nível 5. Optimizado. Descrição O processo de software é caracterizado como ad hoc e, ocasionalmente, mesmo caótico. Há poucos processos definidos e o sucesso depende inteiramente do esforço, competência e heroísmo individual das pessoas que actuam nas organizações. Estão estabelecidos processos básicos de gestão de projectos, para monitorização de custos, prazos e funcionalidade. Está instalada a necessária disciplina de processos para permitir a repetição de sucessos anteriores, em projectos com aplicações similares. O processo de software, dos pontos de vista da gestão e das actividades de engenharia, está documentado, normalizado e integrado num processo mais amplo a nível organizacional. Todos os projectos usam a norma do processo de software documentada e aprovada pela organização para o desenvolvimento e manutenção de software. Este nível inclui todas as características definidas no nível 2. São recolhidas medidas detalhadas do processo de software e da qualidade dos produtos. O processo e os produtos de software são compreendidos e controlados quantitativamente. Este nível inclui todas as características definidas para o nível 3. A melhoria contínua do processo é facilitada mediante feedback quantitativo do processo e através de ideias (e tecnologias) inovadoras. Este nível inclui todas as características definidas para o nível 4. Tabela 16 Níveis de Maturidade do CMM. Fonte: Autor. Maria da Conceição Gomes Vilas Boas 57

82 Cada nível de maturidade à excepção do nível 1 - é caracterizado por determinadas áreas chave do processo (ACP). Essas áreas chave são consideradas críticas para as quais a organização se deve concentrar para melhorar o seu processo. A cada área chave do processo está associado um conjunto de objectivos e práticas chaves (OPC) que possibilitarão a realização desses objectivos. Ao alcançar todos os objectivos das áreas chave do processo, de um determinado nível, completa-se esse nível, o que permite passar ao nível de maturidade seguinte vide figura 16. Figura 16 A Estrutura do CMM. Fonte: [Paulk Mark C. et al., 1993]. 58 Maria da Conceição Gomes Vilas Boas

83 As áreas chave foram definidas por níveis de maturidade - isto é, cada área chave é apresentada num único nível de maturidade - como ilustra a tabela 17. Nível CMM Nível 1. Inicial Área chave do processo Nível 2. Repetível - Gestão de Requisitos - Planeamento do Projecto de Software - Monitorização do Projecto de Software - Gestão dos Subcontratos de Software - Garantia da Qualidade do Software - Gestão da Configuração do Software Nível 3. Definido - Foco no Processo da Organização - Definição do Processo da Organização - Processo de Formação - Gestão Integrada do Software - Engenharia do Produto de Software - Coordenação Inter-grupos - Revisões por Pares Nível 4. Gerido - Gestão da Qualidade do Software - Gestão Quantitativa do Processo Nível 5. Optimizado - Gestão das Alterações ao Processo - Gestão das Alterações Tecnológicas - Prevenção de Defeitos Tabela 17 Áreas Chave do Processo por Nível de Maturidade. Fonte: Autor. Para a organização atingir um determinado nível de maturidade tem de satisfazer todas as áreas-chave do processo (ACP) desse nível, bem como as ACP de todos os níveis de maturidade inferiores. O CMM é deste modo um modelo evolutivo que possibilita a elaboração de um conjunto de recomendações, sobre a sequência das acções, a efectuar pela unidade económica para que esta possa transitar de nível de maturidade do seu processo de desenvolvimento de aplicações. Cada área chave de processo (ACP) específica objectivos que os processos da organização devem atingir para a satisfazer. O modelo CMM contém 316 práticas chave distribuídas pelas 18 áreas do processo. As avaliações subjacentes ao CMM consistem na aplicação de questionários de resposta booleana. Para que uma organização esteja num específico nível de maturidade todas as suas áreas chave, mais as dos níveis precedentes, têm de estar implementadas e institucionalizadas na organização. Maria da Conceição Gomes Vilas Boas 59

84 4.3. Capability Maturity Model Integration (CMMI) Introdução ao Capability Maturity Model Integration O modelo CMMI (Capability Maturity Model Integration) é um projecto iniciado em 1998, pelo Software Engineering Institute (SEI) da Carnegie-Mellon University, com o objectivo de integrar num só modelo vários dos seus modelos de maturidade. O CMMI é sucessor da CMM que foi desenvolvido desde 1987 até O modelo fornece orientações para a utilização no desenvolvimento de software e processos de sistemas. O modelo também pode ser utilizado como framework de instrução da maturidade dos processos da organização. A primeira versão final do CMMI v1.0 surgiu em 2000, CMMI v.1.1 é do início de 2002 e CMMI v.1.2 em 2006, conforme ilustra a figura 17. Figura 17 História do CMMs. Fonte: CMMI, A primeira versão do CMMI integra os modelos: SW-CMM V2.0 DRAFT; Systems Engineering Capability Model (SECM) e Integrated Product Development Capability Maturity Model (IPD-CMM V0.98) [CMMI, 2006]. O CMM foi reformado e o CMMI substitui-o. Actualmente, a SEI 16 já não mantém o modelo CMM, seus métodos associados ou materiais de formação, nem oferece formação. A partir de 1991 foram desenvolvidos CMMs para várias disciplinas (Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gestão e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes modelos tenham mostrado a sua utilidade - o uso de múltiplos modelos mostrou-se problemático. O CMMI surgiu para resolver o problema de se usar vários modelos e é o resultado da evolução do CMM, SECM (System Engineering Capability Model) e IPD-CMM (Integrated Product Development Capability Maturity Model). É, portanto, o sucessor destes modelos. Além disso, o framework CMMI foi desenvolvido para ser consistente e compatível com a ISO/IEC [CMMI, 2006]. 16 Após 31 de Dezembro. 60 Maria da Conceição Gomes Vilas Boas

85 Representações do CMMI As organizações podem optar entre duas abordagens para melhoria do processo: (1) abordagem de capacidade do processo; e (2) abordagem de maturidade organizacional. No primeiro caso, por uma representação contínua do processo semelhante à do modelo SE- CMM e, no segundo caso, para uma representação por estádios do processo semelhante à do modelo de SW-CMM (CMM). Assim, no CMMI existem duas representações: contínua e estádios. Tem-se assim um único modelo que pode ser visto de duas perspectivas distintas [CMMI, 2006]: Representação Contínua. Permite à organização seleccionar a área chave do processo (ou grupo de áreas chave do processo) e melhorar assim os processos usando os níveis de capacidade. Ou seja, a representação contínua é concebida para permitir aos utilizadores incidir sobre os processos específicos, que são considerados importantes para os objectivos do negócio da organização, ou aqueles a que a organização atribui um grau de risco elevado [CMMI, 2006]. Mais ainda, a representação contínua oferece máxima flexibilidade na utilização do modelo CMMI. Uma organização poderá melhorar o desempenho de um único processo, relacionado com problemas pontuais, ou então pode trabalhar em diversas áreas que estão estreitamente alinhados para os objectivos de negócio da organização. Permite, também, à organização melhorar processos com diferentes níveis. Existem algumas limitações, em termo de escolha das áreas do processo, dadas as dependências entre as áreas dos processos nas organizações. Se conhecer os processos que precisam ser melhorados na sua organização, e que compreende as dependências entre as áreas do processo descrito no CMMI, a representação contínua é uma boa escolha para a organização [CMMI, 2006]. Figura 18 Representação Contínua. Fonte: CMMI, Representação por Estádios. Utiliza um conjunto de áreas do processo definindo o caminho para a melhoria de uma organização. Este caminho de melhoria é caracterizado por níveis maturidade. Cada nível de maturidade fornece um conjunto de processos que caracterizam diferentes áreas de comportamento organizacional [CMMI, 2006]. A representação por estádios prescreve uma ordem de execução das áreas dos processos, de acordo com níveis, que define o caminho para a melhoria na organização a partir do nível inicial para o nível optimizado. A representação por estádios é concebida para proporcionar um padrão sequencial de melhorias, pode servir como uma base de Maria da Conceição Gomes Vilas Boas 61

86 comparação para avaliar a maturidade dos diferentes projectos e organizações. A representação por estádio possibilita, também, uma fácil migração do CMM para o CMMI [CMMI, 2006]. Figura 19 Representação em Estádios. Fonte: CMMI, Comparação entre a Representação Contínua e Estádios Cada representação tem vantagens e desvantagens de uma sobre a outra [CMMI, 2006]. A tabela seguinte ilustra a comparação entre a representação contínua e estádios: Representação Contínua Representação por Estádios Liberdade de escolha da ordem de melhoria que melhor satisfaz os objectivos da organização e atenua as áreas de risco da organização. Permite uma maior visibilidade das capacidades alcançadas, em cada área individual do processo. Permite melhoria de processos diferentes, a ser realizada em diferentes taxas. Reflecte uma nova abordagem que ainda não tem dados para demonstrar os seus laços com o retorno do investimento. Tabela 18 Comparação da Representação Contínua e Estádios Fonte: CMMI, Permite que as organizações tenham um caminho de melhoria pré-definido e provado. Incide sobre um conjunto de processos que fornecem uma organização com uma capacidade específica e que se caracteriza por cada nível de maturidade. Resume a melhoria dos resultados dos processos numa forma simples e um único nível de maturidade. Baseia-se na longa história de utilização, que inclui estudos de caso e dados que demonstram a rentabilidade do investimento. A representação em estágios é usada no CMM. Esta representação define um conjunto de áreas de processo para definir um caminho de melhoria, para a unidade organizacional, descrito em termos de níveis de maturidade. A representação contínua é usada no SECM, no IPD-CMM e também na ISO/IEC Esta representação permite que uma organização seleccione uma área de processo específica e melhore com relação a esta área. A representação contínua usa níveis de capacidade para caracterizar a melhoria relacionada com uma área de processo. 62 Maria da Conceição Gomes Vilas Boas

87 Níveis de maturidade A dimensão de capacidade e maturidade do CMMI são utilizadas para aferição e avaliação das actividades, bem como um orientador dos esforços da melhoria da organização: Os níveis de Capacidade, que pertencem a uma representação contínua, aplicam-se a um processo de melhoria da organização na realização da área de processos individuais. Estes níveis são um meio para incrementalmente melhorar os processos correspondentes a uma determinada área do processo. Há seis níveis de capacidade, numerados de 0 a 5. Os níveis de Maturidade, que pertencem a uma representação por estádios, aplicam-se a um processo de melhoria da organização - melhoria conquistada através de múltiplas áreas de processos. Estes níveis são uma forma de predizer os resultados do próximo projecto. Há cinco níveis de maturidade, numerados de 1 a 5. A tabela seguinte ilustra a comparação entre os níveis da representação contínua e estádios: Nível Representação Contínua Representação por Estádios Nível 0 Incompleto N/A Nível 1 Realizado Inicial Nível 2 Gerido Gerido Nível 3 Definido Definido Nível 4 Gerido Quantitativamente Gerido Quantitativamente Nível 5 Optimizada Optimizada Tabela 19 Comparação dos Níveis de Representação Continua e Estádios. Fonte: CMMI, Control Objectives for Information and related Technologies (CobiT) Enquadramento O CobiT (Control Objectives for Information and related Technology) foi disponibilizado pela primeira vez, em 1996, pela ISACF (Information Systems Audit and Control Foundation). Em 1998 foi publicada a segunda edição. Na mesma data (1998), o ITGI 17 (Information Technology Governance Institute) foi formado pela ISACA (Information System Audit and Control Association) e pela Fundação que lhe está associada (a ISACF). O ITGI publicou a terceira edição em 2000, o CobiT 4.0 em 2005 e o CobiT 4.1 em 2007 é a versão mais actual. Refira-se ainda que o CobiT 4.1 baseia-se em mais de 40 das melhores normas, framework e práticas de Tecnologias de Informação [ITGI, 2007, pág. 177]. Dos quais se destaca: (1) COSO: Internal Control-Integrated Framework, 1994 e Enterprise Risk Management-Integrated Framework, 2004; (2) Office of Government Commerce (OGC): IT Infrastructure Library (ITIL), ; (3) International Organisation for Standardisation: ISO/IEC 27000; 17 Em 1998, O ITGI foi fundado com o objectivo de realizar investigação na área, cada vez mais importante, de governança de TI, com um foco especial sobre a framework Cobit, os processos, os objectivos de controlo e os modelos de maturidade [ITIG, 2007a]. Maria da Conceição Gomes Vilas Boas 63

88 (4) Software Engineering Institute (SEI): SEI Capability Maturity Model (CMM), 1993 e SEI Capability Maturity Model Integration (CMMI), 2000; (5) Project Management Institute (PMI): A Guide to the Project Management Body of Knowledge (PMBOK), 2004; (6) Information Security Forum (ISF): The Standard of Good Practice for Information Security, 2003; (7) IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition, IT Governance Institute, USA, 2006; (8) CISA Review Manual, ISACA, De acordo com a edição 4.1 da framework CobiT, publicada pelo IT Governance Institute, esta destina-se a ser utilizado por quatro diferentes públicos: Direcção executiva, ajuda a obter valor dos investimentos de TI, equilibrar os riscos e controlar os investimentos no ambiente frequentemente imprevisível de TI; Gestores do negócio, ajuda a garantir a gestão e controlo dos serviços de TI prestados internamente ou por terceiros; Gestores de TI, ajuda a prover os serviços de TI requeridos para suportar a estratégia do negócio de uma maneira controlada e gerida; Auditores, utilizam para corroboram os seus pareceres e aconselham a gestão sobre o controlo interno. Composição do CobiT. Resumidamente, o CobiT é composta pelos seguintes produtos [ITGI, 2007]: Board Brienfing on IT Governance, 2nd Edicion; Management Guidelines / Maturity models; CobiT and Val IT Frameworks; Control Objectives; Key Management practices; IT Governance implementation guide, 2 nd edition; CobiT control practices, 2 nd edition; IT Assurance Guide Conceitos e Definições Fundamentais para a Framework CobiT Controlo. As políticas, procedimentos, práticas e estruturas organizacionais são concebidas para fornecer uma garantia razoável de que os objectivos de negócio serão atingidos; que eventos indesejáveis serão prevenidos ou detectados e corrigidos [ISACA, 2006]. Objectivo de Controlo. Uma declaração do resultado desejado ou objectivo deverá ser alcançado através da aplicação de procedimentos de controlo numa determinada actividade TI [ISACA, 2006]. Práticas de Controlo. Análises práticas e orientações sobre como implementar os objectivos de controlo [ISACA, 2006]. 64 Maria da Conceição Gomes Vilas Boas

89 Governança de TI. Uma estrutura de relacionamentos e processos para dirigir e controlar a organização, a fim de alcançar os objectivos da organização, acrescentar valor ao mesmo e, ao tempo, equilibrar risco versus retorno sobre TI e seus processos [ISACA, 2006] Princípios da Framework CobiT As principais características da framework CobiT 4.1 são: orientação aos negócios; orientação aos processos; orientação aos controlos; e por último, os mecanismos de medição. A orientação ao negócio tenta unir os objectivos de negócios da TI, fornecendo métricas e modelos de maturidade para melhorar a avaliação de TI, além de auxiliar na identificação de responsabilidades das áreas de negócio e TI. A framework CobiT é baseada no seguinte princípio - para fornecer a informação de que a organização necessita para atingir os seus objectivos, a organização deve investir, gerir e controlar recursos TI usando um conjunto estruturado de processos de prestação de serviços que proporcionam a necessária informação à organização conforme figura 20: O CobiT subdivide-se em 4 domínios: Figura 20 Princípios Básicos do CobiT. Fonte: ITIGI, Planeamento e Organização (PO). Este domínio cobre estratégia, tácticas e diz respeito à identificação da forma como as TI podem melhor contribuir para a realização dos objectivos de negócio. Além disso, a realização da visão estratégica precisa ser planeada, comunicada e gerida por diferentes perspectivas. Aquisição e Implementação (AI). Para concretizar a estratégia TI as soluções TI precisam de ser identificadas, desenvolvidas ou adquiridas, bem como implementadas e integradas no processo empresarial. Além disso, as mudanças na manutenção dos sistemas existentes são abrangidas por este domínio para se certificar de que o ciclo de vida é continuado. Entrega e Suporte (DS). Este domínio está preocupado com a entrega efectiva dos serviços necessários, que vão das tradicionais operações sobre os aspectos de segurança e continuidade à formação. Monitorização e Avaliação (ME). Todos os processos de TI necessitam de ser regularmente avaliados, ao longo do tempo, pela sua qualidade e para controlar o cumprimento dos Maria da Conceição Gomes Vilas Boas 65

90 requisitos. Monitorização e Avaliação (ME). Todos os processos de TI necessitam de ser regularmente avaliados ao longo do tempo pela sua qualidade e controlar o cumprimento dos requisitos. Importa ainda referir que, cada domínio cobre um conjunto de processos, para garantir a completa gestão de TI, somando 34 processos, vide tabela abaixo: Domínios Planeamento Organização (PO) e Aquisição e Implementação (AI) Entrega e Suporte (DS) Monitorização Avaliação (ME) e Processos PO1 - Definir um plano estratégico de TI PO2 - Definir a arquitectura da informação PO3 - Determinar a direcção tecnológica PO4 Definir os processos de TI, organização e relacionamentos PO5 - Gerir o investimento em TI PO6 - Comunicar as metas e as linhas de orientação de gestão PO7 - Gerir os recursos humanos de TI PO8 - Gerir a qualidade PO9 - Avaliar e gerir os riscos de TI PO10 Gestão de projectos AI1 - Identificar as soluções de automação AI2 - Adquirir e manter software aplicacional AI3 - Adquirir e manter a infra-estrutura tecnológica AI4 - Facilitar a operação e utilização de TI AI5 - Obter recursos de TI AI6 - Gerir as alterações AI7 - Instalar e validar as soluções e as alterações DS1 - Definir e manter os acordos de níveis de serviços (SLA) DS2 - Gerir os serviços de terceiros DS3 - Gerir a performance e a capacidade DS4 - Assegurar serviço contínuo DS5 - Garantir a segurança dos sistemas DS6 - Identificar e alocar custos DS7 - Educar e Treinar dos utilizadores DS8 - Gerir o serviço de help-desk e os Incidentes DS9 - Gerir a configuração DS10 - Gerir os problemas DS11 - Gerir os dados DS12 - Gerir o ambiente físico DS13 - Gerir as operações ME1 - Monitorar e avaliar a performance de TI ME2 - Monitorar e avaliar o controlo interno ME3 - Assegurar conformidade com regulamentações ME4 Definir IT Governance Tabela 20 Domínios vs Processos de CobiT. Fonte: CMMI, A estrutura do CobiT possui 34 processos, agrupados em 4 domínios, e propõe uma maneira de gerir os recursos de TI (Pessoas, Aplicações, Informação e Infra-estrutura) de maneira a fornecer informações relevantes ao atendimento dos objectivos do negócio e da governança. 66 Maria da Conceição Gomes Vilas Boas

91 O CobiT segue sete (7) critérios de informação: Eficácia das operações e processos de TI; Eficiência das operações e processos de TI; Confidencialidade da informação; Integridade da informação; Disponibilidade da informação e dos sistemas onde esta é mantida; Conformidade com a legislação e Fiabilidade da informação. O modelo também propõe a utilização eficiente dos recursos da TI, relacionando-os aos critérios e processos do modelo vide figura 21. Figura 21 Framework CobiT. Fonte: ITIGI, O CobiT 4.1 contém 34 processo de alto nível e 214 objectivos de controlo detalhados para os processos de TI. Esses Objectivos de Controlos são suportados pelos Guias de Auditoria ( Management Guidelines ) consultar os seguintes documentos com as seguintes referências: [ITIG-MyCobiT, 2007a], [ITIG-MyCobiT, 2007b], [ITIG-MyCobiT, 2007c] e [ITIG- MyCobiT, 2007d]. Saliente-se ainda que, o CobiT 4.1 possui uma grelha constituída por objectivos de controlo associados a cada processo, designada por Control Objectives Assessment Forms, baseada nos conceitos de maturidade que visa posicionar uma organização no nível de maturidade que representa a evolução conseguida pela função TI. Maria da Conceição Gomes Vilas Boas 67

92 Modelo de Maturidade O modelo de maturidade para a gestão e controlo dos processos de TI é baseado num método de avaliação da organização, utilizando uma escala de seis níveis, desde o nível de maturidade inexistente (0) para optimizada (5) vide figura 22. Figura 22 Gráfico de Representação dos Níveis de Maturidade. Fonte: ITIGI, Esta abordagem é derivada do modelo de maturidade do Software Engineering Institute (SEI), utilizado para avaliar a maturidade da capacidade de desenvolvimento de software. Saliente-se ainda que a partir dos níveis de maturidade, para cada um dos 34 processos, é possível identificar: 1. Desempenho real da organização (onde estamos); 2. A situação actual da organização (benchemarking); 3. Os avanços possibilitados pelos padrões e modelos disponíveis no mercado; 4. A meta para a melhora do processo da organização (onde queremos estar). Uma melhor descrição, de cada um destes níveis, pode ser vista no modelo genérico de maturidade como segue: Níveis Maturidade de Nível 0. Inexistente Nível 1. Inicial / Ad Hoc Nível 2. Repetitivo mas intuitivo Nível 3. Definido Descrição do Ambiente de Controlo Completa inexistência do processo. A entidade não reconhece a necessidade de tratar e gerir o assunto. A entidade reconhece a pertinência do assunto e necessidade de o abordar. Os processos não se encontram uniformizados, a abordagem é intuitiva e tende a ser aplicada por um indivíduo ou em casos específicos. Na generalidade a abordagem do processo é desorganizada. O processo encontra-se num estado em que diferentes pessoas adoptam o mesmo procedimento para a mesma função. Não existe uma formação ou comunicação formal dos procedimentos adoptados e a responsabilidade está a cargo do indivíduo. Há uma grande dependência no conhecimento individual de determinados colaboradores. Os procedimentos encontram-se uniformizados e formalizados, sendo comunicados através de formação. É obrigatório o cumprimento destes processos, no entanto, será pouco provável a detecção de excepções ou desvios. Os procedimentos não são de todo sofisticados, constituindo 68 Maria da Conceição Gomes Vilas Boas

93 Nível 4. Mensurável Nível 5. Optimizado uma mera formalização das práticas existentes. A gestão monitoriza e avalia o cumprimento dos procedimentos e adopta medidas quando os processos aparentam não funcionar eficazmente. Os processos encontram-se em constante melhoria e asseguram um conjunto de boas práticas. A utilização de processos automáticos e ferramentas informáticas é limitado ou utilizado de forma fragmentada e estanque. Os processos encontram-se revistos ao nível das boas práticas, como resultado de melhoria contínua e da análise de maturidade face a outras entidades. As TI são utilizadas de forma integrada para automatizar o workflow, fornecendo ferramentas para melhorar a qualidade e eficácia, facilitando dessa forma a capacidade de adaptação da entidade. Para além do modelo de maturidade genérico supra-apresentado, o CobiT apresenta um modelo de maturidade específico, para cada um dos 34 processos, a partir dos níveis de maturidade definidos no modelo de maturidade genérico [ITIG, 2007] Planeamento Estratégico de TI e Gestão de Projectos Neste ponto apresenta-se uma descrição do processo PO1- Definir Planeamento Estratégico de TI e do processo PO10 - Gestão de Projectos. São, também, descritos os objectivos de controlo dos referidos processos e os riscos associados Definir Planeamento Estratégico de TI (Processo PO1) O planeamento estratégico de TI é necessário para gerir e direccionar todos os recursos TI - em conformidade com a estratégia de negócios e prioridades. A função TI mais as empresas interessadas são responsáveis por garantir que o valor óptimo é realizado a partir de projecto e carteiras de Serviços. O plano estratégico de TI é necessário para gerir, direccionar todos os recursos em conformidade com a estratégia de negócio e as suas prioridades. A função de TI e stakeholders da organização são responsáveis por garantir a realização óptima dos projectos e dos portfolios. O plano estratégico de TI melhora a compreensão das oportunidades e limitações da organização, avalia o desempenho actual, identifica requisitos de capacidade, recursos humanos e esclarece o nível de investimento necessário. A estratégia de negócio e prioridades devem ser reflectidas nos portfolios e serem executados através de planos tácticos. [ITIG, 2007]. O processo Definir um Planeamento Estratégico de TI é constituído pelos seguintes objectivos de controlo: Objectivo de Controlo: 1.1. Gerir o Valor de TI. A gestão deve garantir que o portfolio de investimentos de TI é constituído por programas sólidos para o negócio. Os serviços de TI devem ser executados de acordo com níveis de serviço (SLAs) equitativos e exequíveis. As responsabilidades para alcançar os benefícios e controlar os custos devem ser claramente atribuídas como também monitorizadas. Estabelece condições justas, transparentes, repetitivas e comparáveis dos processos organizacionais, inclusive o valor financeiro, o risco de não entregar funcionalidades e o risco de não materializar os benefícios esperados; Maria da Conceição Gomes Vilas Boas 69

94 Objectivo de Controlo: 1.2. Alinhamento das TI com o Negócio. A gestão deve estabelecer processos bidireccionais e recíprocos envolvendo o planeamento estratégico, para alcançar os objectivos de negócio, o alinhamento e integração de TI. Mediar entre os imperativos do negócio e de TI para que possam ser acordadas as prioridades; Objectivo de Controlo: 1.3. Avaliação de desempenho e capacidade actual. A gestão deve avaliar o desempenho e capacidade dos actuais sistemas de informação e serviços, para estabelecer uma linha a partir da qual futuras exigências possam ser comparadas. Definir o desempenho de TI em termos da contribuição para os objectivos de negócios, funcionalidade, estabilidade, complexidade, custos, pontos fortes e fracos; Objectivo de Controlo: 1.4. Plano Estratégico de TI. Criar um plano estratégico, em cooperação com os principais stakeholders, que defina como os objectivos das TI contribuem para os objectivos estratégicos, custos e riscos relacionados. O plano deve incluir a forma como as TI irão suportar os programas de investimento, serviços e activos de TI. Deverá definir o modo como os objectivos serão cumpridos, as medidas e os procedimentos para obtenção da aprovação formal dos stakeholders. O plano estratégico de TI deverá abranger investimentos, orçamento, fontes de financiamento, estratégia de contratação e de aquisição, bem como as exigências legais e reguladoras. O plano estratégico de TI deve ser suficientemente detalhado para permitir a definição de planos tácticos de TI; Objectivo de Controlo: 1.5. Planos Táctico TI. Criar um portfolio de planos tácticos de TI que são obtidos a partir do plano estratégico de TI. Os planos tácticos de TI devem abordar o programa de investimentos, de serviços a prestar e activos de TI. Os planos tácticos de TI deverão descrever as iniciativas e requisitos de TI, recursos necessários, os recursos que são utilizados, como os benefícios são controlados e geridos. Os planos tácticos de TI devem ser suficientemente pormenorizados para permitir a definição de planos de projectos. Gerir de forma activa o conjunto de planos tácticos de TI, iniciativas através da análise do portfolio de projectos e serviços; Objective de Controlo: 1.6. Gerir o Portfolio de TI. Gerir activamente, com o negócio, o portfolio de TI ligando os programas de investimento de TI, necessários para alcançar objectivos estratégicos de negócio, através da identificação, definição, avaliação, priorização, selecção, inicialização, gestão e controlo dos programas. Essa estratégia deverá incluir a clarificação pretendida dos resultados de negócio, garantindo que os objectivos dos programas apoiam os resultados, atribuindo a responsabilidade dessas medidas, definindo o âmbito dos projectos dos programas, alocação de recursos humanos e financeiros, a delegação de autoridade, e comprometer-se no lançamento dos projectos. 70 Maria da Conceição Gomes Vilas Boas

95 A framework Cobit apresenta um conjunto de riscos associados aos objectivos de controlo do processo planeamento estratégico de TI, que se passa a descrever: Objectivo Controlo de Gerir o Valor de TI Alinhamento das TI com o Negócio Avaliação de desempenho e capacidade actual Plano Estratégico de TI Planos TI Táctico Gerir o Portfolio de TI Riscos A ineficácia na decisão conduz a investimentos em TI sem retorno ou com impacto negativo sobre a organização. TI não alinhadas com o negócio. Falta de apoio e empenho da gestão relativamente às TI. Responsabilidades indefinidas ou confusas Custos, benefícios e riscos das TI pouco claros ou mal entendidos. TI não cumpre os requisitos governação, para potenciar impactar na gestão TI é vista como um factor de custos A missão da empresa não foi apoiada pelo seu TI TI não segue as decisões de gestão do negócio direcção A falta de entendimento comum entre as prioridades de negócio e as TI, levando a conflitos sobre a alocação de recursos e prioridades Oportunidades perdidas para a exploração de novas capacidades de TI As capacidades de TI não contribuem para a missão da organização e objectivos Decisões de investimentos tomadas demasiado tardem Oportunidades e capacidades não promovidas Utilização ineficaz dos recursos existentes Incapacidade de identificar as actuais e futuras exigências para, a gestão e desempenho Os requisitos de negócio não compreendem a gestão de TI Planos de TI não alinhados com as necessidades das organizações Investimentos desnecessários Planos de TI inconsistentes com os requisitos ou expectativas das organizações TI não incidiu sobre as prioridades correctas TI de longo prazo não realizados Recursos disponíveis não promovem benefícios para o negócio Desvios nos planos de TI planos não identificados Prioridades incompreendidas e sujeitas as alterações Informação para acompanhar o desempenho da TI não disponível Oportunidades de negócio perdidas devido a uma carteira conservador RÓI baixo devido a uma carteira agressiva Recursos disponíveis não promovidos Desvios nos TI planos não identificados Este modelo permite ainda efectuar uma gestão mais rigorosa do processo de Planeamentos Estratégico das TI dentro das organizações ao oferecer um conjunto de métricas para a avaliação dos resultados, tais como: Indicadores de desempenho; Indicadores chave de objectivos e factores críticos de sucesso consultar os seguintes documentos com as seguintes referências: [ITIG-MyCobiT, 2007a], [ITIG-MyCobiT, 2007b], [ITIG-MyCobiT, 2007c] e [ITIG-MyCobiT, 2007d]. Maria da Conceição Gomes Vilas Boas 71

96 Gestão de Projectos (Processo PO10) A framework de gestão de programa e de gestão de projectos é estabelecida para a gestão de todos os projectos. A framework garante a correcta definição de prioridades e coordenação de todos os projectos. A framework inclui um plano do projecto - com os recursos, definição das entregas, plano de gestão da qualidade, plano formal de teste, plano de riscos. Esta abordagem reduz o risco de custos imprevistos e cancelamentos projecto, melhora a comunicação e o envolvimento da organização e utilizadores finais, garante o valor e a qualidade das entregas (isto é, produtos) do projecto, e maximiza a sua contribuição para a TI - activado programas de investimento [ITIG, 2007]. O processo Gestão de Projectos é constituído pelos seguintes objectivos de controlo: Objectivo de Controlo: Framework de Gestão de Programas. Manter a programação dos projectos relacionados com o portfolio de TI ligando os programas de investimento, através da identificação, definição, avaliação, priorização, selecção, inicialização, gestão e controlo dos projectos. Assegurar que os projectos apoiam os objectivos da programação. Coordenar as actividades e as interdependências dos múltiplos projectos, gerir a contribuição de todos os projectos no âmbito do programa para os resultados esperados, resolver os pedidos de recursos e conflitos de recursos; Objectivo de Controlo: Framework de Gestão de Projectos. A gestão deve estabelecer e manter uma framework de gestão de projectos que defina o âmbito e os limites da gestão de projectos, bem como as metodologias a adoptar e aplicar a cada um dos projectos realizados. A framework e metodologias de suporte devem ser integradas com os processos de gestão da programação; Objectivo de Controlo: Abordagem de Gestão de Projectos. Estabelecer uma abordagem de gestão de projectos proporcional à dimensão, complexidade e requisitos regulamentares de cada projecto. A estrutura de gestão de projecto deve incluir os papéis, responsabilidades, patrocinador do programa e projecto, committee e gestor de projecto, e os mecanismos através dos quais eles podem cumprir essas responsabilidades (tais como a elaboração de relatórios e fases de revisão). Certificar-se de que todos os projectos têm patrocinadores, com suficiente autoridade, para a execução do projecto no âmbito do programa estratégico global; Objectivo de Controlo: Compromisso de Stakeholder. Obter o compromisso e a participação dos stakeholder, na definição e execução do projecto, dentro do contexto do programa global de investimento em TI; Objectivo de Controlo: Declaração de Âmbito de Projecto. Definir e documentar a natureza (e âmbito) do projecto, para confirmar e desenvolver um entendimento comum entre as partes interessadas no projecto, e a forma como se relaciona com os outros projectos dentro do programa de investimento de TI. A definição deverá ser formalmente aprovada pelos patrocinadores do projecto antes de iniciar; Objectivo de Controlo: Fase Inicial do Projecto. Assegurar que o início de cada fase do projecto é comunicado a todas as partes interessadas. A aprovação da fase inicial baseia-se em decisões de gestão da programação. A aprovação das fases subsequentes deve basear-se na revisão e aceitação de entregas da fase anterior, bem como a aprovação de actualização que implique revisão na programação. Em caso de sobreposição de fases do projecto deve ser estabelecido um ponto de aprovação, por parte dos patrocinadores do projecto e programa, para autorizar a progressão do projecto; 72 Maria da Conceição Gomes Vilas Boas

97 Objectivo de Controlo: Planeamento Integrado do Projecto. Estabelecer um plano integrado para o projecto, aprovado e formal (abrangendo os recursos da organização e os sistemas de informação) para orientar a execução do projecto como o seu controlo durante todo o ciclo de vida. As actividades e interdependências dos vários projectos dentro de um programa devem ser entendidas e documentadas. O plano do projecto deve ser mantido durante todo o ciclo de vida do mesmo. O plano do projecto, bem como as alterações ao mesmo, deve ser aprovado em conformidade com a framework de gestão do programa e projecto; Objectivo de Controlo: Recursos do Projecto. Definir as responsabilidades, relacionamentos, autoridades e critérios de desempenho dos membros da equipa do projecto, e especificar a base para a aquisição e atribuição dos membros da equipa e/ou contratados para o projecto. A aquisição de produtos como serviços necessários para cada projecto deve ser planeada e gerida para alcançar os objectivos do projecto, através de práticas de aquisição da organização; Objectivo de Controlo: Gestão do Risco do Projecto. Eliminar ou minimizar os riscos específicos associados com os projectos através de um processo sistemático de planeamento, identificação, análise, resposta, monitorização e controlo das áreas ou eventos que têm potencial para causar alterações indesejadas. Os riscos do processo de gestão do projecto e entrega do projecto devem ser oficializados como também registados centralmente; Objectivo de Controlo: Plano de Qualidade do Projecto. Preparar um plano de qualidade que descreva o sistema de qualidade do projecto e como será implementado. O plano deverá ser formalmente analisado, acordado por todas as partes envolvidas, e, em seguida, incorporado no plano do projecto; Objectivo de Controlo: Controlo das Alterações do Projecto. Estabelecer um sistema de controlo das alterações para cada projecto, de modo que todas as alterações ao projecto inicial (por exemplo, custo, tempo, âmbito, qualidade) são adequadamente revistas, aprovadas e incorporadas de maneira adequada, no plano global do projecto, de acordo com o framework de gestão do programa e do projecto; Objectivo de Controlo: Planeamento dos Métodos de Segurança. Identificar as tarefas de segurança necessárias para apoiar a aprovação de sistemas novos ou modificados, durante o planeamento de projectos, e incluí-las no plano integrado do projecto. As tarefas devem fornecer garantias de que os controlos internos e recursos de segurança satisfazem os requisitos definidos; Objectivo de Controlo: Medir, Reportar e Monitorizar o Desempenho do Projecto. Medir o desempenho do projecto com critérios chave de desempenho como: âmbito, tempo, qualidade, custos e riscos. Identificar eventuais desvios do plano. Avaliar o impacto dos desvios, no projecto e programa, e relatar os resultados para as principais partes interessadas. Recomendar, implementar, acompanhar acções correctivas, quando necessário, em consonância com a framework de gestão de programa e de projecto; Objectivo de Controlo: Encerramento do Projecto. Solicitar que, no final de cada projecto, os stakeholders verifiquem se os resultados são os planeados e os benefícios são os esperados. Identificar e comunicar quaisquer actividades necessárias para atingir os resultados planeados do projecto como os benefícios do programa, identificar e documentar as lições apreendidas para uso em futuros projectos e programas. Maria da Conceição Gomes Vilas Boas 73

98 A framework Cobit apresenta um conjunto de riscos associados aos objectivos de controlo do processo gestão de projectos, que se passa a descrever: Objectivos de Controlo Framework de Gestão de Programas Framework de Gestão de Projectos Abordagem de Gestão de Projectos Compromisso Stakeholder de Declaração de Âmbito de Projecto Fase Inicial do Projecto Planeamento do Projecto Integrado Recursos do Projecto Gestão do Risco do Projecto Plano de Qualidade do Projecto Controlo das Alterações do Projecto Riscos Inapropriado priorização do projecto Desorganizada e ineficaz abordagem do programa do projecto programas Desalinhamento do projecto com os objectivos do programa Diferentes abordagens de gestão de projectos no âmbito da organização Falta de comunicação estruturada dentro organização Ferramentas inconsistentes para gestão de projecto Confusão e incerteza causada por diferentes abordagens de gestão de projectos no âmbito da organização Falta de comunicação estruturada na organização Falta de resposta às questões do projecto e decisões aprovadas Imprecisão na contabilização e responsabilidades para assegurar o controlo dos custos Insuficiente participação dos interessados na definição de requisitos e revisão dos mesmos Compreensão reduzidas dos benefícios Incompreensão dos objectivos do projecto e exigências Incompreensão do impacto do projecto com outros projectos relacionados A falta de alinhamento dos projectos com a visão da organização Priorização errada de projectos Desvios não detectados no plano global do projecto Má utilização dos recursos Erros detectados no planeamento e orçamentação A falta de alinhamento dos projectos com os objectivos da organização e interdependência com outros projectos As lacunas no conhecimento e recursos críticos do comprometer a missões do projecto A utilização ineficiente dos recursos Contrato de litígios com recursos terceirizados Não detectados os riscos do projecto A falta de acções para mitigar os riscos identificados Projecto não satisfaz os requisitos dos utilizadores Lacunas na qualidade esperada (e entregues) relativamente ao âmbito do projecto Ineficiente e fragmentada abordagem de garantia de qualidade A falta de controlo sobre âmbito do projecto, custo e cronograma Perda de foco comercial A incapacidade de gerir recursos 74 Maria da Conceição Gomes Vilas Boas

99 Planeamento dos Métodos de Segurança Medir, Reportar e Monitorizar o Desempenho do Projecto Encerramento do Projecto Garantia actividades de falsas Atrasos na acreditação e implementação Ineficácia na identificação de problemas e sua informação A falta de controlo sobre os progressos do projecto Perda de interesse sobre as expectativas do cliente e as necessidades da organização Detectado deficiências de gestão de projectos Oportunidades perdidas a partir de lições aprendidas Este modelo permite ainda efectuar uma gestão mais rigorosa do processo de gestão de projectos dentro das organizações ao oferecer um conjunto de métricas para a avaliação dos resultados, tais como: Indicadores de desempenho; Indicadores chave de objectivos e factores críticos de sucesso consultar os seguintes documentos com as seguintes referências: [ITIG- MyCobiT, 2007a], [ITIG-MyCobiT, 2007b], [ITIG-MyCobiT, 2007c] e [ITIG-MyCobiT, 2007d] Avaliação da Maturidade - Síntese Os modelos de maturidade são um instrumento disponível para avaliar, e ao mesmo tempo orientar, as organizações em direcção às melhores políticas e estratégias no que respeita à área de sistemas de informação. A utilidade principal destes modelos é permitir identificar (por avaliação) a situação corrente (estádio actual de maturidade) bem como planear a progressão para o próximo estádio, assumido que a organização se move de um estádio X para um Y, tornando-se mais madura. Portanto, o processo de crescimento ou aperfeiçoamento descreve as características dos estádios que podem ser usados como forma de medir a maturidade. Os modelos CMM e CMMI foram desenvolvidos pela Carnegie Mellon University em parceria com o SEI Software Engineering Institute. O CMM, cuja versão integral foi publicada em 1993, apresenta cinco níveis de maturidade, sendo cada um deles caracterizado por um conjunto de áreas chave cuja estrutura é considerada necessária para o projecto como para o desenvolvimento de software. Os cinco níveis de maturidade contemplados pelo modelo CMM são: nível 1 Inicial; nível 2 Repetitivo; nível 3 Definido; nível 4 Gerido; nível 5 Optimizado. O modelo CMMI, que teve a sua primeira versão lançada em 2000, possui duas formas de representação: a representação em estádios e a representação contínua. No modelo CMMI em estádios, de forma análoga ao CMM, há cinco níveis de maturidade, assim definidos: nível 1 inicial; nível 2 gerido; nível 3 definido; nível 4 Gerido quantitativamente; e nível 5 optimizado. Para cada nível de maturidade são definidos um conjunto de requisitos estruturais das áreas-chave de processo. No modelo CMMI em contínuo o que se obtém é um perfil de maturidade da organização; ou seja, uma avaliação do nível de maturidade de cada uma das áreas-chave do processo. Segundo o modelo CMMI contínuo há seis níveis de maturidade para cada uma das áreas de processo: nível 0 Incompleto; nível 1 Realizado; nível 2 Gerido; nível 3 Definido; nível 4 Gerido quantitativamente; nível 5 Optimizado. O CobiT é um referencial internacional de gestão de Tecnologias de Informação (TI) cujo principal objectivo é fornecer um conjunto de recursos que poderão servir como modelo de alinhamento entre os objectivos da área de TI e os objectivos de negócio. Maria da Conceição Gomes Vilas Boas 75

100 De acordo com ISACA, o CobiT introduz uma ferramenta de avaliação do progresso de uma organização ao longo de um modelo de maturidade, detalhado em cinco níveis. A framework CobiT baseia-se em: 7 Critérios de Informação (Eficácia das operações processos de TI, eficiência das operações processos de TI, confidencialidade da informação, integridade da informação, disponibilidade da informação e dos sistemas onde esta é mantida, conformidade com legislação, fiabilidade da informação); Recursos de TI necessários para suportar o negócio (Pessoal, Aplicações, Informação, Infra-estruturas); Modelos de maturidade que indicam o estado de cada um dos processos. O CobiT 4.1 possui uma grelha constituída por objectivos de controlo associados a cada processo, designada por Control Objectives Assessment Forms, baseada nos conceitos de maturidade que visa posicionar uma organização no nível de maturidade que representa a evolução conseguida pela função TI conforme definido no ponto No CobiT Management Guidelines existe um modelo de maturidade - semelhante ao CMMI com níveis de 0 (Inexistente) a 5 (Optimizado) - para avaliar os níveis de maturidade de cada objectivo de controlo. Assim, o nível de maturidade de cada objectivo de controlo será medido através dessa escala conforme definido no ponto O CobiT 4.1 possui dois (2) modelos de maturidade para avaliação dos processos o modelo genérico e o modelo específico para cada processo conforme ilustrado no capítulo 4, ponto Maria da Conceição Gomes Vilas Boas

101 5. O Problema Na revisão da literatura realizada nos capítulos anteriores apresentaram-se, discutiram-se tópicos e preocupações nucleares à área de gestão de projectos de SI/TI: com ênfase para a metodologia de gestão de projectos; a avaliação dos projectos de SI/TI e os modelos de maturidade organizacional em gestão de projectos. Boas práticas de Gestão de Projectos Constatou-se que no meio académico e organizacional é discutida a importância das boas práticas de gestão de projectos nas organizações, tais como as ditadas pelo PMI no seu guia PMBok (Project Management Body of Knowledege), pois se estas não estiverem enraizadas na cultura organizacional a possibilidade da organização atingir a excelência em gestão de projectos é baixa vide capítulo 2. Metodologias de Gestão de Projectos Mais: verificou-se que a aplicação das metodologias de gestão de projectos é um dos principais factores para o sucesso dos projectos de Sistemas e Tecnologias de Informação (SI/TI) [PMBOK, 2004]. Competências do Gestor do Projecto e Maturidade Organizacional em Gestão de Projectos Há vários autores sugerem que a principal causa do sucesso dos projectos de Sistemas e Tecnologias de Informação (SI/TI) se deve às competências do gestor do projecto e à maturidade da organização em gestão de projectos (Pinto and Slevin, 1987; Magal et al., 1988; Pinto e Mantel, 1990; Yap et al., 1992; Selin and Selin, 1994; The Standish group, 2000; Couillard, 1995; Tan, 1996; Belassi and Tukel, 1996; Kpmg, 1997; Dvir et al., 1998; Kasser and Williams, 1998; Wittaker, 1999; Taylor, 2000; Thite, 2000; Poon and Wager, 2001; Andersen et al., 2002; Yeo, 2002; Avots, 1969; Morris, 1986; Morris and Hough, 1987; McComb and Smith, 1991; Martinez, 1994; Wastell and Newman, 1996; Mcgolpin and Ward, 1997; Jang and Lee, 1998; Cooke-Davies, 2002; Caldeira and Ward, 2002; Westerveld, 2003; Cleland and King (1983); Stoddart-Stones, 1988; Cash and Fox, 1992; Tennant, 1993; Munns and Bjeirmi, 1996; McCormack, 1997; Turner, 1999; Weir, 1999; Turn, 2004; entre outros) vide capítulo 3. Refira-se que a própria publicação Project Manager Competency Development (PMCD) Framework do PMI (páginas 1 a 5) afirma que as competências do gestor do projecto e a maturidade da Maria da Conceição Gomes Vilas Boas 77

102 organização em gestão de projectos contribuem para o sucesso do projecto. Afirma ainda que as competências do gestor de projecto, por si só, não garantem o sucesso do projecto. O PMI acredita que o sucesso do projecto exige competências em gestão de projecto, bem como maturidade e capacidade em gestão de projectos o desempenho organizacional não pode ser ignorado! Por outras palavras ter um gestor com competência não assegura o sucesso. Centrar-se, exclusivamente, nas competências do gestor de projecto independente do desempenho da organização é, assim, demasiado simplista. Modelos de Avaliação da Gestão de Projectos O simples uso da gestão de projectos, mesmo que realizado durante um grande período de tempo, não conduz à excelência. Pelo contrário, pode resultar na repetição sistemática dos mesmos erros vide capítulo 4. Deve ter-se em consideração que os modelos de maturidade CMM, CMMI, Processo PO10 da framework CobiT 4.1, entre outros - são um instrumento disponível para avaliar e, ao mesmo tempo, orientar as organizações em direcção às melhores práticas (e estratégicas) no que respeita à área de projectos de SI/TI. Planeamento Estratégico de SI/TI Assim, verificou-se que a excelência na gestão de projectos só pode ser alcançada com um planeamento estratégico de SI/TI, conforme é explicitado a seguir vide com maior detalhe o capítulo 2. Os projectos são utilizados como meio de atingir o plano estratégico de uma organização, seja a equipa do projecto formada por funcionários da organização ou prestadores de serviços contratados [PMBOK, 2004]. Porém, em muitas organizações, muitos projectos emergiram ou evoluíram de forma isolada ao longo dos anos sem constituírem uma parte integrante de qualquer plano estratégico de SI/TI. Isto conduziu a um conjunto de dificuldades: custos elevados; benefícios mínimos ou não quantificados; incapacidade de resposta a mudanças no mercado ou na tecnologia e restrições à integração de sistemas [António Miguel, 2003, pág. 57]. Para O Connor (1993) empresas com planos estratégicos para os SI, bem integrados com a gestão, conseguem sistematicamente melhores resultados do que aquelas que não os têm. Teo e Ang (1999) identificaram como dimensão para o sucesso dos projectos o alinhamento dos projectos com os planos de negócio. Também, para Amaral (1994) o planeamento estratégico de SI/TI traz vantagens competitivas à organização. Administração Pública Despende Elevados Recursos Financeiros em SI/TI No estudo da IGF, de 2008, verificou-se que a Administração Pública Serviços Integrados e Serviços e Fundos Autónomos - despende elevados recursos financeiros em projectos de SI/TI. Assim, considerou-se pertinente aferir se as entidades que investem mais recursos financeiros em SI/TI, ao longo dos anos, possuem maior nível de maturidade organizacional em gestão de projectos. Gestão de Projectos Dimensão Humana e Dimensão Técnica Cada aspecto da gestão de projecto tem duas dimensões: uma dimensão técnica e uma dimensão humana. A dimensão técnica engloba os grupos de práticas ou processos que são essenciais para a gestão de projectos e a dimensão humana inclui as pessoas com os seus conhecimentos [Cooke-Davis, 2002]. 78 Maria da Conceição Gomes Vilas Boas

103 Inexistência ou Escassez de Pessoal de TIC A UMIC - Agência para a Sociedade do Conhecimento nos seus inquéritos à Utilização das Tecnologias da Informação e Comunicação efectuados à Administração Central, Câmaras Municipais e Região Autónoma da Madeira, nos anos de 2005 e 2006, conclui a inexistência ou escassez de Pessoal de TIC tem condicionado negativamente o desenvolvimento das actividades dos organismos vide tabela 21: % Referências Organismos da Administração Pública Central, % [UMIC, 2005] Organismos do Governo Regional da Madeira, % [UMIC, 2005M] Câmaras Municipais, % [UMIC, 2005C] Organismos da Administração Pública Central, % [UMIC, 2006] Tabela 21 Organismos onde a Inexistência ou Escassez de Pessoal TI tem Condicionado Negativamente o Desenvolvimento das suas Actividades. Fonte: Autor. É também oportuno investigar se a percentagem de recursos humanos de TI afecta a maturidade organizacional em gestão de projectos Problema de Investigação Partindo dos pressupostos anteriormente referidos parece pertinente avaliar em que estádio se encontra a Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública. Assim sendo esta investigação versará o seguinte problema de investigação: Avaliar a Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos Pergunta de Investigação e Proposições Esta investigação apresenta como pergunta de investigação, já previamente mencionada no ponto 1.2: Qual o actual nível de maturidade organizacional em gestão de projectos na Administração Pública Portuguesa Serviços Integrados e Serviços e Fundos Autónomos? Qual a correlação com maturidade organizacional em planeamento estratégico de TI, recursos humanos de TI por recursos humanos globais (%), despesa em TI por despesa global (%)? vide figura 23. Maria da Conceição Gomes Vilas Boas 79

104 Maturidade Organizacional em Planeamento Estratégico de TI Maturidade Organizacional em Gestão de Projectos Recursos Humanos de TI Investimentos em TI Figura 23 Pergunta de Investigação e Ligação às Proposições. Fonte: Autor. A resposta a este problema exige a validação ou comprovação das seguintes proposições: Qual é a correlação entre a maturidade em planeamento estratégico de SI/TI e a maturidade em gestão de projectos de SI/TI? Espera-se que as organizações com maior maturidade em planeamento estratégico de SI/TI possuem maior maturidade em gestão de projectos, tal como é sugerido pela PMI [PMBOK, 2004]. Qual é a correlação entre os recursos humanos de TI por recursos humanos globais (%) e a maturidade em gestão de projectos SI/TI? Espera-se que as organizações que possuem maior percentagem de recursos humanos de TI possuem também uma maturidade de gestão de projectos superior. Qual é a correlação entre despesa em TI por despesa global (%) e a maturidade em gestão de projectos de SI/TI? Espera-se que as organizações que investem mais em SI/TI, ao longo do tempo, apresentem maior maturidade em gestão de projectos de SI/TI Tipo de Estudo A estratégia de investigação a utilizar é Estudo de Caso. O tipo de caso de estudo mais adequado às características do objecto de estudo identificado é o singular e o incluso. Singular, porque o objecto de estudo é a Gestão de Projectos. Incluso, porque a análise incidirá no conjunto das entidades da Administração Pública - Serviços Integrados e Serviços e Fundos Autónomos (várias unidades de análise). 80 Maria da Conceição Gomes Vilas Boas

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge)

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) Governança de TI AULA 08 2011-1sem Governança de TI 1 Introdução ao Gerenciamento de Projetos HISTÓRIA PMI Project Management Institute: Associação

Leia mais

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1 r Indice Introdução.......................................... 1 Parte I - Um Modelo de Gestão de Projectos 1- Características da Gestão de Projectos 11 1.1 Definição de Projecto 11 1.2 Projectos e Estratégia

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

O Gerenciamento de Projetos na abordagem do

O Gerenciamento de Projetos na abordagem do Seminário de Desenvolvimento de Gestores de Programas e Projetos Fórum QPC O Gerenciamento de Projetos na abordagem do PMI - Project Management Institute Marco Antônio Kappel Ribeiro Presidente do PMI-RS

Leia mais

5.1 Introdução. 5.2 Project Management Institute (PMI)

5.1 Introdução. 5.2 Project Management Institute (PMI) 5 NORMALIZAÇÃO DA GESTÃO DE PROJETOS 5.1 Introdução Embora tradicionalmente o esforço de normalização pertença à International Standards Organization (ISO), no caso da gestão de projetos a iniciativa tem

Leia mais

A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde

A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde Luis Augusto dos Santos 1, Heimar de Fátima Marin 2 1 Engenheiro Eletricista, membro do NIEn e pós-graduando pela

Leia mais

CATÁLOGO DE FORMAÇÃO project management - management personal effectiveness

CATÁLOGO DE FORMAÇÃO project management - management personal effectiveness CATÁLOGO DE FORMAÇÃO project management - management personal effectiveness 2015 Rua Bombarda 58 Santa Joana 3810-013 Aveiro, Portugal emete@emete.com 1 ÍNDICE PREPARAÇÃO PARA A CERTIFICAÇÃO PMP...4 GESTÃO

Leia mais

efagundes com GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4

efagundes com GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4 GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4 1 CobIT Modelo abrangente aplicável para a auditoria e controle de processo de TI, desde o planejamento da tecnologia até a monitoração e auditoria de

Leia mais

Carlos Henrique Santos da Silva

Carlos Henrique Santos da Silva GOVERNANÇA DE TI Carlos Henrique Santos da Silva Mestre em Informática em Sistemas de Informação UFRJ/IM Certificado em Project Management Professional (PMP) PMI Certificado em IT Services Management ITIL

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

TI - GESTÃO DE PROJETOS

TI - GESTÃO DE PROJETOS TI - GESTÃO DE PROJETOS BISCAIA, R RESUMO: Atualmente o mercado competitivo faz com que empresas busquem constantemente inovações para se manterem competitivas, e nesse cenário tempo, custo e qualidade,

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS ISSN 1984-9354 PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Debora Athayde Herkenhoff (Latec/UFF) Moacyr Amaral Domingues Figueiredo (Latec/UFF) Gilson Brito de Lima (UFF)

Leia mais

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc Governança de TI Prof. Carlos Henrique Santos da Silva, MSc PMP, PMI-RMP, PMI-ACP, CSM, CSPO, ITIL & CobiT Certified Carlos Henrique Santos da Silva, MSc, PMP Especializações Certificações Mestre em Informática

Leia mais

Elaboração e Análise de Projetos

Elaboração e Análise de Projetos 1 ADM 0395 Elaboração e Análise de Projetos Isnard Martins Referencial Bibliográfico Gerenciamento de Projetos Cláudio Jordão et Al O Projeto pode ser entendido como a alocação de recursos com um objetivo

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Objectivos globais PROJECTO INTEGRADOR LEI 2010/11/12/13 NOÇÕES DE GESTÃO DE PROJECTOS. 1ª parte (IJ) 2ª parte (RL)

Objectivos globais PROJECTO INTEGRADOR LEI 2010/11/12/13 NOÇÕES DE GESTÃO DE PROJECTOS. 1ª parte (IJ) 2ª parte (RL) PROJECTO INTEGRADOR LEI 2010/11/12/13 NOÇÕES DE GESTÃO DE PROJECTOS Isabelina Jorge, PMP, isabelina.jorge@gmail.com Rui Leal, Mst EI, rui.leal@gmail.com Objectivos globais 1ª parte (IJ)! Abordagem standard

Leia mais

i 3.2 Assegurar Integridade e Profissionalismo 43 9 3.2.1 Lucro Pessoal 44

i 3.2 Assegurar Integridade e Profissionalismo 43 9 3.2.1 Lucro Pessoal 44 ICE Introdução 1 PARTE I - CONTEXTO DA GESTÃO DE PROJECTOS E NORMAS DO MERCADO 1. Enquadramento da Gestão de Projectos 7 1.1 Definição de Projecto 7 1.2 Intervenientes no Projecto 9 1.3 Triângulo de Restrições

Leia mais

GPAD Gestão de Projetos em Ambientes Digitais

GPAD Gestão de Projetos em Ambientes Digitais GPAD Gestão de Projetos em Ambientes Digitais Tecnologia e Mídias Digitais PUC SP Prof. Eduardo Savino Gomes 1 Afinal, o que vem a ser Gestão? 2 Gestão/Gerir/Gerenciar Gerenciar, administrar, coordenar

Leia mais

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK 180 - Encontro Anual de Tecnologia da Informação Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK Thiago Roberto Sarturi1, Evandro Preuss2 1 Pós-Graduação em Gestão de TI Universidade

Leia mais

IT Governance uma janela de oportunidades

IT Governance uma janela de oportunidades A Governança dos SI/TI da AP O quê, como, onde e porquê? IT Governance uma janela de oportunidades Luis Borges Gouveia Professor Associado Faculdade de Ciência e Tecnologia Universidade Fernando Pessoa

Leia mais

Estudo do CMM e do CMMI

Estudo do CMM e do CMMI Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos

Leia mais

1 Descrição sumária. Varajão, Santana, Cunha e Castro, Adopção de sistemas CRM nas grandes empresas portuguesas, Computerworld, 2011 1

1 Descrição sumária. Varajão, Santana, Cunha e Castro, Adopção de sistemas CRM nas grandes empresas portuguesas, Computerworld, 2011 1 Adopção de sistemas CRM nas grandes empresas portuguesas João Varajão 1, Daniela Santana 2, Manuela Cunha 3, Sandra Castro 4 1 Escola de Ciências e Tecnologia, Departamento de Engenharias, Universidade

Leia mais

PMBok x PRINCE2. Flávia David de Oliveira Gomes. Prof. Msc. Guilherme A. Barucke Marcondes. Víctor Hugo Rodrigues de Barros

PMBok x PRINCE2. Flávia David de Oliveira Gomes. Prof. Msc. Guilherme A. Barucke Marcondes. Víctor Hugo Rodrigues de Barros PMBok x Flávia David de Oliveira Gomes Instituto Nacional de Telecomunicações - Inatel flavia@cp2ejr.com.br Prof. Msc. Guilherme A. Barucke Marcondes Instituto Nacional de Telecomunicações - Inatel guilherme@inatel.br

Leia mais

Implementação de Ferramentas de Gestão SOX ISO 20000 ISO 27001. Susana Carias Lisboa, 24 de Outubro de 2008

Implementação de Ferramentas de Gestão SOX ISO 20000 ISO 27001. Susana Carias Lisboa, 24 de Outubro de 2008 Implementação de Ferramentas de Gestão SOX ISO 20000 ISO 27001 Susana Carias Lisboa, 24 de Outubro de 2008 Agenda Introdução Desafio 1º passo Problemática ISO 27001 ISO 20000 Conclusões 2 Agenda Introdução

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

Um modelo para o gerenciamento de múltiplos projetos de software aderente ao CMMI

Um modelo para o gerenciamento de múltiplos projetos de software aderente ao CMMI Universidade Federal de Pernambuco Graduação em Ciência da Computação Centro de Informática Um modelo para o gerenciamento de múltiplos projetos de software aderente ao CMMI PROPOSTA DE TRABALHO DE GRADUAÇÃO

Leia mais

Desenvolvimento Produto e Projetos

Desenvolvimento Produto e Projetos 1 ADM Desenvolvimento Produto e Projetos Isnard Martins Referencial Bibliográfico Gerenciamento de Projetos - Ralph Kelling Gestão de Projetos - Cláudio Jordão et Al A Natureza de um Projeto Projeto é

Leia mais

Pós-graduação em Gerenciamento de Projetos práticas do PMI

Pós-graduação em Gerenciamento de Projetos práticas do PMI Pós-graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) 2 Gerente Sênior de Projetos e Processos, 18 anos de experiência

Leia mais

PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO

PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno: Marcus

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005 ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade 2005 Estrutura da Norma 0. Introdução 1. Campo de Aplicação 2. Referência Normativa 3. Termos e Definições 4. Sistema de Gestão

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

PMBOK e Gerenciamento de Projetos

PMBOK e Gerenciamento de Projetos PMBOK e Gerenciamento de Projetos Gerenciamento de projetos (GP) é uma área de atuação e conhecimento que tem ganhado, nos últimos anos, cada vez mais reconhecimento e importância. Um dos principais difusores

Leia mais

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa IV Seminário Internacional Maturidade em Gerenciamento de Projetos Como Medir o Nível de Maturidade em GP de uma Empresa Palestrante: Leon Herszon F.,MSc, PMP Leon Herszon F., MSc, PMP Diretor Executivo

Leia mais

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NIP: Nº DO RELATÓRIO: DENOMINAÇÃO DA EMPRESA: EQUIPA AUDITORA (EA): DATA DA VISITA PRÉVIA: DATA DA AUDITORIA: AUDITORIA DE: CONCESSÃO SEGUIMENTO ACOMPANHAMENTO

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

PMO (Project Management Office) - Implantação de Escritório de Projetos

PMO (Project Management Office) - Implantação de Escritório de Projetos PMO (Project Management Office) - Implantação de Escritório de Projetos Orientações para o Projeto, Implantação, Gerenciamento e Avaliação de Maturidade do Escritório de Projetos Objetivo O que leva as

Leia mais

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011

Workshop. Maturidade da Governação e Gestão de TI em Portugal. Inquérito Nacional 2011. Mário Lavado itsmf Portugal 11-10-2011 Workshop Maturidade da Governação e Gestão de TI em Portugal Inquérito Nacional 2011 Mário Lavado itsmf Portugal 11-10-2011 Agenda Apresentação dos resultados do estudo de maturidade do ITSM & ITGovervance

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade e Auditorias (Mestrado em Engenharia Alimentar) Gestão da Qualidade (Mestrado em Biocombustívies) ESAC/João Noronha Novembro

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Em conformidade com a metodologia PMI 1 Apresentações Paulo César Mei, MBA, PMP Especialista em planejamento, gestão e controle de projetos e portfólios, sempre aplicando as melhores

Leia mais

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Resumo. O gerenciamento de projetos tem se tornado, durante os últimos anos, alvo de

Leia mais

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis MBA em Gestão de Projetos Gerenciamento de Projetos Prática essencial para gerar negócios sustentáveis Prof: Ângelo Braga, PMP, MBA angelo.braga@fgv.br eu@angelobraga.com.br 2/154 Contatos Prof. Ângelo

Leia mais

Guimarães, 13 de Maio de 2002. Luis Amaral. Universidade do Minho

Guimarães, 13 de Maio de 2002. Luis Amaral. Universidade do Minho Prefácio A Arquitectura dos Sistemas de Informação, enquanto assunto central da área disciplinar das Tecnologias e Sistemas de Informação é, na minha opinião, um dos seus temas mais importantes e, simultaneamente,

Leia mais

Governança de TI: Aspectos Gerenciais

Governança de TI: Aspectos Gerenciais Governança de TI: Aspectos Gerenciais Governança de TI: Aspectos Gerenciais 1 Governança de TI: Aspectos Gerenciais Governança de TI: Aspectos Gerenciais Governança é a forma como a estrutura organizacionalestá

Leia mais

Gerência de Projetos. O segredo para ter sucesso na implantação de Tecnologia da informação

Gerência de Projetos. O segredo para ter sucesso na implantação de Tecnologia da informação Gerência de Projetos O segredo para ter sucesso na implantação de Tecnologia da informação Introdução e Conceitos Conceitos importantes para o entendimento da disciplina O que é um projeto? Um projeto

Leia mais

Programa AconteSER. Gestão de Projetos. Torres Vedras 12 de Dezembro de 2013

Programa AconteSER. Gestão de Projetos. Torres Vedras 12 de Dezembro de 2013 Programa AconteSER Gestão de Projetos Torres Vedras 12 de Dezembro de 2013 Agenda Enquadramento dos projetos na mudança Conceitos de gestão de projetos Iniciação Organização e planeamento Execução, monitorização

Leia mais

COBIT FOUNDATION - APOSTILA DE RESUMO

COBIT FOUNDATION - APOSTILA DE RESUMO COBIT FOUNDATION - APOSTILA DE RESUMO GOVERNANÇA DE TI O QUE É GOVERNANÇA DE TI É um conjunto de estruturas e processos que visa garantir que a TI suporte e maximize adequadamente os objetivos e estratégias

Leia mais

GESTÃO LOGÍSTICA. Capítulo - 12. Organização para uma Logística Efectiva. Identificação do impacto de uma logística efectiva no desempenho

GESTÃO LOGÍSTICA. Capítulo - 12. Organização para uma Logística Efectiva. Identificação do impacto de uma logística efectiva no desempenho GESTÃO LOGÍSTICA Capítulo - 12 Organização para uma Logística Efectiva Objectivos do Capítulo Identificação do impacto de uma logística efectiva no desempenho eficaz e eficiente da empresa Descrição de

Leia mais

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

MODELOS DE MELHORES GOVERNANÇA DE T.I. PRÁTICAS DA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MODELOS DE MELHORES PRÁTICAS DA GOVERNANÇA DE T.I. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza MELHORES PRÁTICAS PARA T.I. MODELO DE MELHORES PRÁTICAS COBIT Control Objectives for Information

Leia mais

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;

Leia mais

MBA Gestão da Tecnologia de Informação

MBA Gestão da Tecnologia de Informação MBA Gestão da Tecnologia de Informação Informações: Dias e horários das aulas: Segundas e Terças-feiras das 18h00 às 22h00 aulas semanais; Sábados das 08h00 às 12h00 aulas quinzenais. Carga horária: 600

Leia mais

A relação da Governança de TI (COBIT), Gerenciamento de Serviços (ITIL) e Gerenciamento de Projetos (PMI)

A relação da Governança de TI (COBIT), Gerenciamento de Serviços (ITIL) e Gerenciamento de Projetos (PMI) A relação da Governança de TI (COBIT), Gerenciamento de Serviços (ITIL) e Gerenciamento de Projetos (PMI) Os principais modelos de melhores práticas em TI Carlos Henrique Santos da Silva, MSc, PMP, ITIL

Leia mais

Conceituar projetos e a gerência de projetos. Conhecer a importância e os benefícios do gerenciamento de projetos Conhecer o PMI, o PMBOK, os grupos

Conceituar projetos e a gerência de projetos. Conhecer a importância e os benefícios do gerenciamento de projetos Conhecer o PMI, o PMBOK, os grupos Gestão de Projetos Empresariais Objetivos: Conceituar projetos e a gerência de projetos. Conhecer a importância e os benefícios do gerenciamento de projetos Conhecer o PMI, o PMBOK, os grupos de processos

Leia mais

25/05/2015. Um pouco de história. O Modelo CMMI. Capability Maturity Model Integration (CMMI) Capability Maturity Model (CMM)

25/05/2015. Um pouco de história. O Modelo CMMI. Capability Maturity Model Integration (CMMI) Capability Maturity Model (CMM) DCC / ICEx / UFMG Um pouco de história O Modelo CMMI Na década de 80, o Instituto de Engenharia de Software (SEI) foi criado Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Objetivos Fornecer software

Leia mais

OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA

OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA SOBRE A CONSULTORIA Alcance melhores resultados através da gestão integrada de projetos relacionados ou que compartilham

Leia mais

Melhores Práticas em TI

Melhores Práticas em TI Melhores Práticas em TI Referências Implantando a Governança de TI - Da Estratégia à Gestão de Processos e Serviços - 2ª Edição Edição - AGUINALDO ARAGON FERNANDES, VLADIMIR FERRAZ DE ABREU. An Introductory

Leia mais

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 Marcelo Campolina de Castro 2 Resumo Com o novo cenário econômico, muitas empresas estão investindo alto na

Leia mais

Minicurrículo. Prof. Dr. Adilson de Oliveira Computer Engineering Ph.D Project Management Professional. Líder no PMO. Diretor e Professor

Minicurrículo. Prof. Dr. Adilson de Oliveira Computer Engineering Ph.D Project Management Professional. Líder no PMO. Diretor e Professor Adilson de Oliveira Minicurrículo Mestre em Ciência da Informação Doutor em Engenharia de Computação Diretor e Professor Líder no PMO Gerente de Projetos Profissional Prof. Dr. Adilson de Oliveira Computer

Leia mais

ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA

ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA SOBRE A CONSULTORIA Assegure melhores resultados em seus projetos com uma estrutura de comunicação simples, efetiva,

Leia mais

3. Metodologias de Gerenciamento de Riscos

3. Metodologias de Gerenciamento de Riscos 3. Metodologias de Gerenciamento de Riscos A complexidade que caracteriza a implantação de um sistema ERP é uma das maiores preocupações das organizações que pretendem desenvolver projetos desta natureza.

Leia mais

Governança de TI. Importância para as áreas de Auditoria e Compliance. Maio de 2011. IT Governance Discussion

Governança de TI. Importância para as áreas de Auditoria e Compliance. Maio de 2011. IT Governance Discussion Governança de TI Importância para as áreas de Auditoria e Compliance Maio de 2011 Page 1 É esperado de TI mais do que deixar o sistema no ar. Page 2 O que mudou o Papel de TI? Aumento de riscos e de expectativas

Leia mais

Análise da influência da evolução na maturidade em gerenciamento no desempenho dos projetos

Análise da influência da evolução na maturidade em gerenciamento no desempenho dos projetos Análise da influência da evolução na maturidade em gerenciamento no desempenho dos projetos Luiz Gustavo de Castro Santos (POLI-USP) lgustavoindg@terra.com.br Marcelo Ramos Martins (POLI-USP) mrmartin@usp.br

Leia mais

Sistemas de Informação Empresarial

Sistemas de Informação Empresarial Sistemas de Informação Empresarial Governança de Tecnologia da Informação parte 2 Fonte: Mônica C. Rodrigues Padrões e Gestão de TI ISO,COBIT, ITIL 3 International Organization for Standardization d -

Leia mais

Mapeamento GRH. 1. Introdução

Mapeamento GRH. 1. Introdução Mapeamento GRH 1. Introdução 1.1. Finalidade Este documento tem duas finalidades principais: a) Averiguar semelhanças e diferenças entre modelos, normas e guias de boas práticas para gestão de recursos

Leia mais

SOBRE O WORKSHOP [ WORKSHOP

SOBRE O WORKSHOP [ WORKSHOP WORKSHOP [ WORKSHOP SOBRE O WORKSHOP O PMDome é um treinamento muito dinâmico e prático em gerenciamento de projetos onde os participantes são divididos em times que, em uma competição desafiadora e animada,

Leia mais

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto?

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto? Planejamento, Execução e Controle de Projetos de Software. Objetivos da aula 1) Dizer o que é gerenciamento de projetos e a sua importância; 2) Identificar os grupos de processos do gerenciamento de projetos

Leia mais

ESCRITÓRIO RIO DE PROJETOS

ESCRITÓRIO RIO DE PROJETOS PMO PROJETOS PROCESSOS MELHORIA CONTÍNUA PMI SCRUM COBIT ITIL LEAN SIX SIGMA BSC ESCRITÓRIO RIO DE PROJETOS DESAFIOS CULTURAIS PARA IMPLANTAÇÃO DANIEL AQUERE DE OLIVEIRA, PMP, MBA daniel.aquere@pmpartner.com.br

Leia mais

Universidade do Porto

Universidade do Porto O Estado da Arte em Projectos de Investimento - A Importância da Análise Não Financeira Na Prática das Empresas Portuguesas Nuno Filipe Lopes Moutinho Tese de Mestrado em Ciências Empresariais Área de

Leia mais

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc Governança de TI Prof. Carlos Henrique Santos da Silva, MSc PMP, PMI-RMP, PMI-ACP, CSM, ITIL & CobiT Certified Carlos Henrique Santos da Silva, MSc Mestre em Informática na área de Sistemas de Informação

Leia mais

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS Curricular Unit Plan ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS CURSO Licenciatura em Engenharia Informática U.C. GESTÃO DE PROJECTOS INFORMÁTICOS Horas presenciais / Ano 56 Ano Lectivo 2010

Leia mais

Project Management Institute São Paulo, Brasil Chapter http://www.pmisp.org.br. Metodologia de Maturidade em Gerenciamento de Projetos

Project Management Institute São Paulo, Brasil Chapter http://www.pmisp.org.br. Metodologia de Maturidade em Gerenciamento de Projetos Metodologia de Maturidade em Gerenciamento de Projetos Farhad Abdollahyan, Msc, PMP Diretor Administrativo do PMI-SP AGENDA Cultura de Gerenciamento de Projetos Modelos de Maturidade OPM3 TM Demonstração

Leia mais

Modelagem de Processos de Negócio Departamento de Ciência da Computação - UFMG. Maturidade em BPM. (Business Process Management)

Modelagem de Processos de Negócio Departamento de Ciência da Computação - UFMG. Maturidade em BPM. (Business Process Management) Modelagem de Processos de Negócio Departamento de Ciência da Computação - UFMG Maturidade em BPM (Business Process Management) Douglas Rodarte Florentino Belo Horizonte, 21 de Junho de 2010 Agenda Introdução

Leia mais

O Desenvolvimento do Corporate Governance em Portugal

O Desenvolvimento do Corporate Governance em Portugal 10 ANOS DO IPCG O GOVERNO SOCIETÁRIO EM PORTUGAL O Desenvolvimento do Corporate Governance em Portugal Lisboa, 09 de Julho de 2013 SUMÁRIO 1. Acontecimentos empresariais e governance 2. Fatores normativos

Leia mais

GERENCIAMENTO DE PROJETOS

GERENCIAMENTO DE PROJETOS GERENCIAMENTO DE PROJETOS Professora: Valéria Vargens Email: valeriapitagoras@gmail.com A Importância do Gerenciamento de Projetos O que estes eventos têm em comum? Como estudar Gerenciamento de projetos?

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

1 Descrição sumária. Varajão, Trigo e Barroso, O Gestor de Sistemas de Informação nas grandes empresas portuguesas, Computerworld, 2011.

1 Descrição sumária. Varajão, Trigo e Barroso, O Gestor de Sistemas de Informação nas grandes empresas portuguesas, Computerworld, 2011. O Gestor de Sistemas de Informação nas grandes empresas portuguesas João Varajão 1, António Trigo 2, João Barroso 1 1 Escola de Ciências e Tecnologia, Universidade de Trás-os-Montes e Alto Douro 2 Instituto

Leia mais

Sistemas de Gestão na Segurança de Informação

Sistemas de Gestão na Segurança de Informação Public Safety & National Security Day Sistemas de Gestão na Segurança de Informação Paulo Faroleiro Lisboa, 10 de Dezembro 09 A Novabase Web site: www.novabase.pt Fundada em 1989 no seio académico no IST,

Leia mais

SISTEMAS DE GESTÃO DA QUALIDADE

SISTEMAS DE GESTÃO DA QUALIDADE SISTEMAS DE GESTÃO DA QUALIDADE Objectivos do Curso. No final deste os alunos deverão: Identificar os principais objectivos associados à implementação de Sistemas de Gestão da Qualidade (SGQ) Compreender

Leia mais

Metodologia de Gerenciamento de Projetos e Captação de Recursos. Secretaria das Cidades. Secretaria do Meio Ambiente e Recursos Hídricos

Metodologia de Gerenciamento de Projetos e Captação de Recursos. Secretaria das Cidades. Secretaria do Meio Ambiente e Recursos Hídricos Metodologia de Gerenciamento de Projetos e Captação de Recursos Secretaria das Cidades Secretaria do Meio Ambiente e Recursos Hídricos Evolução da Administração no Setor Público Melhores práticas de gestão

Leia mais

Uma plataforma estratégica

Uma plataforma estratégica Publicado: Fevereiro 2007 Autor: Rui Loureiro Sénior Partner Implementar o Help Desk Quando simplesmente pensamos em implementar um Help Desk, isso pode significar uma solução fácil de realizar ou algo

Leia mais

Project Management Institute Building professionalism in project management

Project Management Institute Building professionalism in project management Project Management Institute Building professionalism in project management Marco Antônio Kappel Ribeiro marcokr@via-rs.net Julho / 2004 Project Management Institute Building professionalism in project

Leia mais

COACHING E MENTORING EM GERENCIAMENTO DE PROJETOS CONSULTORIA

COACHING E MENTORING EM GERENCIAMENTO DE PROJETOS CONSULTORIA COACHING E MENTORING EM GERENCIAMENTO DE PROJETOS CONSULTORIA SOBRE A CONSULTORIA Assegure resultados superiores do seu time de projetos e dos executivos com o coaching e mentoring exclusivo da Macrosolutions.

Leia mais

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

Governança de TI: O que é COBIT?

Governança de TI: O que é COBIT? Governança de TI: O que é COBIT? Agenda Governança de TI Metodologia COBIT Relacionamento do COBIT com os modelos de melhores práticas Governança de TI em 2006 Estudo de Caso Referências Governança de

Leia mais

2. Gerenciamento de projetos

2. Gerenciamento de projetos 2. Gerenciamento de projetos Este capítulo contém conceitos e definições gerais sobre gerenciamento de projetos, assim como as principais características e funções relevantes reconhecidas como úteis em

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

CARACTERÍSTICAS DE UM PROJETO

CARACTERÍSTICAS DE UM PROJETO CARACTERÍSTICAS DE UM PROJETO Temporário: significa que cada projeto tem um início e um fim muito bem definidos. Um projeto é fundamentalmente diferente: porque ele termina quando seus objetivos propostos

Leia mais

Definição do Modelo de Processo

Definição do Modelo de Processo Definição do Modelo de Processo 1. Introdução 1.1. Finalidade Mapear práticas sugeridas (i) pelo Padrão para Gestão de Portfólio do PMI, (ii) pelo Modelo de Referência do MPS.BR e (iii) pela Norma ISO/IEC

Leia mais

COMUNICAÇÃO, GESTÃO E PLANO DE RECUPERAÇÃO DE PROJETOS EM CRISE CONSULTORIA

COMUNICAÇÃO, GESTÃO E PLANO DE RECUPERAÇÃO DE PROJETOS EM CRISE CONSULTORIA COMUNICAÇÃO, GESTÃO E PLANO DE RECUPERAÇÃO DE PROJETOS EM CRISE CONSULTORIA SOBRE A CONSULTORIA Minimize os impactos de um projeto em crise com a expertise de quem realmente conhece o assunto. A Macrosolutions

Leia mais

Este programa tem como objetivo consolidar conhecimentos sobre as melhores práticas de Gerenciamento de Projetos na área de TI com base no

Este programa tem como objetivo consolidar conhecimentos sobre as melhores práticas de Gerenciamento de Projetos na área de TI com base no GERÊNCIA DE PROJETOS DE TI Práticas do PMBOK v4 aplicadas à Tecnologia da Informação. Inclui Planejamento Estratégico da TI, modelos de maturidade (OPM3 e CMM-I) e metodologias ágeis (SCRUM etc.). Discussão

Leia mais

PMONow! Serviço de Implantação de um Escritório de Projetos

PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos As organizações em torno do mundo estão implantando processos e disciplinas formais

Leia mais

XI Mestrado em Gestão do Desporto

XI Mestrado em Gestão do Desporto 2 7 Recursos Humanos XI Mestrado em Gestão do Desporto Gestão das Organizações Desportivas Módulo de Gestão de Recursos Rui Claudino FEVEREIRO, 28 2 8 INDÍCE DOCUMENTO ORIENTADOR Âmbito Objectivos Organização

Leia mais

Paulo Roberto Borges Ferreira. IMPLEMENTAÇÃO DE ERP s: Características e Estratégias de implementação

Paulo Roberto Borges Ferreira. IMPLEMENTAÇÃO DE ERP s: Características e Estratégias de implementação Paulo Roberto Borges Ferreira IMPLEMENTAÇÃO DE ERP s: Características e Estratégias de implementação Paracatu 2012 RESUMO Este trabalho visa atender uma demanda esquecida, e agora emergente, de empresas

Leia mais

GTI Governança de TI

GTI Governança de TI GTI Governança de TI Modelos de Melhores Práticas e o Modelo de Governança de TI Governança de TI FERNANDES & ABREU, cap. 4 1 COBIT Control Objectives for Information and Related Technology. Abrangente

Leia mais

Pensamento. Não se envelhece, enquanto buscamos." (Jean Rostand)

Pensamento. Não se envelhece, enquanto buscamos. (Jean Rostand) Pensamento Não se envelhece, enquanto buscamos." (Jean Rostand) AGRADECIMENTOS Os meus primeiros agradecimentos, vão para a minha mãe por estar sempre presente e acreditar em mim, para o meu pai, pelas

Leia mais

Como concluir um projeto com sucesso?

Como concluir um projeto com sucesso? Como concluir um projeto com sucesso? Luiz Eduardo Cunha, Eng. Professor da FAAP e do IMT 1 Luiz Eduardo Cunha Graduado em Engenharia de Produção EPUSP Pós-Graduado em Gestão do Conhecimento e Inteligência

Leia mais

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo A metáfora bala de prata se aplica a qualquer ação que terá uma extrema

Leia mais

Aula Nº 11 Suprimentos e contratações

Aula Nº 11 Suprimentos e contratações Aula Nº 11 Suprimentos e contratações Objetivos da Aula: Os objetivos desta aula visam fornecer uma visão geral do processo empregado para se administrar a aquisição, no mercado, dos produtos necessários

Leia mais